qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Qemu-devel] [PATCH RFC v1] Sync dev.config with XenPTReg->data field.


From: Konrad Rzeszutek Wilk
Subject: [Qemu-devel] [PATCH RFC v1] Sync dev.config with XenPTReg->data field.
Date: Mon, 29 Jun 2015 17:01:57 -0400

Hey,

This patchset is dependent on 
http://lists.xen.org/archives/html/xen-devel/2015-06/msg04812.html
(Cleanups + various fixes due to libxl  ABI + more logging on errors.).

During the discussion of 
http://lists.xen.org/archives/html/xen-devel/2015-06/msg01504.html
"[PATCH QEMU-XEN] xen/pt: Start with emulated PCI_COMMAND set to zero."
we got in a discussion about the xen/pt code usage of XenPTRreg->data
and dev.config. The crux of the matter was that the PCI_COMMAND
register read from the host changed from 0 to 3 (so PCI_COMMAND_IO
and PCI_COMMAND_MEM were enabled). That messed up QEMU badly (thought
it did recover) with some nasty messages on the Xen's ring buffer.

Fast-forward and we came to the conclusion that:

1) The dev.config is (by Xen code) is used as the cache of the
   host configuration devices (which is OK at init right now).

   However to sync up the ->data with dev.config (and apply emu_mask)
   means that it cannot be used as such (the semantics of that have changed).

   We want dev.confg and ->data be synced up so that the 
   initial guest values are not polluted with host register values
   which we are emulating.

2). The dev.config is (by the generic code) used as a view of what
   the guest should see (cache of guest values). 

This patchset moves in the direction of ripping out XenPTRreg->data
and just using dev.config. Any time we want to consult the host values
we will do so.

These patches lay the groundwork and untangle some of the assumptions
that the Xen code had made.

The end goal (another patchset after this) will be that the XenPTRreg->data
will vanish and will use dev.config as the sole source of guest cache
values.

Note: Only the first three patches are neccessary in the march toward
this goal:

 [PATCH RFC 1 1/8] xen/pt: Use xen_host_pci_get_[byte|word] instead of
 [PATCH RFC 1 2/8] xen/pt: Sync up the dev.config and data values.
 [PATCH RFC 1 3/8] xen/pt: Check if reg->init is past the reg->size

The rest are to piggyback on this and add proper error logging and
reporting such that any bug fallout that comes out of this will be
easier to tackle. I can move them way out to the end of the next
patch series - but it might be easier to have them in this to help
with bisection.

Please review.

 hw/xen/xen-host-pci-device.c |   5 ++
 hw/xen/xen-host-pci-device.h |   1 +
 hw/xen/xen_pt.c              | 157 +++++++++++++++++++++++++++----------------
 hw/xen/xen_pt.h              |   2 +
 hw/xen/xen_pt_config_init.c  | 135 ++++++++++++++++++++++++++++++-------
 hw/xen/xen_pt_msi.c          |  18 +++--
 6 files changed, 231 insertions(+), 87 deletions(-)

Konrad Rzeszutek Wilk (8):
      xen/pt: Use xen_host_pci_get_[byte|word] instead of dev.config
      xen/pt: Sync up the dev.config and data values.
      xen/pt: Check if reg->init is past the reg->size
      xen/pt: Log xen_host_pci_get in two init functions
      xen/pt: Log xen_host_pci_get/set errors in MSI code.
      xen/pt: Make xen_pt_unregister_device idempotent
      xen/pt: Move bulk of xen_pt_unregister_device in its own routine.
      xen/pt: Check for return values for xen_host_pci_[get|set] in init




reply via email to

[Prev in Thread] Current Thread [Next in Thread]