This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
Home Products Support Community News


Re: [Xen-devel] [PATCH] ioemu: passthough: add no_wb option for pci conf

To: Qing He <qing.he@xxxxxxxxx>
Subject: Re: [Xen-devel] [PATCH] ioemu: passthough: add no_wb option for pci conf write
From: Stefano Stabellini <stefano.stabellini@xxxxxxxxxxxxx>
Date: Mon, 9 Nov 2009 10:34:34 +0000
Cc: "xen-devel@xxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxx>, Ian Jackson <Ian.Jackson@xxxxxxxxxxxxx>
Delivery-date: Mon, 09 Nov 2009 02:33:43 -0800
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <20091109030345.GA16917@ub-qhe2>
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
References: <20091106091756.GA29376@ub-qhe2> <19188.26651.778508.710707@xxxxxxxxxxxxxxxxxxxxxxxx> <20091109030345.GA16917@ub-qhe2>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
User-agent: Alpine 2.00 (DEB 1167 2008-08-23)
On Mon, 9 Nov 2009, Qing He wrote:
> The data and address registers is the sole way to update MSI vector and
> affinity (at least when not using intremap), but the problem here is
> that QEmu overwrite the hypervisor changes using stale data.
> As we know, guest MSI is virtual, this means guest MSI address and data
> are all emulated, and guest vector has nothing to do with real vector.
> QEmu needs to map and bind MSI through Xen. via the following two calls:
>       xc_physdev_map_pirq_msi
>       xc_domain_bind_pt_irq
> The physical content of MSI data/address is then decided and written by Xen.
> xc_physdev_map_pirq_msi is also used to update guest MSI, including vector
> and affinity.
> Now come to the pt_pci_write_config logic:
>       pci_read_block(&read_val);
>       reg->u.dw.write(read_val, &val);   // the handler
>       pci_write_block(val);
> Since MSI data/address is fully emulated, val always equals to read_val,
> i.e. write what is read back to the register. This would be OK for most of
> the time, however, when the guest changes MSI affinity, something happens
> between read and write. the handler calls xc_physdev_map_pirq_msi to update
> the MSI, hypervisor changes the affinity and write a new vector/affinity
> to the real registers. When the handler returns, pci_write_block(val)
> overwrites the real registers, all the HV changes are lost, making the
> MSI fail.

If "val always equals to read_val", why do we need to call
pci_write_block at all?

Xen-devel mailing list