[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [PATCH RFC v2] vPCI: account for hidden devices
- To: Stefano Stabellini <sstabellini@xxxxxxxxxx>
- From: Roger Pau Monné <roger.pau@xxxxxxxxxx>
- Date: Thu, 25 May 2023 09:35:00 +0200
- 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-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=JMTB9KDiY/p0p9NLr52mvTizmfg6ZizPVRJTlPx83uo=; b=ICSQb0qRWUFMm7dGF8jEfsZz9kpLLMvXbyZXY796qt99m7x2BA6/Q2D2nKUj0w+2hhKcJVsYqJG8IAloHnFKvDfS14bu9ym8mCwmpUvIK7ufMmre+DZrGs3alhFYQypFbnOJo8hrpGvge9tTGFWJyp7MVYxORRHj8aCBSIxHQUHqBi4B/vmXsQ1R/yAKFEjZ7FNMT8Zzmz+chK97+UxWru9NroI8vi1hnfxNRTu11irl6l1+fUFkec/qJ0NXaVDuUh2mEQTa+4o7vKU5uCurrIremg5cfo/s79U0OQAaKd+1wsFSSxMOduFVwnYXFtDIve0a9tIXVkzEFRU5MikW/w==
- Arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=fG0kSGpzqJfdHQM91nVG+ZjejKvEVAYF9GLlMZU2sselI+eqNnno3tmR4J5d9q0T4M/IrGM/wzrZAclBnQoXyokuSgwyi4VriLGis3wtTdLjp8h+0ASnqR6OhhON545jKIcfNz7nLMnK293bcp4PJ56vfH4cFYJ7BRRrG5rKf8xIi+GyH5PIkuH+/S6SDrbvjLrEGW3qEQQX3Ai1nVFiwy9Cb+XiVPQCn4ZEt4KoCNQk+b8KaN1UAW3fXV3mgEPTYCCealjggAWrH8BIJHhh4ZUvqO65Jj2f3MVB+YbM/qTDMBmjYQeDfi3dSdqsLSMsypNBJx278puTcF7XOb0kyw==
- Authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=citrix.com;
- Cc: Jan Beulich <jbeulich@xxxxxxxx>, "xen-devel@xxxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxxx>
- Delivery-date: Thu, 25 May 2023 07:35:39 +0000
- Ironport-data: A9a23:pUqmiq5SBUE02ySHrY6PFgxRtBLGchMFZxGqfqrLsTDasY5as4F+v mceUG2FaPiLMTHyc9Bza4229BlXuJ/RzIRrSldsqiswHi5G8cbLO4+Ufxz6V8+wwm8vb2o8t plDNYOQRCwQZiWBzvt4GuG59RGQ7YnRGvynTraCYnsrLeNdYH9JoQp5nOIkiZJfj9G8Agec0 fv/uMSaM1K+s9JOGjt8B5mr9lU35JwehBtC5gZlPa0R4AeC/5UoJMl3yZ+ZfiOQrrZ8RoZWd 86bpJml82XQ+QsaC9/Nut4XpWVTH9Y+lSDX4pZnc/DKbipq/0Te4Y5iXBYoUm9Fii3hojxE4 I4lWapc6+seFvakdOw1C3G0GszlVEFM0OevzXOX6aR/w6BaGpdFLjoH4EweZOUlFuhL7W5m6 v1HBRoNKSK/psmk/JyeQ9lJ2toFBZy+VG8fkikIITDxK98DGMmGaYOaoNhS0XE3m9xEGuvYa 4wBcz1zYR/cYhpJfFAKFJY5m+TujX76G9FagAvN+exrvC6OnEoojuiF3Nn9I7RmQe1PmUmVv CTe9nnRCRAGLt2PjzGC9xpAg8eWxXKjCdlOTeDQGvhCvlOw+2cMVwwqVBilrNiQtheGd+58J BlBksYphe1onKCxdfHmRAGxqnOAuh8aWvJTHvc85QXLzbDbiy6bDGUZSj9KaPQ9qdQ7Azct0 zehj97vQDBirrCRYXac7auP6yO/PzAPKm0PbjNCShEKi+QPu6k2hxPLC9xlQKi8i4SsHSmqm m7a6i8jm78UkMgHkb2h+kzKiC6toZ6PSRMp4gLQXSSu6QYRiJOZWrFEIGPztZ5oRLt1hHHa1 JTYs6ByNNwzMKw=
- Ironport-hdrordr: A9a23:F3+aXKpXomFuMOrXeoMklmUaV5rveYIsimQD101hICG9Evb0qy nOpoV/6faQslwssR4b9uxoVJPvfZq+z+8W3WByB9eftWDd0QPFEGgL1+DfKlbbak7DH4BmtJ uJc8JFeafN5VoRt7eG3OFveexQvOVu88qT9JjjJ28Gd3APV0n5hT0JcjpyFCdNNW57LKt8Lr WwzOxdqQGtfHwGB/7LfUXsD4D41rv2fIuNW29+OyIa
- List-id: Xen developer discussion <xen-devel.lists.xenproject.org>
On Wed, May 24, 2023 at 04:37:42PM -0700, Stefano Stabellini wrote:
> On Wed, 24 May 2023, Jan Beulich wrote:
> > >> RFC: _setup_hwdom_pci_devices()' loop may want splitting: For
> > >> modify_bars() to consistently respect BARs of hidden devices while
> > >> setting up "normal" ones (i.e. to avoid as much as possible the
> > >> "continue" path introduced here), setting up of the former may want
> > >> doing first.
> > >
> > > But BARs of hidden devices should be mapped into dom0 physmap?
> >
> > Yes.
>
> The BARs would be mapped read-only (not read-write), right? Otherwise we
> let dom0 access devices that belong to Xen, which doesn't seem like a
> good idea.
It's my understanding that Xen will mark any regions of the BARs
in-use by the hypervisor as read-only, but the rest will be writable.
> But even if we map the BARs read-only, what is the benefit of mapping
> them to Dom0? If Dom0 loads a driver for it and the driver wants to
> initialize the device, the driver will crash because the MMIO region is
> read-only instead of read-write, right?
I think USB is a good example, Xen uses the debug functionality of
EHCI/XHCI, but by marking the device as hidden it allows dom0 to also
make use of any remaining USB ports.
For r/o devices I don't see much point in mapping the BARs to dom0, as
dom0 is not allowed to size them in the first place, so will be able
to detect the BAR position, but not the BAR size. I guess this could
cause issues in the future if dom0 starts repositioning BARs, but
let's leave that aside.
> How does this device hiding work for dom0? How does dom0 know not to
> access a device that is present on the PCI bus but is used by Xen?
I think the objective for hidden is to allow dom0 to use the device,
but Xen should protect any MMIO region it doesn't want dom0 to
modify.
> The reason why I was suggesting to hide the device completely in the
> past was that I assumed we had to hide the device (make it "disappear"
> on the PCI bus) otherwise Dom0 would access it. Is there another way to
> mark a PCI devices as "inaccessible" or "disabled"?
I'm not aware of anything else, short of using stuff like the ACPI
STAO and reporting disabled devices there in addition of marking their
config space as r/o.
Thanks, Roger.
|