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

Re: [PATCH V5 00/22] IOREQ feature (+ virtio-mmio) on Arm


  • To: Julien Grall <julien@xxxxxxx>, Stefano Stabellini <sstabellini@xxxxxxxxxx>
  • From: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>
  • Date: Thu, 28 Jan 2021 20:10:18 +0000
  • Arc-authentication-results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=citrix.com; dmarc=pass action=none header.from=citrix.com; dkim=pass header.d=citrix.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:X-MS-Exchange-SenderADCheck; bh=sAKv26QV9GxPFLhT/hWdtPSRoZI1RuO9lVHK04vtwrw=; b=cT52E6PhdMxJYkySDMbYCUvqfjB9CNbovApJxCklLJGFXmyB05G9R0R0hCk5HZ2YuzGTovUIu7PIfN1mfeByIFdjzHVhqhbw6TsWAldaJ9DQwWwDLcQ58RA3vArb5iPutv+SjlPqu8IEkrjZS0qNxbhl+9dDxzSrCsMrwZNxGYX+BxfQxOxoznorTI2dBisCQ1DWi8vjriVwR7BEmDB4+fkRuDCdoO/gh7EFIaRWQHuaqC2kTMhn6YnbCITC1k9vKVX5mxyIMkZc7IBd8IY96QI99SHFYALIz88gnnN3ibyJiAEySLrulA8rzD0Wh1bz0nCoVbAFJzF2OCimXlDjLQ==
  • Arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=G9p6+Dcio/MRWYzbC8ixRkLXfF4J8UUfiSbYMEyaoK9TPEeSYVK/pdkyAUwOrIfqvqimge0IBuk8N1GDqw34UuOSpdC4/I7LJT244W9MBZftcnkbxYj21FwdnvM4n3t52othnQnnMQnzwhDWEjjW436ydNrd3UUl4oNI32jKU6Hzpdzh1V3UFntyKFRE4QdwhylrA33OBKtVaiVGKL6kI13aHZjtGOkyo1k7/nTWuLmCZf3gKUmnlKqPQS6oHht0/T9XGGgmC/z1gv+7Nt39t8gakFqqsYGUqx/0/kpBG99GoCJ1Mv5G5fvYeW46NgcN1JnlC6Ko+QVFE3RXepiJCQ==
  • Authentication-results: esa4.hc3370-68.iphmx.com; dkim=pass (signature verified) header.i=@citrix.onmicrosoft.com
  • Cc: Oleksandr Tyshchenko <olekstysh@xxxxxxxxx>, <xen-devel@xxxxxxxxxxxxxxxxxxxx>, Ian Jackson <iwj@xxxxxxxxxxxxxx>, Oleksandr Tyshchenko <oleksandr_tyshchenko@xxxxxxxx>, Paul Durrant <paul@xxxxxxx>, Jan Beulich <jbeulich@xxxxxxxx>, Roger Pau Monné <roger.pau@xxxxxxxxxx>, Wei Liu <wl@xxxxxxx>, Julien Grall <julien.grall@xxxxxxx>, George Dunlap <george.dunlap@xxxxxxxxxx>, Jun Nakajima <jun.nakajima@xxxxxxxxx>, Kevin Tian <kevin.tian@xxxxxxxxx>, Tim Deegan <tim@xxxxxxx>, Daniel De Graaf <dgdegra@xxxxxxxxxxxxx>, Volodymyr Babchuk <Volodymyr_Babchuk@xxxxxxxx>, Bertrand Marquis <bertrand.marquis@xxxxxxx>, Wei Chen <Wei.Chen@xxxxxxx>, Kaly Xin <Kaly.Xin@xxxxxxx>, Artem Mygaiev <joculator@xxxxxxxxx>, Alex Bennée <alex.bennee@xxxxxxxxxx>
  • Delivery-date: Thu, 28 Jan 2021 20:10:37 +0000
  • Ironport-sdr: vqAf0e4FNZub/ri8UM8EW3xxT7ogxZRTEWwFHZnpJ+SbIzVZ7SyfeEd3NxvldjioIUN5/eEr8m Zyi97ocxiJvw538524/uo+zmRpN7hXsUe4fkhwlSlc5DV2LzUBICDIgYAQ8zV5+i+9lBQNwb7w brZf0TT6+vymUnXGJ1qfGcPOlFe/RACg5knV/cDVlKihF5agnOISz4BgGrjREndfObGQhp8WcQ u/KmOuJ6mu84b6Tfh56cIEsh+8W277J9Ud+zkQH2KEnHt6WFX9InDClft+QkqHjsL0XaKAFpO4 1+o=
  • List-id: Xen developer discussion <xen-devel.lists.xenproject.org>

