[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20200221164151.GD10054@lst.de>
Date: Fri, 21 Feb 2020 17:41:51 +0100
From: Christoph Hellwig <hch@....de>
To: "Michael S. Tsirkin" <mst@...hat.com>
Cc: Halil Pasic <pasic@...ux.ibm.com>,
Jason Wang <jasowang@...hat.com>,
Marek Szyprowski <m.szyprowski@...sung.com>,
Robin Murphy <robin.murphy@....com>,
Christoph Hellwig <hch@....de>, linux-s390@...r.kernel.org,
virtualization@...ts.linux-foundation.org,
linux-kernel@...r.kernel.org, iommu@...ts.linux-foundation.org,
Christian Borntraeger <borntraeger@...ibm.com>,
Janosch Frank <frankja@...ux.ibm.com>,
Viktor Mihajlovski <mihajlov@...ux.ibm.com>,
Cornelia Huck <cohuck@...hat.com>,
Ram Pai <linuxram@...ibm.com>,
Thiago Jung Bauermann <bauerman@...ux.ibm.com>,
David Gibson <david@...son.dropbear.id.au>,
"Lendacky, Thomas" <Thomas.Lendacky@....com>,
Michael Mueller <mimu@...ux.ibm.com>
Subject: Re: [PATCH 0/2] virtio: decouple protected guest RAM form
VIRTIO_F_IOMMU_PLATFORM
On Thu, Feb 20, 2020 at 04:33:35PM -0500, Michael S. Tsirkin wrote:
> So it sounds like a host issue: the emulation of s390 unnecessarily complicated.
> Working around it by the guest looks wrong ...
Yes. If your host (and I don't care if you split hypervisor, ultravisor
and megavisor out in your implementation) wants to support a VM
architecture where the host can't access all guest memory you need to
ensure the DMA API is used. Extra points for simply always setting the
flag and thus future proofing the scheme.
Powered by blists - more mailing lists