On 02/21/2010 04:43 AM, Joerg Roedel wrote:
On Sun, Feb 21, 2010 at 03:40:55PM +0200, Avi Kivity wrote:
On 02/21/2010 03:14 PM, Avi Kivity wrote:
(Either synthetic msrs, or an new state ioctl). The state would
contain a bit that says whether the guest is in guest or host mode.
However, since we're breaking the architecture one way or another,
let's just go with the synthetic INTR intercept.
On the other hand, there is no equivalent intercept in vmx. The
"external interrupt" exit can be configured to run an INTACK cycle and
capture the vector in a vmcs field, and there's no vector we can insert
there (Xen for example uses this).
Difficult. We could use an instruction intercept which has no side
effect on guest state (invlpg for example). But thats a lot more
dangerous than an INTR intercept. What about PENDING_INTERRUPT? Are
there hypervisors that may get confused getting this intercept without
asking for it?
Yes, hypervisors which never mean to handle exits will break. There are
many possible reasons you might design such a hypervisor; security,
non-trivial software lock-out of SVM, special hardware concern, research
project, or perhaps just a shell hypervisor which has one module capable
of handling exits, and one module which doesn't require it, used for
high performance but still maintaining binary compatibility with the
underlying OS.
Perhaps it is just a guest bug, but any design which disallows this is
visibly and fundamentally architecturally broken.
On the other hand, architectural effects of a new state ioctl or MSR
update which is properly implemented are completely invisible to the
guest. I don't have a strong preference which way that is done, but I
do have a very strong preference not to break the architecture.
Zach
--
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
