>From: Keir Fraser [mailto:Keir.Fraser@xxxxxxxxxxxx]
>Sent: 2007年2月15日 16:14
>
>Oh, hmmm, it may be that #GP(0) is a very common reason to exit VM86
>mode. I
>expect we print that line every time such an exit happens, and it may not
>actually be a bug at all. It may be that logging line is too noisy, even for
>debug logging level.
>
> -- Keir
Yeah, I just realized this point just now, since injecting GP for VM86
mode also go through that path. So maybe instead we should avoid
that print for vm86_mode at least, or else it's really annoying. But
there's still something I didn't understand fully, and maybe you can
help here.
My basic understanding is that Xen doesn't do much about VM86
mode emulation, and still let monitor in xenlinux to handle that. I
captured all cases which causes those prints, and found two
classes:
1) Privileged instructions to be handled by xenlinux vm86 monitor,
which is normal:
- 9c (PUSHF)
- 9d (POPF)
- cf (IRET)
- f4 (HLT)
Seems that HLT is also not handled by xenlinux, and not sure
whether that will cause any issue.
2) No permission on I/O ports (0xCF8/0xCFC, 0x20e0, 0x20e4)
which is weird:
Seems that this version of VGA bios will try to scan PCI bus.
0x20e0/0x20e4 is the I/O BAR configured for integrated graphics
controller. However I printed all sys_ioperm, and found that Xorg
only requests for [0x0-0x3ff],[0x40-0x43],[0x60-0x63]. Then each
time when above ports are accessed within VM86 mode,
guest_io_okay will fail since related bitmap bits are all 1s. So I'm
interested that why X-windows can still work under such case. Do
you know any path to enable I/O ports specially for VM86 mode?
Thanks,
Kevin
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
Home