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

Re: [PATCH v5 01/11] xen/arm: xc_domain_ioport_permission(..) not supported on ARM.

  • To: Jan Beulich <jbeulich@xxxxxxxx>, Bertrand Marquis <bertrand.marquis@xxxxxxx>
  • From: Oleksandr Andrushchenko <Oleksandr_Andrushchenko@xxxxxxxx>
  • Date: Tue, 12 Oct 2021 10:06:04 +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:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=bAAKj+mjbcLNrefHOaYAJNKi82rGpZcHncXHCee6OO0=; b=KgVVulVSGxX0njJG+7JxyVlwsenhk70fC7KD6rSemqBleQcbRIbzTRyznOm8EIdarHC1SF3+xDPNp2aCPahnMqkoZQDXGWF8dOD70qRg2+B2RCGLQ8XTf+jvpL+oLtkQRe+CIo9Ef95wxxPe7Nw6V6Kg7VSjxrBQGHC50H+SjSZ9UBuNliBPJ1fZf/J7u5ZlkJz+aQfYiLEkIK5nZAWlFG0OaHJZMVz/LCfS+TY1sZZT2S1WuSuAYDxnUMGQ9mghP1VxyxDNzI7pvKZqA4v++Ofpq2Be/xztMB/G0YSr6mdlUBxFwdhYhx4HH4yFcxk67AiiNpKKcxI9A3b31ULIag==
  • Arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=d/OPV1dJ4KnMjkycXbxXo7gMG5I2TWoXJWSA9d2ScmiicElIrD+M/m6f/vCcKs/p18q9JlMid7bXKIHJCRY8mYYMybJ4qa7IUgE4u+dMmwF9nOviTQJyN3RNMQfN78tLWc3NyXLooyK+DiBykQXrjlDkUOdzesYr/UbIVql3nqus7E478FHXzPG3DOEmkSEY1GxbBaQpIpVTZwM4MkOOir5IPYGScWoAIfZ6TqQC/hUpUmpy5qmkC5LK1L9trG0nV48tyoO6S89uZ+7iXp5h+rXdCbuVXL7jNCk+IKIA0jx4bzzNJ5nMznnr01oQ0/p4I+5MKWZDOqlXr9jNAmCx7A==
  • Authentication-results: suse.com; dkim=none (message not signed) header.d=none;suse.com; dmarc=none action=none header.from=epam.com;
  • Cc: Rahul Singh <rahul.singh@xxxxxxx>, "xen-devel@xxxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxxx>, Andre Przywara <Andre.Przywara@xxxxxxx>, Ian Jackson <iwj@xxxxxxxxxxxxxx>, Wei Liu <wl@xxxxxxx>, Juergen Gross <jgross@xxxxxxxx>, Stefano Stabellini <sstabellini@xxxxxxxxxx>, Roger Pau Monné <roger.pau@xxxxxxxxxx>, Oleksandr Andrushchenko <Oleksandr_Andrushchenko@xxxxxxxx>
  • Delivery-date: Tue, 12 Oct 2021 10:06:17 +0000
  • List-id: Xen developer discussion <xen-devel.lists.xenproject.org>
  • Thread-topic: [PATCH v5 01/11] xen/arm: xc_domain_ioport_permission(..) not supported on ARM.

On 12.10.21 13:01, Jan Beulich wrote:
> On 12.10.2021 11:38, Oleksandr Andrushchenko wrote:
>> On 12.10.21 12:32, Jan Beulich wrote:
>>> On 12.10.2021 10:41, Bertrand Marquis wrote:
>>>>> On 12 Oct 2021, at 09:29, Jan Beulich <jbeulich@xxxxxxxx> wrote:
>>>>> On 11.10.2021 19:11, Bertrand Marquis wrote:
>>>>>>> On 11 Oct 2021, at 17:32, Roger Pau Monné <roger.pau@xxxxxxxxxx> wrote:
>>>>>>> On Mon, Oct 11, 2021 at 02:16:19PM +0000, Bertrand Marquis wrote:
>>>>>>>>> On 11 Oct 2021, at 14:57, Roger Pau Monné <roger.pau@xxxxxxxxxx> 
>>>>>>>>> wrote:
>>>>>>>>> I think the commit message needs to at least be expanded in order to
>>>>>>>>> contain the information provided here. It might also be helpful to
>>>>>>>>> figure out whether we would have to handle IO port accesses in the
>>>>>>>>> future on Arm, or if it's fine to just ignore them.
>>>>>>>> All our investigations and tests have been done without supporting it
>>>>>>>> without any issues so this is not a critical feature (most devices can
>>>>>>>> be operated without using the I/O ports).
>>>>>>> IMO we should let the users know they attempted to use a device with
>>>>>>> BARs in the IO space, and that those BARs won't be accessible which
>>>>>>> could make the device not function as expected.
>>>>>>> Do you think it would be reasonable to attempt the hypercall on Arm
>>>>>>> also, and in case of error (on Arm) just print a warning message and
>>>>>>> continue operations as normal?
>>>>>> I think this would lead to a warning printed on lots of devices where in
>>>>>> fact there would be no issues.
>>>>>> If this is an issue for a device driver because it cannot operate without
>>>>>> I/O ports, this will be raised by the driver inside the guest.
>>>>> On what basis would the driver complain? The kernel might know of
>>>>> the MMIO equivalent for ports, and hence might allow the driver
>>>>> to properly obtain whatever is needed to later access the ports.
>>>>> Just that the port accesses then wouldn't work (possibly crashing
>>>>> the guest, or making it otherwise misbehave).
>>>> As ECAM and Arm does not support I/O ports, a driver requesting access
>>>> to them would get an error back.
>>>> So in practice it is not possible to try to access the ioports as there is 
>>>> no
>>>> way on arm to use them (no instructions).
>>>> A driver could misbehave by ignoring the fact that ioports are not there 
>>>> but
>>>> I am not quite sure how we could solve that as it would be a bug in the 
>>>> driver.
>>> The minimal thing I'd suggest (or maybe you're doing this already)
>>> would be to expose such BARs to the guest as r/o zero, rather than
>>> letting their port nature "shine through".
>> If we have the same, but baremetal then which entity disallows
>> those BARs to shine?
> I'm sorry, but I don't understand what you're trying to say.
>> I mean that if guest wants to crash... why
>> should we stop it and try emulating something special for it?
> This isn't about a guest "wanting to crash", but a driver potentially
> getting mislead into thinking that it can driver a device a certain
> way.
Well, for the guest, as we do not advertise IO in the emulated host
bridge, the driver won't be able to allocate any IO at all. Thus, even
if we have a BAR with PCI_BASE_ADDRESS_SPACE_IO bit set, the
driver won't get anything. So, I think this is equivalent to a baremetal
use-case where we have no IO supported by the host bridge and
a device with IO BAR.
> Jan



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