From mboxrd@z Thu Jan  1 00:00:00 1970
From: Andrew Cooper <andrew.cooper3@citrix.com>
Subject: Re: [PATCH] ioreq-server: handle IOREQ_TYPE_PCI_CONFIG
 in assist function
Date: Tue, 27 Jan 2015 19:34:54 +0000
Message-ID: <54C7E85E.2090100@citrix.com>
References: <1422385589-17316-1-git-send-email-wei.liu2@citrix.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Return-path: <xen-devel-bounces@lists.xen.org>
In-Reply-To: <1422385589-17316-1-git-send-email-wei.liu2@citrix.com>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org
To: Wei Liu <wei.liu2@citrix.com>, xen-devel@lists.xen.org
Cc: Paul Durrant <paul.durrant@citrix.com>, Jan Beulich <jbeulich@suse.com>
List-Id: xen-devel@lists.xenproject.org

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@citrix.com>
> Cc: Jan Beulich <jbeulich@suse.com>
> Cc: Paul Durrant <paul.durrant@citrix.com>
> Cc: Andrew Cooper <andrew.cooper3@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 )