Jan Kiszka <jan.kiszka@xxxxxx> wrote on 07/06/2012 13:51:19: > >> My first feeling is that it's not easily upstreamable due to the need to > >> fiddle with the host's IDT, specifically on VCPU task migration. But I > >> need to read the requirements of this more carefully. Still interesting > >> work! > > > > You don't need to fiddle with the host's IDT, you need to fiddle with > > the shadow IDT and interrupt vector mapping/remapping. > > Yes, but you need to sync the host IDT into the shadow table. This may > require some hooks in generic code to avoid scanning the host table on > each guest entry. Well, the shadow IDT only needs to be synced with interrupts coming from assigned devices. The rest of the entries doesn't matter, they just generate an exception. Once they generate an exception, they are delivered through the host IDT. So, all you need to know are the vectors assigned to the guest to build the shadow IDT. > BTW, the shadow IDT has to be put in the guest address space, right? So > we need to make it read-only for the guest? Yes, the shadow IDT is mapped into the guest address space and write-protected in case a malicious guest tries to change it. In addition, you also need to write protect the "guest IDT" to catch any changes the guest could made that need to be reflected in the shadow IDT (e.g. handlers for assigned vectors or exceptions). However, this is a rare case and does not occur during normal execution. -- 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