guest patched with pax causes "set_cr0: 0xffff88000[...] #GP, reserved bits 0x8004003?" flood on host

guest patched with pax causes "set_cr0: 0xffff88000[...] #GP, reserved bits 0x8004003?" flood on host

[Antoine Martin]

Hi,

I've updated my host kernel headers to 2.6.33, rebuilt glibc (and the 
base system), rebuilt kvm.
... and now I get hundreds of those in dmesg on the host when I start a 
guest kernel that worked fine before. (2.6.33 + pax patch v5)
  set_cr0: 0xffff88000ec29d58 #GP, reserved bits 0x80040033
  set_cr0: 0xffff88000f3cdb38 #GP, reserved bits 0x8004003b
  set_cr0: 0xffff88000f3dbc88 #GP, reserved bits 0x80040033
  set_cr0: 0xffff88000f83b958 #GP, reserved bits 0x8004003b
(hundreds of all 4)
And the VM just reboots shortly after starting init.
Funnily enough, I've got some VMs still running that kernel just fine! 
(as I started them before the headers+glibc+qemu-kvm rebuild)

Now, you might just say that I shouldn't use out of tree patches like 
pax, but I just want to know one thing: should the guest kernel still be 
able to flood dmesg on the host like this?

Thanks
Antoine

PS: Avi, are you still interested in seeing if this rebuild fixes the 
pread/glibc bug?

Re: guest patched with pax causes "set_cr0: 0xffff88000[...] #GP, reserved bits 0x8004003?" flood on host

[Avi Kivity]

On 03/10/2010 06:17 PM, Antoine Martin wrote:
> Hi,
>
> I've updated my host kernel headers to 2.6.33, rebuilt glibc (and the 
> base system), rebuilt kvm.
> ... and now I get hundreds of those in dmesg on the host when I start 
> a guest kernel that worked fine before. (2.6.33 + pax patch v5)
>  set_cr0: 0xffff88000ec29d58 #GP, reserved bits 0x80040033
>  set_cr0: 0xffff88000f3cdb38 #GP, reserved bits 0x8004003b
>  set_cr0: 0xffff88000f3dbc88 #GP, reserved bits 0x80040033
>  set_cr0: 0xffff88000f83b958 #GP, reserved bits 0x8004003b

The guest is clearly confused.  Can you bisect kvm to find out what 
introduced this problem?

> (hundreds of all 4)
> And the VM just reboots shortly after starting init.
> Funnily enough, I've got some VMs still running that kernel just fine! 
> (as I started them before the headers+glibc+qemu-kvm rebuild)
>
> Now, you might just say that I shouldn't use out of tree patches like 
> pax, 

You can run anything you like in a guest.

> but I just want to know one thing: should the guest kernel still be 
> able to flood dmesg on the host like this?

No, these are debug messages.

>
> Thanks
> Antoine
>
> PS: Avi, are you still interested in seeing if this rebuild fixes the 
> pread/glibc bug?

I think we figured it out, but a confirmation would be nice.

-- 
error compiling committee.c: too many arguments to function

Re: guest patched with pax causes "set_cr0: 0xffff88000[...] #GP, reserved bits 0x8004003?" flood on host

[pageexec]

On 11 Mar 2010 at 8:44, Avi Kivity wrote:

> On 03/10/2010 06:17 PM, Antoine Martin wrote:
> > Hi,
> >
> > I've updated my host kernel headers to 2.6.33, rebuilt glibc (and the 
> > base system), rebuilt kvm.
> > ... and now I get hundreds of those in dmesg on the host when I start 
> > a guest kernel that worked fine before. (2.6.33 + pax patch v5)
> >  set_cr0: 0xffff88000ec29d58 #GP, reserved bits 0x80040033
> >  set_cr0: 0xffff88000f3cdb38 #GP, reserved bits 0x8004003b
> >  set_cr0: 0xffff88000f3dbc88 #GP, reserved bits 0x80040033
> >  set_cr0: 0xffff88000f83b958 #GP, reserved bits 0x8004003b
> 
> The guest is clearly confused.  Can you bisect kvm to find out what 
> introduced this problem?

the guest is calling pax_{open,close}_kernel that flip cr0.wp off/on,
respectively. Antoine, can you decode some of those rip values please
(or better, send me the corresponding vmlinux and all logs)?

Re: guest patched with pax causes "set_cr0: 0xffff88000[...] #GP, reserved bits 0x8004003?" flood on host

[Antoine Martin]

On 03/11/2010 04:31 PM, pageexec@freemail.hu wrote:
> On 11 Mar 2010 at 8:44, Avi Kivity wrote:
>
>    
>> On 03/10/2010 06:17 PM, Antoine Martin wrote:
>>      
>>> Hi,
>>>
>>> I've updated my host kernel headers to 2.6.33, rebuilt glibc (and the
>>> base system), rebuilt kvm.
>>> ... and now I get hundreds of those in dmesg on the host when I start
>>> a guest kernel that worked fine before. (2.6.33 + pax patch v5)
>>>   set_cr0: 0xffff88000ec29d58 #GP, reserved bits 0x80040033
>>>   set_cr0: 0xffff88000f3cdb38 #GP, reserved bits 0x8004003b
>>>   set_cr0: 0xffff88000f3dbc88 #GP, reserved bits 0x80040033
>>>   set_cr0: 0xffff88000f83b958 #GP, reserved bits 0x8004003b
>>>        
>> The guest is clearly confused.  Can you bisect kvm to find out what
>> introduced this problem?
>>      
OK, will try to find the time.
> the guest is calling pax_{open,close}_kernel that flip cr0.wp off/on,
> respectively. Antoine, can you decode some of those rip values please
> (or better, send me the corresponding vmlinux and all logs)
I've dumped everything here (.config, vmlinuz and log):
http://users.nagafix.co.uk/~antoine/KVM/

Antoine

Re: guest patched with pax causes "set_cr0: 0xffff88000[...] #GP, reserved bits 0x8004003?" flood on host

[pageexec]

On 11 Mar 2010 at 8:44, Avi Kivity wrote:

> On 03/10/2010 06:17 PM, Antoine Martin wrote:
> > Hi,
> >
> > I've updated my host kernel headers to 2.6.33, rebuilt glibc (and the 
> > base system), rebuilt kvm.
> > ... and now I get hundreds of those in dmesg on the host when I start 
> > a guest kernel that worked fine before. (2.6.33 + pax patch v5)
> >  set_cr0: 0xffff88000ec29d58 #GP, reserved bits 0x80040033
> >  set_cr0: 0xffff88000f3cdb38 #GP, reserved bits 0x8004003b
> >  set_cr0: 0xffff88000f3dbc88 #GP, reserved bits 0x80040033
> >  set_cr0: 0xffff88000f83b958 #GP, reserved bits 0x8004003b
> 
> The guest is clearly confused.  Can you bisect kvm to find out what 
> introduced this problem?

i screwed up the paravirt register clobbers, don't worry about it.