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

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> 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.)

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel