On 11/05/2009 08:44 AM, Tian, Kevin wrote: >> From: Avi Kivity >> Sent: 2009年11月3日 12:57 >> >> On 11/03/2009 01:35 AM, Rik van Riel wrote: >> >>>> We can't add an exception vector since all the existing >>>> >> ones are either >> >>>> taken or reserved. >>>> >>> >>> I believe some are reserved for operating system use. >>> >> Table 6-1 says: >> >> 9 | | Coprocessor Segment Overrun (reserved) | Fault | No | >> Floating-point instruction.2 >> 15 | ― | (Intel reserved. Do not use.) | | No | >> 20-31 | ― | Intel reserved. Do not use. | >> 32-255 | ― | User Defined (Non-reserved) Interrupts | Interrupt >> | | External interrupt or INT n instruction. >> >> So we can only use 32-255, but these are not fault-like >> exceptions that >> can be delivered with interrupts disabled. >> >> > would you really want to inject a fault-like exception here? Fault > is architurally synchronous event while here apf is more like an > asynchronous interrupt as it's not caused by guest itself. If > guest is with interrupt disabled, preemption won't happen and > apf path just ends up "wait for page" hypercall to waste cycles. > An async page fault is, despite its name, synchronous, since it is associated with an instruction. It must either be delivered immediately or not at all. It's true that in kernel mode you can't do much with an apf if interrupts are disabled, but you still want to receive apfs for user mode with interrupts disabled (for example due to interrupt shadow). -- 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