On 28/01/2021 18:16, Julien Grall wrote:
> Hi Andrew,
>
> On 28/01/2021 18:10, Andrew Cooper wrote:
>> On 28/01/2021 17:44, Julien Grall wrote:
>>>
>>>
>>> On 28/01/2021 17:24, Stefano Stabellini wrote:
>>>> On Thu, 28 Jan 2021, Julien Grall wrote:
>>>>> On 25/01/2021 19:08, Oleksandr Tyshchenko wrote:
>>>>>    > Patch series [8] was rebased on recent "staging branch"
>>>>>> (5e31789 tools/ocaml/libs/xb: Do not crash after xenbus is
>>>>>> unmapped) and
>>>>>> tested on
>>>>>> Renesas Salvator-X board + H3 ES3.0 SoC (Arm64) with virtio-mmio
>>>>>> disk
>>>>>> backend [9]
>>>>>> running in driver domain and unmodified Linux Guest running on
>>>>>> existing
>>>>>> virtio-blk driver (frontend). No issues were observed. Guest domain
>>>>>> 'reboot/destroy'
>>>>>> use-cases work properly. Patch series was only build-tested on x86.
>>>>>
>>>>> I have done basic testing with a Linux guest on x86 and I didn't
>>>>> spot any
>>>>> regression.
>>>>>
>>>>> Unfortunately, I don't have a Windows VM in hand, so I can't confirm
>>>>> if there
>>>>> is no regression there. Can anyone give a try?
>>>>>
>>>>> On a separate topic, Andrew expressed on IRC some concern to
>>>>> expose the
>>>>> bufioreq interface to other arch than x86. I will let him explain
>>>>> his view
>>>>> here.
>>>>>
>>>>> Given that IOREQ will be a tech preview on Arm (this implies the
>>>>> interface is
>>>>> not stable) on Arm, I think we can defer the discussion past the
>>>>> freeze.
>>>>
>>>> Yes, I agree that we can defer the discussion.
>>>>
>>>>
>>>>> For now, I would suggest to check if a Device Model is trying to
>>>>> create an
>>>>> IOREQ server with bufioreq is enabled (see ioreq_server_create()).
>>>>> This would
>>>>> not alleviate Andrew's concern, however it would at allow us to
>>>>> judge whether
>>>>> the buffering concept is going to be used on Arm (I can see some use
>>>>> for the
>>>>> Virtio doorbell).
>>>>>
>>>>> What do others think?
>>>>
>>>> Difficult to say. We don't have any uses today but who knows in the
>>>> future.
>>>
>>> I have some ideas, but Andrew so far objects on using the existing
>>> bufioreq interface for good reasons. It is using guest_cmpxchg() which
>>> is really expensive.
>>
>> Worse.  Patch 5 needs to switch cmpxchg() to guest_cmpxchg() to avoid
>> reintroducing XSA-295, but doesn't.
>
> The memory is only shared with the emulator (we don't allow the legacy
> interface on Arm).

Excellent.

> So why do you think it is re-introducing XSA-295?

Because the Xen security model considers "stubdomain can DoS Xen" a
security issue.

Yes - I know that right now, it will only be the hardware domain which
can use acquire_resource on ARM, but eventually we'll fix the
refcounting bug, and lifting the "translate && !hwdom" restriction would
be the thing that actually reintroduces XSA-295.

~Andrew



 


Rackspace

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