On Tue, Mar 21, 2023 at 08:20:53PM +0800, Roger Pau Monné wrote:
> On Tue, Mar 21, 2023 at 07:49:26PM +0800, Huang Rui wrote:
> > On Tue, Mar 21, 2023 at 06:20:03PM +0800, Jan Beulich wrote:
> > > On 21.03.2023 11:14, Huang Rui wrote:
> > > > On Tue, Mar 21, 2023 at 05:41:57PM +0800, Jan Beulich wrote:
> > > >> On 21.03.2023 10:36, Huang Rui wrote:
> > > >>> On Wed, Mar 15, 2023 at 12:02:35AM +0800, Jan Beulich wrote:
> > > >>>> On 12.03.2023 08:54, Huang Rui wrote:
> > > >>>>> --- a/xen/drivers/vpci/header.c
> > > >>>>> +++ b/xen/drivers/vpci/header.c
> > > >>>>> @@ -392,7 +392,7 @@ static void cf_check bar_write(
> > > >>>>> * Xen only cares whether the BAR is mapped into the p2m, so
> > > >>>>> allow BAR
> > > >>>>> * writes as long as the BAR is not mapped into the p2m.
> > > >>>>> */
> > > >>>>> - if ( bar->enabled )
> > > >>>>> + if ( pci_conf_read16(pdev->sbdf, PCI_COMMAND) &
> > > >>>>> PCI_COMMAND_MEMORY )
> > > >>>>> {
> > > >>>>> /* If the value written is the current one avoid printing
> > > >>>>> a warning. */
> > > >>>>> if ( val != (uint32_t)(bar->addr >> (hi ? 32 : 0)) )
> > > >>>>
> > > >>>> ... bar->enabled doesn't properly reflect the necessary state? It
> > > >>>> generally shouldn't be necessary to look at the physical device's
> > > >>>> state here.
> > > >>>>
> > > >>>> Furthermore when you make a change in a case like this, the
> > > >>>> accompanying comment also needs updating (which might have clarified
> > > >>>> what, if anything, has been wrong).
> > > >>>>
> > > >>>
> > > >>> That is the problem that we start domU at the first time, the enable
> > > >>> flag
> > > >>> will be set while the passthrough device would like to write the real
> > > >>> pcie
> > > >>> bar on the host.
> > > >>
> > > >> A pass-through device (i.e. one already owned by a DomU) should never
> > > >> be allowed to write to the real BAR. But it's not clear whether I'm not
> > > >> misinterpreting what you said ...
> > > >>
> > > >
> > > > OK. Thanks to clarify this. May I know how does a passthrough device
> > > > modify
> > > > pci bar with correct behavior on Xen?
> > >
> > > A pass-through device may write to the virtual BAR, changing where in its
> > > own memory space the MMIO range appears. But it cannot (and may not) alter
> > > where in host memory space the (physical) MMIO range appears.
> > >
> >
> > Thanks, but we found if dom0 is PV domain, the passthrough device will
> > access this function to write the real bar.
>
> I'm very confused now, are you trying to use vPCI with HVM domains?
We are using QEMU for passthrough at this moment.
>
> As I understood it you are attempting to enable PCI passthrough for
> HVM guests from a PVH dom0, but now you say your dom0 is PV?
>
Ah, sorry to make you confused, you're right. I am using PVH dom0 + HVM
domU. But we are comparing passthrough function on PV dom0 + HVM domU as a
reference.
Thanks,
Ray
