Re: [RFC XEN PATCH 2/6] vpci: accept BAR writes if dom0 is PVH

[Jan Beulich <jbeulich@suse.com>]

On 21.03.2023 13:20, 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?
> 
> 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?

I didn't read it like this. Instead my way of understanding the reply
is that they try to mimic on PVH Dom0 what they observe on PV Dom0.

Jan