On Mon, Jul 15, 2019 at 07:03:03PM -0300, Thiago Jung Bauermann wrote:

Michael S. Tsirkin [off-list ref] writes:

quoted

On Mon, Jul 15, 2019 at 05:29:06PM -0300, Thiago Jung Bauermann wrote:

quoted

Michael S. Tsirkin [off-list ref] writes:

quoted

On Sun, Jul 14, 2019 at 02:51:18AM -0300, Thiago Jung Bauermann wrote:

quoted

Michael S. Tsirkin [off-list ref] writes:

quoted

So this is what I would call this option:

VIRTIO_F_ACCESS_PLATFORM_IDENTITY_ADDRESS

and the explanation should state that all device
addresses are translated by the platform to identical
addresses.

In fact this option then becomes more, not less restrictive
than VIRTIO_F_ACCESS_PLATFORM - it's a promise
by guest to only create identity mappings,
and only before driver_ok is set.
This option then would always be negotiated together with
VIRTIO_F_ACCESS_PLATFORM.

Host then must verify that
1. full 1:1 mappings are created before driver_ok
    or can we make sure this happens before features_ok?
    that would be ideal as we could require that features_ok fails
2. mappings are not modified between driver_ok and reset
    i guess attempts to change them will fail -
    possibly by causing a guest crash
    or some other kind of platform-specific error

I think VIRTIO_F_ACCESS_PLATFORM_IDENTITY_ADDRESS is good, but requiring
it to be accompanied by ACCESS_PLATFORM can be a problem. One reason is
SLOF as I mentioned above, another is that we would be requiring all
guests running on the machine (secure guests or not, since we would use
the same configuration for all guests) to support it. But
ACCESS_PLATFORM is relatively recent so it's a bit early for that. For
instance, Ubuntu 16.04 LTS (which is still supported) doesn't know about
it and wouldn't be able to use the device.

OK and your target is to enable use with kernel drivers within
guests, right?

Right.

quoted

My question is, we are defining a new flag here, I guess old guests
then do not set it. How does it help old guests? Or maybe it's
not designed to ...

Indeed. The idea is that QEMU can offer the flag, old guests can reject
it (or even new guests can reject it, if they decide not to convert into
secure VMs) and the feature negotiation will succeed with the flag
unset.

OK. And then what does QEMU do? Assume guest is not encrypted I guess?

There's nothing different that QEMU needs to do, with or without the
flag. the perspective of the host, a secure guest and a regular guest
work the same way with respect to virtio.

OK. So now let's get back to implementation. What will
Linux guest driver do? It can't activate DMA API blindly since that
will assume translation also works, right?
Or do we somehow limit it to just a specific platform?

--
Thiago Jung Bauermann
IBM Linux Technology Center