[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

  • To: Jan Beulich <jbeulich@xxxxxxxx>, Oleksandr Andrushchenko <andr2000@xxxxxxxxx>
  • From: Oleksandr Andrushchenko <Oleksandr_Andrushchenko@xxxxxxxx>
  • Date: Tue, 7 Sep 2021 09:52:16 +0000
  • Accept-language: en-US
  • Arc-authentication-results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=epam.com; dmarc=pass action=none header.from=epam.com; dkim=pass header.d=epam.com; arc=none
  • Arc-message-signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=+ol761Dc91+0hUI/Jo1B4DDOAwiNGaIXzUP1n4/xJDE=; b=Sd2oFJsoJrYc6fz9/hrKGBWkdnTvscWMMZ6dPyztpbqnZmImNdwxjm4LEbbRBsQYOgke7W0ndt9p6ZmCS+uff+SG8cuYzMTVOK7Hlz/+A4cP3xcMQJQZu0o1DVYbZtU2GFA6o8AkKfLM7oAQW+W5DVlO5gC4kAxbUmzpGGKAbHiE9LSEhiYdXRuS5bZ6IwIrU5Xb/dsLHbKYmC1m3gFreN5aXpBWkOxKmGj2vGThNsSKz0wKB5RnyCVbYiUR1akSFiFLPTFH5i1bm40bUZkhW707oWDCGimO9du1SIAj/T27heUYOsjqY4RCrmRhaAOT95UAE0f919zm/YA/TRvqfA==
  • Arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=jK7A8sAL19CiTLD3ZU6JXJHyA2iHkaS+uQeSNQi0nDL/oyZSmdhku4rxDffaQyY/EcxelDcXiE7h0DU8H+6m1I3HvzXvbbMPsucKSUt3WwbWz+KiFojcErDaOTnDZw5yBPnD+rFWfmtTUNQU4DlbFty7ok2XJSjqHBEIt2P1MCq2o8rezPzapNlwgc7GFK3lA9Dt+P/S/y5CSLSOtU+tiv5/K9YzhT8UKicyNo/iwUsv+WfmMGUqGbu38DyoZqgjAae9/N6U/JUinPkrg6xP5MoDWY7wlwwGRIES4bx9D5cXh7PtaUiOrGZgZo1DVtXh8soyGIqInh/IJ6mjxFIyfQ==
  • Authentication-results: suse.com; dkim=none (message not signed) header.d=none;suse.com; dmarc=none action=none header.from=epam.com;
  • Cc: "julien@xxxxxxx" <julien@xxxxxxx>, "sstabellini@xxxxxxxxxx" <sstabellini@xxxxxxxxxx>, Oleksandr Tyshchenko <Oleksandr_Tyshchenko@xxxxxxxx>, Volodymyr Babchuk <Volodymyr_Babchuk@xxxxxxxx>, Artem Mygaiev <Artem_Mygaiev@xxxxxxxx>, "roger.pau@xxxxxxxxxx" <roger.pau@xxxxxxxxxx>, Bertrand Marquis <bertrand.marquis@xxxxxxx>, Rahul Singh <rahul.singh@xxxxxxx>, "xen-devel@xxxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxxx>
  • Delivery-date: Tue, 07 Sep 2021 09:52:40 +0000
  • List-id: Xen developer discussion <xen-devel.lists.xenproject.org>
  • Thread-topic: [PATCH 8/9] vpci/header: Reset the command register when adding devices

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(?),
>> 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 

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

> Jan
Thank you,




Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.