On 20.10.2009, at 15:19, Jan Kiszka wrote:
Alexander Graf wrote:
On 20.10.2009, at 15:01, Jan Kiszka wrote:
Hi all,
as the list of yet user-unaccessible x86 states is a bit volatile
ATM,
this is an attempt to collect the precise requirements for
additional
state fields. Once everyone feels the list is complete, we can
decide
how to partition it into one ore more substates for the new
KVM_GET/SET_VCPU_STATE interface.
What I read so far (or tried to patch already):
- nmi_masked
- nmi_pending
- nmi_injected
- kvm_queued_exception (whole struct content)
- KVM_REQ_TRIPLE_FAULT (from vcpu.requests)
Unclear points (for me) from the last discussion:
- sipi_vector
- MCE (covered via kvm_queued_exception, or does it require more?)
Please extend or correct the list as required.
hflags. Qemu supports GIF, kvm supports GIF, but no side knows how to
sync it.
OK. Whole hflags or just the GIF bit?
agraf@busu:~/git/kvm> grep -R HF_ arch/x86/include/asm/*kvm*
arch/x86/include/asm/kvm_host.h:#define HF_GIF_MASK (1 << 0)
arch/x86/include/asm/kvm_host.h:#define HF_HIF_MASK (1 << 1)
arch/x86/include/asm/kvm_host.h:#define HF_VINTR_MASK (1 << 2)
arch/x86/include/asm/kvm_host.h:#define HF_NMI_MASK (1 << 3)
arch/x86/include/asm/kvm_host.h:#define HF_IRET_MASK (1 << 4)
I can only talk for GIF here and that should be fine. Not knowing
about the others does seem like we could get race conditions though.
If we allow access to all bits, can user space cause any problems
(beyond screwing up its guests) by passing weird patterns?
IMHO the hflags should be converted between userspace and kernel
representation. There's a good chance we run older userspace that
doesn't know about certain flags yet and I'd like to keep the bits as
flexible as possible.
Alex
--
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
