Re: Nested SVM and migration

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 02/22/2010 07:07 PM, Zachary Amsden wrote:
On 02/22/2010 07:02 AM, Avi Kivity wrote:
On 02/22/2010 07:00 PM, Zachary Amsden wrote:
The force vmexit would generate an INTR #vmexit even if the INTR intercept was disabled and even if no INTR is pending. However this was shot down since there was no equivalent vmx exit reason that we can except the guest to reasonably handle.


While true, my point is more precisely - how can this possibly work for guests which MUST never exit SVM? As in, the hypervisor is broken or deliberately disabled from taking exits, and in fact, may no longer even exist in memory?

These guests will be broken. My assumption was that only malicious guests will disable INTR intercepts (though I can imagine a Luvalley-like system that disables INTR intercepts when running dom0).

Not an SVM expert, but can't you pass through INTR in SVM and leave a fully functioning guest which technically runs under SVM but requires no hypervisor?

You could, but without trapping INTR, you can't reliably multiplex guests or have a hypervisor-controlled network interface. That means you're likely a blue pill thing.

Is that what the Luvalley system does?

Luvalley is vmx only at the moment, but it certainly could let its dom0 handle interrupts (since the scheduler and all device drivers are in dom0). Once it switches to a different guest, it needs to enable INTR.

--
error compiling committee.c: too many arguments to function

--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[Index of Archives]     [KVM ARM]     [KVM ia64]     [KVM ppc]     [Virtualization Tools]     [Spice Development]     [Libvirt]     [Libvirt Users]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite Questions]     [Linux Kernel]     [Linux SCSI]     [XFree86]
  Powered by Linux