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.
A Qemu stubdom is a PV guest, not an HVM one, so will not be triggering
this path in Xen. It is HVMLoader which scans the PCI bus.
I presume, given the description, that in the case that a Qemu stubdom
is used (as opposed to a dom0 qemu), it is not registered as the default
ioreq server, causing Xen to complete the config cycles (and incorrectly
return 0 instead of ~0)?
~Andrew
> ---
> xen/arch/x86/hvm/hvm.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/xen/arch/x86/hvm/hvm.c b/xen/arch/x86/hvm/hvm.c
> index c7984d1..c826ac5 100644
> --- a/xen/arch/x86/hvm/hvm.c
> +++ b/xen/arch/x86/hvm/hvm.c
> @@ -2577,6 +2577,7 @@ static bool_t hvm_complete_assist_req(ioreq_t *p)
> {
> case IOREQ_TYPE_COPY:
> case IOREQ_TYPE_PIO:
> + case IOREQ_TYPE_PCI_CONFIG:
> if ( p->dir == IOREQ_READ )
> {
> if ( !p->data_is_ptr )
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
