Re: [PATCH 8/9] vpci/header: Reset the command register when adding devices

[Oleksandr Andrushchenko <Oleksandr_Andrushchenko@xxxxxxxx>]

On 07.09.21 12:19, Jan Beulich wrote:
> On 07.09.2021 11:07, Oleksandr Andrushchenko wrote:
>> On 07.09.21 11:49, Jan Beulich wrote:
>>> On 07.09.2021 10:18, Oleksandr Andrushchenko wrote:
>>>> So, if we have a hidden PCI device which can be assigned to a guest and it 
>>>> is literally untouched
>>>> (not enabled in Dom0) then I think there will be no such reference as 
>>>> "host assigned values" as
>>>> most probably the command register will remain in its after reset state.
>>> What meaning of "hidden" do you imply here? Devices passed to
>>> pci_{hide,ro}_device() may not be assigned to guests ...
>> You are completely right here.
>>> For any other meaning of "hidden", even if the device is completely
>>> ignored by Dom0,
>> Dom0less is such a case when a device is assigned to the guest
>> without Dom0 at all?
> In this case it is entirely unclear to me what entity it is to have
> a global view on the PCI subsystem.
>
>>>    certain of the properties still cannot be allowed
>>> to be DomU-controlled.
>> The list is not that big, could you please name a few you think cannot
>> be controlled by a guest? I can think of PCI_COMMAND_SPECIAL(?),
>> PCI_COMMAND_INVALIDATE(?), PCI_COMMAND_PARITY, PCI_COMMAND_WAIT,
>> PCI_COMMAND_SERR, PCI_COMMAND_INTX_DISABLE which we may want to
>> be aligned with the "host reference" values, e.g. we only allow those bits
>> to be set as they are in Dom0.
> Well, you've compile a list already, and I did say so before as well:
> Everything except I/O and memory decoding as well as bus mastering
> needs at least closely looking at. INTX_DISABLE, for example, is
> something I don't think a guest should be able to directly control.
> It may still be the case that the host permits it control, but then
> only indirectly, allowing the host to appropriately adjust its
> internals.
>
> Note that even for I/O and memory decoding as well as bus mastering
> it may be necessary to limit guest control: In case the host wants
> to disable any of these (perhaps transiently) despite the guest
> wanting them enabled.

Ok, so it is now clear that we need a yet another patch to add a proper

command register emulation. What is your preference: drop the current

patch, implement command register emulation and add a "reset patch"

after that or we can have the patch as is now, but I'll only reset IO/mem and 
bus

master bits, e.g. read the real value, mask the wanted bits and write back?

>
> Jan
>
Thank you,

Oleksandr