[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [RFC PATCH 00/13] Add support for Mirror VM.
From: |
Daniel P . Berrangé |
Subject: |
Re: [RFC PATCH 00/13] Add support for Mirror VM. |
Date: |
Mon, 16 Aug 2021 16:16:30 +0100 |
User-agent: |
Mutt/2.0.7 (2021-05-04) |
On Mon, Aug 16, 2021 at 05:00:21PM +0200, Paolo Bonzini wrote:
> On 16/08/21 16:23, Daniel P. Berrangé wrote:
> > snip
> >
> > > 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.
> >
> > I don't think management apps will accept that approach when pinning
> > guests. They will want control over how many extra vCPU threads are
> > created, what host pCPUs they are pinned to, and what schedular
> > policies might be applied to them.
>
> That doesn't require creating the migration threads at startup, or making
> them vCPU threads, does it?
>
> The migration helper is guest code that is run within the context of the
> migration helper in order to decrypt/re-encrypt the code (using a different
> tweak that is based on e.g. the ram_addr_t rather than the HPA). How does
> libvirt pin migration thread(s) currently?
I don't think we do explicit pinning of migration related threads right
now, which means they'll inherit characteristics of whichever thread
spawns the transient migration thread. If the mgmt app has pinned the
emulator threads to a single CPU, then creating many migration threads
is a waste of time as they'll compete with each other.
I woudn't be needed to create migration threads at startup - we should
just think about how we would identify and control them when created
at runtime. The complexity here is a trust issue - once guest code has
been run, we can't trust what QMP tells us - so I'm not sure how we
would learn what PIDs are associated with the transiently created
migration threads, in order to set their properties.
Regards,
Daniel
--
|: https://berrange.com -o- https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o- https://fstop138.berrange.com :|
|: https://entangle-photo.org -o- https://www.instagram.com/dberrange :|
- [RFC PATCH 08/13] kvm: Add Mirror VM support., (continued)
- [RFC PATCH 08/13] kvm: Add Mirror VM support., Ashish Kalra, 2021/08/16
- [RFC PATCH 09/13] kvm: create Mirror VM and share primary VM's encryption context., Ashish Kalra, 2021/08/16
- [RFC PATCH 10/13] softmmu/cpu: Skip mirror vcpu's for pause, resume and synchronization., Ashish Kalra, 2021/08/16
- [RFC PATCH 11/13] kvm/apic: Disable in-kernel APIC support for mirror vcpu's., Ashish Kalra, 2021/08/16
- [RFC PATCH 12/13] hw/acpi: disable modern CPU hotplug interface for mirror vcpu's, Ashish Kalra, 2021/08/16
- [RFC PATCH 13/13] hw/i386/pc: reduce fw_cfg boot cpu count taking into account mirror vcpu's., Ashish Kalra, 2021/08/16
- Re: [RFC PATCH 00/13] Add support for Mirror VM., Claudio Fontana, 2021/08/16
- Re: [RFC PATCH 00/13] Add support for Mirror VM., Paolo Bonzini, 2021/08/16
- Re: [RFC PATCH 00/13] Add support for Mirror VM., Ashish Kalra, 2021/08/16
- Re: [RFC PATCH 00/13] Add support for Mirror VM., Paolo Bonzini, 2021/08/16
- Re: [RFC PATCH 00/13] Add support for Mirror VM., Ashish Kalra, 2021/08/16
- Re: [RFC PATCH 00/13] Add support for Mirror VM., Paolo Bonzini, 2021/08/16
- Re: [RFC PATCH 00/13] Add support for Mirror VM., Dr. David Alan Gilbert, 2021/08/16
- Re: [RFC PATCH 00/13] Add support for Mirror VM., Ashish Kalra, 2021/08/18
- Re: [RFC PATCH 00/13] Add support for Mirror VM., James Bottomley, 2021/08/18
- Re: [RFC PATCH 00/13] Add support for Mirror VM., Dr. David Alan Gilbert, 2021/08/18
- Re: [RFC PATCH 00/13] Add support for Mirror VM., James Bottomley, 2021/08/18