[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20190205072407.GA4311@lst.de>
Date: Tue, 5 Feb 2019 08:24:07 +0100
From: Christoph Hellwig <hch@....de>
To: "Michael S. Tsirkin" <mst@...hat.com>
Cc: Thiago Jung Bauermann <bauerman@...ux.ibm.com>,
Christoph Hellwig <hch@....de>,
Jason Wang <jasowang@...hat.com>,
virtualization@...ts.linux-foundation.org,
linuxppc-dev@...ts.ozlabs.org, iommu@...ts.linux-foundation.org,
linux-kernel@...r.kernel.org,
David Gibson <david@...son.dropbear.id.au>,
Alexey Kardashevskiy <aik@...ux.ibm.com>,
Paul Mackerras <paulus@...abs.org>,
Benjamin Herrenschmidt <benh@...nel.crashing.org>,
Ram Pai <linuxram@...ibm.com>,
Jean-Philippe Brucker <jean-philippe.brucker@....com>
Subject: Re: [RFC PATCH] virtio_ring: Use DMA API if guest memory is
encrypted
On Mon, Feb 04, 2019 at 04:38:21PM -0500, Michael S. Tsirkin wrote:
> It was designed to make, when set, as many guests as we can work
> correctly, and it seems to be successful in doing exactly that.
>
> Unfortunately there could be legacy guests that do work correctly but
> become slow. Whether trying to somehow work around that
> can paint us into a corner where things again don't
> work for some people is a question worth discussing.
The other problem is that some qemu machines just throw passthrough
devices and virtio devices on the same virtual PCI(e) bus, and have a
common IOMMU setup for the whole bus / root port / domain. I think
this is completely bogus, but unfortunately it is out in the field.
Given that power is one of these examples I suspect that is what
Thiago referes to. But in this case the answer can't be that we
pile on hack ontop of another, but instead introduce a new qemu
machine that separates these clearly, and make that mandatory for
the secure guest support.
Powered by blists - more mailing lists