Re: [RFC PATCH 00/13] Add support for Mirror VM.

From: Paolo Bonzini <pbonzini@redhat.com>
To: "Dr. David Alan Gilbert" <dgilbert@redhat.com>
Cc: Thomas Lendacky <thomas.lendacky@amd.com>,
	Ashish Kalra <Ashish.Kalra@amd.com>,
	Brijesh Singh <brijesh.singh@amd.com>,
	"Habkost, Eduardo" <ehabkost@redhat.com>,
	kvm <kvm@vger.kernel.org>, "S. Tsirkin, Michael" <mst@redhat.com>,
	Tobin Feldman-Fitzthum <tobin@ibm.com>,
	"James E . J . Bottomley" <jejb@linux.ibm.com>,
	Richard Henderson <richard.henderson@linaro.org>,
	qemu-devel <qemu-devel@nongnu.org>,
	Hubertus Franke <frankeh@us.ibm.com>,
	Dov Murik <dovmurik@linux.vnet.ibm.com>
Subject: Re: [RFC PATCH 00/13] Add support for Mirror VM.
Date: Mon, 16 Aug 2021 22:53:19 +0200	[thread overview]
Message-ID: <CABgObfb6JAfs1zeJmPnZAXEO_7_QpaJHqh-xQbvKjgqnOev=Zw@mail.gmail.com> (raw)
In-Reply-To: <YRqfI0YlNZ6Xowwt@work-vm>

[-- Attachment #1: Type: text/plain, Size: 2221 bytes --]

Il lun 16 ago 2021, 19:23 Dr. David Alan Gilbert <dgilbert@redhat.com> ha
scritto:

> > However, I am not sure if the in-guest migration helper vCPUs should use
> the
> > existing KVM support code.  For example, they probably can just always
> work
> > with host CPUID (copied directly from KVM_GET_SUPPORTED_CPUID),
>
> Doesn't at least one form of SEV have some masking of CPUID that's
> visible to the guest; so perhaps we have to match the main vCPUs idea of
> CPUIDs?
>

I don't think we do. Whatever startup code the on the migration helper can
look at CPUID for purposes such as enabling AES instructions. It's a
separate VM and one that will never be migrated (it's started separately on
the source and destination).

> The migration helper can then also use its own address space, for example
> > operating directly on ram_addr_t values with the helper running at very
> high
> > virtual addresses.  Migration code can use a RAMBlockNotifier to invoke
> > KVM_SET_USER_MEMORY_REGION on the mirror VM (and never enable dirty
> memory
> > logging on the mirror VM, too, which has better performance).
>
> How does the use of a very high virtual address help ?
>

Sorry, read that as physical addresses, i.e. the code and any dedicated
migration helper RAM (including communication structures) would be out of
the range used by ram_addr_ts. (The virtual addresses instead can be chosen
by the helper, since QEMU knows nothing about them).

Paolo

> > With this implementation, the number of mirror vCPUs does not even have
> to
> > be indicated on the command line.  The VM and its vCPUs can simply be
> > created when migration starts.  In the SEV-ES case, the guest can even
> > provide the VMSA that starts the migration helper.
> >
> > The disadvantage is that, as you point out, in the future some of the
> > infrastructure you introduce might be useful for VMPL0 operation on
> SEV-SNP.
> > My proposal above might require some code duplication. However, it might
> > even be that VMPL0 operation works best with a model more similar to my
> > sketch of the migration helper; it's really too early to say.
> >
>
> Dave
>
> > Paolo
> >
> --
> Dr. David Alan Gilbert / dgilbert@redhat.com / Manchester, UK
>
>

[-- Attachment #2: Type: text/html, Size: 3283 bytes --]