Taken fault at bad CS c000...

Taken fault at bad CS c000...

[Tian, Kevin]

Just saw such warnings like:
...
(XEN) printk: 387824 messages suppressed.
(XEN) seg_fixup.c:282: Taken fault at bad CS c000, IP 00003aab
(XEN) seg_fixup.c:282: Taken fault at bad CS c000, IP 00003ab2
(XEN) seg_fixup.c:282: Taken fault at bad CS c000, IP 00003aab
(XEN) seg_fixup.c:282: Taken fault at bad CS c000, IP 00003ab2
...

It only jumped out when switching to/off X-windows within dom0, 
and seems that guest is in vm86 mode for executing VGABIOS 
code. System is still running good except such warning...

Xen-unstable has no such issue, which just happens on my local 
version with PM patch sets. Though it's very likely to do with my 
local changes, these changes are assumed to have no impact on 
normal system running. So can anybody help a bit about 
possible cause for such warning? Does it mean something wrong 
in emulate_privilege_op before gpf_emulate_4gb?

Thanks,
Kevin

Re: Taken fault at bad CS c000...

[Keir Fraser]

On 13/2/07 11:55, "Tian, Kevin" <kevin.tian@intel.com> wrote:

> Xen-unstable has no such issue, which just happens on my local
> version with PM patch sets. Though it's very likely to do with my
> local changes, these changes are assumed to have no impact on
> normal system running. So can anybody help a bit about
> possible cause for such warning? Does it mean something wrong
> in emulate_privilege_op before gpf_emulate_4gb?

You've screwed something up so you are taking #GP(0) faults from vm86 mode.
The warnings from Xen are only debug-level and are a side effect of this.

So you need to investigate why these faults are happening in the first
place.

 -- Keir

RE: Taken fault at bad CS c000...

[Tian, Kevin]

>From: Keir Fraser [mailto:Keir.Fraser@cl.cam.ac.uk]
>Sent: 2007年2月14日 17:41
>
>
>On 13/2/07 11:55, "Tian, Kevin" <kevin.tian@intel.com> wrote:
>
>> Xen-unstable has no such issue, which just happens on my local
>> version with PM patch sets. Though it's very likely to do with my
>> local changes, these changes are assumed to have no impact on
>> normal system running. So can anybody help a bit about
>> possible cause for such warning? Does it mean something wrong
>> in emulate_privilege_op before gpf_emulate_4gb?
>
>You've screwed something up so you are taking #GP(0) faults from vm86
>mode.
>The warnings from Xen are only debug-level and are a side effect of this.
>
>So you need to investigate why these faults are happening in the first
>place.
>
> -- Keir

Actually I provided wrong info. This also happens on xen-unstable 
even without my changes. The difference is that I set "loglvl=all" in 
modified tree while no such option for base xen-unstable (before 
Rev 13897 which print all). I also tried an old xen-unstable version 
(still, without any change) which uses a 2.6.16.33 xenlinux. After 
setting "loglvl=all", that debug info still jumps out once switching to 
X-windows. So this seems to happen on some box (like with 945 
chipset), and I'm suspecting vm86 emulation has something wrong 
there. Anyway, I'll do some investigation here.

Thanks,
Kevin

Re: Taken fault at bad CS c000...

[Keir Fraser]

On 15/2/07 01:16, "Tian, Kevin" <kevin.tian@intel.com> wrote:

> Actually I provided wrong info. This also happens on xen-unstable
> even without my changes. The difference is that I set "loglvl=all" in
> modified tree while no such option for base xen-unstable (before
> Rev 13897 which print all). I also tried an old xen-unstable version
> (still, without any change) which uses a 2.6.16.33 xenlinux. After
> setting "loglvl=all", that debug info still jumps out once switching to
> X-windows. So this seems to happen on some box (like with 945
> chipset), and I'm suspecting vm86 emulation has something wrong
> there. Anyway, I'll do some investigation here.

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

RE: Taken fault at bad CS c000...

[Tian, Kevin]

>From: Keir Fraser [mailto:Keir.Fraser@cl.cam.ac.uk]
>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

Re: Taken fault at bad CS c000...

[Keir Fraser]

On 15/2/07 08:36, "Tian, Kevin" <kevin.tian@intel.com> wrote:

> 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?

It may be that the X Server fixes up the faults. I'm pretty sure it can do
various bits of fixup emulation.

 -- Keir

RE: Taken fault at bad CS c000...

[Tian, Kevin]

>From: Keir Fraser [mailto:Keir.Fraser@cl.cam.ac.uk]
>Sent: 2007年2月15日 16:40
>On 15/2/07 08:36, "Tian, Kevin" <kevin.tian@intel.com> wrote:
>
>> 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?
>
>It may be that the X Server fixes up the faults. I'm pretty sure it can do
>various bits of fixup emulation.
>
> -- Keir

OK, maybe X server will turn to legacy VGA ports for fixup...

So, will VM86 mode also utilize 4g segment? If yes, we can remove 
the print for vm86. Or else, the whole seg fixup can be skipped for 
vm86 then. :-)

Thanks,
Kevin

Re: Taken fault at bad CS c000...

[Keir Fraser]

On 15/2/07 08:53, "Tian, Kevin" <kevin.tian@intel.com> wrote:

> OK, maybe X server will turn to legacy VGA ports for fixup...
> 
> So, will VM86 mode also utilize 4g segment? If yes, we can remove
> the print for vm86. Or else, the whole seg fixup can be skipped for
> vm86 then. :-)

Oh yes, it's just a noise issue. Segment fixup is never actually done for
vm86 mode. That would make no sense.

 -- Keir