On 27.03.2010, at 17:42, Pekka Enberg wrote:

> Hi Alexander,
> 
> Alexander Graf wrote:
>>> I'm continuing my journey through the KVM API documentation and I'm now 
>>> scratching my head on how interrupts, traps, and exceptions are supported 
>>> by the API. I see KVM_CREATE_IRQCHIP and KVM_IRQ_LINE but I'm unable to 
>>> work out how the host is notified of such events. For example, if the guest 
>>> does
>>> 
>>> int $0x10
>> IRQs here mean hardware interrupts. They usually are pushed from host -> 
>> guest. So all you need is a way to tell the guest "you got an interrupt". 
>> Your userspace is the one giving interrupts, so there's no need to an exit.
>> The "int $0x10" instruction describes a software interrupt. These are 
>> handled 100% in guest space.
>>> is there some KVM_EXIT "exit reason" like we have for IO? Is there some 
>>> other mechanism for that? As I haven't yet set up anything related to IRQs 
>>> I can see the host just deadlock on user interrupts.
>> I don't think I quite understand? If there's anything running inside guest 
>> context the host shouldn't be affected at all. Host interrupts always 
>> intercept guest execution.
> 
> OK, so Avi asked me not to look at KVM code or qemu code if I don't 
> understand something in Documentation/kvm/api.txt and instead, complain about 
> it. That might also partly explain why I am so confused.

Oh I see :-). That's an eager goal.

> I'm not talking in host -> guest interrupts but interrupts happening in the 
> _guest_. Now if I understand your explanation correctly, host is not involved 
> in interrupt processing but instead I just need to set up IDTs properly in 
> the guest? That makes sense and explains why guest interrupts are not 
> mentioned in the KVM API documentation at all. ;-)

Heh, yep. SW interrupts run 100% in guest context. Interrupt handling (IDT 
interpretation etc.) also happens in guest context.


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

Reply via email to