Re: [Xen-devel] Re: tip.git regression from "vsprintf: unify the format decoding layer for its 3 users"

Re: [Xen-devel] Re: tip.git regression from "vsprintf: unify the format decoding layer for its 3 users"

[Jeremy Fitzhardinge]

Boris Derzhavets wrote:
> What is the issue status in meantime ?
> git pull reports conflicting merge ./lib/vsprintf.c
> PV DomUs  may be brought up , but cannot be
> shutdown.
>

Do a "git checkout xen/dom0/hackery; git reset --hard 
remotes/xen/xen/dom0/hackery" to rebase your local hackery branch to the 
upstream one.  I did a bit of a history-rewrite to replace the reverts 
with the proper fix.

    J

how to enable shadow page table? Do I have to run HVM guest systems for shadow paging mode?

[Long Wang]

I am working on a research project based on Xen 3.3.1. I want to use the
shadow page table for setting guest system memory pages as read-only and/or
dirty, and perform a copy-on-write mechanism when these memory pages are
updated. I heard that auto_translated_physmap is not supported any more. 

Then how can I enable shadow page table? Do I have to run HVM guest systems
to have shadow paging mode? Can I enable shadow paging mode in PV?

I look forward to your help on this problem. Thank you very much,

Sincerely,
Long Wang

Re: [Xen-devel] Re: tip.git regression from "vsprintf: unify the format decoding layer for its 3 users"

[Jeremy Fitzhardinge]

Boris Derzhavets wrote:
> It's not working:-
>
> root@ServerIntrepid:/usr/src/linux-2.6-xen# git checkout xen/dom0/hackery
> Already on "xen/dom0/hackery"
> root@ServerIntrepid:/usr/src/linux-2.6-xen# git reset --hard 
> remotes/xen/xen/dom0/hackery
> fatal: ambiguous argument 'remotes/xen/xen/dom0/hackery': unknown 
> revision or path not in the working tree.
>

The proper name is "remotes/<whatever you called your xen 
remote>/xen/dom0/hackery" (it might be "origin").

    J

Re: [Xen-devel] Re: tip.git regression from "vsprintf: unify the format decoding layer for its 3 users"

[Jeremy Fitzhardinge]

Boris Derzhavets wrote:
> Performed:-
>
> root@ServerIntrepid:/usr/src/linux-2.6-xen# git reset --hard 
> remotes/origin/xen/dom0/hackery
> HEAD is now at a38db50 Merge commit 'tip/core/printk' into 
> xen/dom0/hackery
> make clean
> make
> make modules_install install
> mkinitramfs -o /boot/initrd-2.6.29-rc7-tip.img 2.6.29-rc7-tip
>
> Booted with new kernel under Xen (19355) and get same bug in place.
> Cannot shutdown any PV DomU . Xen Host dies.
>
OK, so we're talking about a new bug now, right?

When you say "Xen Host dies", do you mean that Xen itself crashes?  Or 
that the dom0 kernel crashes?  Hangs?  Non-responsive?

Do you have a serial console?

    J