>>> On 27.01.15 at 20:34, <andrew.coop...@citrix.com> wrote: > On 27/01/15 19:06, Wei Liu wrote: >> QEMU stubdom will read PCI config space when enumerating PCI devices. >> Xen should return ~0 when there is no suitable ioreq server to dispatch >> the request. >> >> Without this patch, QEMU stubdom will fail to start because hvmloader >> fails following assertion: >> >> 118 ASSERT((devfn != PCI_ISA_DEVFN) || >> 119 ((vendor_id == 0x8086) && (device_id == 0x7000))); >> >> because vendor_id and device_id are 0. >> >> This fixes a regression for QEMU stubdom. It should be backported to 4.5 >> as well. >> >> Signed-off-by: Wei Liu <wei.l...@citrix.com> >> Cc: Jan Beulich <jbeul...@suse.com> >> Cc: Paul Durrant <paul.durr...@citrix.com> >> Cc: Andrew Cooper <andrew.coop...@citrix.com> > > The patch is clearly a good bugfix, but I am not sure the commit message > is accurate.
Nor am I convinced that this is the only place to fix. hvmloader assuming to get back ~0 is contrary to various other code also taking 0 in vendor or device IDs as a sign to skip the device. (Looking at the surrounding code I'm also puzzled by all the pci_write?()-s in that bus scanning loop: Most if not all of them should be done by the BIOS, not hvmloader. But of course that's the case for the BAR setup further down too.) Jan _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
