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

Re: [Xen-devel] [PATCH] ioreq-server: handle IOREQ_TYPE_PCI_CONFIG in assist function

>>> On 27.01.15 at 20:34, <andrew.cooper3@xxxxxxxxxx> 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.liu2@xxxxxxxxxx>
>> Cc: Jan Beulich <jbeulich@xxxxxxxx>
>> Cc: Paul Durrant <paul.durrant@xxxxxxxxxx>
>> Cc: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>
> 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.)


Xen-devel mailing list



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.