Re: KVM handling external interrupts

[Jan Kiszka <jan.kiszka@web.de>]

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

On 2012-06-07 13:49, Abel Gordon wrote:
> 
> 
> Jan Kiszka <jan.kiszka@web.de> wrote on 07/06/2012 14:10:32:
> 
>>> 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?
>>
>> Just found your solution: Append to a PCI bar. That's nasty. Better
>> reserve some memory via e820. There is a paravirtual channel from QEMU
>> to the BIOS to communicate such reservations.
> 
> We will take a look at e820 and consider your suggestion, thanks!
> The PCI BAR worked well to obtain an "unused" and "mapped" memory area
> for unmodified guests.
> 
> Nasty ? Well, as usual, depends who you ask and the alternatives you
> compare with.
> For us, it was an elegant and easy way to achieve the goal.

It's nasty as it requires more interaction between KVM and the userspace
hypervisor and relies on PCI, which has nothing to do with the x86
architecture. Consider you only want to forward non-PCI interrupts (e.g.
the LAPIC timer) and have no assigned device...

> 
>> BTW, the IDTR holds a linear address, not a virtual one. Unless I
>> misremember, there is no need to map the IDT via the page table. The
>> processor will not consult it for reading its entries.
> 
> As I understand and as we noticed in our runs using ELI, the processor
> uses the page tables to translate the IDTR (linear address) into physical
> address (guest physical in this case).
> 
> (1) Logical addresses are converted to linear addresses using segments (not
> relevant in our case)
> (2) Linear addresses are converted to physical addresses using page tables
> (this is our case)
> 
> Am I missing something ? In your case, I assume, [virtual = logical] and
> [linear = linear]
> or you are using some different semantics ?

No, you are right, the descriptor tables run through paging as well.

But how do you ensure that the shadow IDT is mapped where you expect it?
How do you detect where it is mapped? That reminds me of our KVM VAPIC
and the hoops that code has to jump through to ensure this just for
32-bit XP guests...

Jan


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 262 bytes --]