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 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
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 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
>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. > > -- KeirActually 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 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
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 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
>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. > > -- KeirYeah, 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@lists.xensource.com http://lists.xensource.com/xen-devel
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 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
>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. > > -- KeirOK, 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 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
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 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel