Re: [Xen-devel] pvgrub2 is merged

[Fabio Fantoni <fabio.fantoni@xxxxxxx>]

Il 14/11/2013 22:43, Vladimir 'Ï-coder/phcoder' Serbinenko ha scritto:
> On 14.11.2013 22:11, M A Young wrote:
> > On Thu, 14 Nov 2013, Vladimir 'Ï-coder/phcoder' Serbinenko wrote:
> >
> > > On 14.11.2013 19:57, Vladimir 'Ï-coder/phcoder' Serbinenko wrote:
> > > > On 14.11.2013 19:48, M A Young wrote:
> > > > > On Thu, 14 Nov 2013, Vladimir 'Ï-coder/phcoder' Serbinenko wrote:
> > > > >
> > > > > > On 14.11.2013 18:03, M A Young wrote:
> > > > > > > On Thu, 14 Nov 2013, M A Young wrote:
> > > > > > >
> > > > > > > > On Wed, 13 Nov 2013, Vladimir 'Ï-coder/phcoder' Serbinenko wrote:
> > > > > > > >
> > > > > > > > > On 13.11.2013 20:06, M A Young wrote:
> > > > > > > > > > It doesn't seem to understand sub-partitions. I can get it to
> > > > > > > > > > work if
> > > > > > > > > > the boot files are in /dev/xvda but not in /dev/xvda1 .
> > > > > > > > > insmod part_msdos
> > > > > > > > > insmod part_gpt
> > > > > > > > Right, if I add those to the embedded grub.cfg file I get to the
> > > > > > > > standard grub menu and the boot starts. However the boot doesn't get
> > > > > > > > very far - it loads the kernel and the initrd file and starts the
> > > > > > > > kernel but the kernel doesn't see the virtual disks so it doesn't
> > > > > > > > get
> > > > > > > > very far.
> > > > > > > Using xenstore-ls from the dom0 on the guest when the boot stops the
> > > > > > > local/domain/2/device/vbd/51712 section looks like
> > > > > > >        backend = "/local/domain/0/backend/vbd/2/51712"
> > > > > > >        backend-id = "0"
> > > > > > >        state = "6\000"
> > > > > > >        virtual-device = "51712"
> > > > > > >        device-type = "disk"
> > > > > > >        ring-ref = "\000"
> > > > > > >        event-channel = "\000"
> > > > > > >        protocol = "x86_64-abi\000"
> > > > > > >
> > > > > > > As nothing else has null character endings I suspend that is wrong.
> > > > > > Good catch. Could you test following:
> > > > > > diff --git a/grub-core/kern/xen/init.c b/grub-core/kern/xen/init.c
> > > > > > index 3bfd99f..ab74543 100644
> > > > > > --- a/grub-core/kern/xen/init.c
> > > > > > +++ b/grub-core/kern/xen/init.c
> > > > > > @@ -256,11 +256,10 @@ grub_xenstore_write_file (const char *dir, const
> > > > > > void *buf, grub_size_t len)
> > > > > >
> > > > > >    grub_memset (&msg, 0, sizeof (msg));
> > > > > >    msg.type = XS_WRITE;
> > > > > > -  msg.len = dirlen + len + 1;
> > > > > > +  msg.len = dirlen + len;
> > > > > >    grub_xen_store_send (&msg, sizeof (msg));
> > > > > >    grub_xen_store_send (dir, dirlen);
> > > > > >    grub_xen_store_send (buf, len);
> > > > > > -  grub_xen_store_send ("", 1);
> > > > > >    grub_xen_store_recv (&msg, sizeof (msg));
> > > > > >    resp = grub_malloc (msg.len + 1);
> > > > > >    if (!resp)
> > > > > The section is tidied up, ie.
> > > > >        backend = "/local/domain/0/backend/vbd/4/51712"
> > > > >        backend-id = "0"
> > > > >        state = "6"
> > > > >        virtual-device = "51712"
> > > > >        device-type = "disk"
> > > > >        ring-ref = ""
> > > > >        event-channel = ""
> > > > >        protocol = "x86_64-abi"
> > > > >
> > > > > but unfortunately it doesn't help as the boot process sticks at the
> > > > > same
> > > > > point. I notice this section is in state 6 which apparently is
> > > > > "closed".
> > > > > I wonder if the kernel expecting something else.
> > > > Possible. I'd try this (on top of previous patch):
> > > Sorry, too tired. I meant:
> > > diff --git a/grub-core/disk/xen/xendisk.c b/grub-core/disk/xen/xendisk.c
> > > index c449848..9b71d3a 100644
> > > --- a/grub-core/disk/xen/xendisk.c
> > > +++ b/grub-core/disk/xen/xendisk.c
> > > @@ -449,5 +449,10 @@ grub_xendisk_fini (void)
> > >        grub_xen_free_shared_page (virtdisks[i].shared_page);
> > >
> > >        grub_xen_event_channel_op (EVTCHNOP_close, &close_op);
> > > +
> > > +      /* Prepare for handoff.  */
> > > +      grub_snprintf (fdir, sizeof (fdir), "%s/state",
> > > +                    virtdisks[i].frontend_dir);
> > > +      grub_xenstore_write_file (fdir, "0", 1);
> > >      }
> > > }
> > That doesn't work. However, according to the documentation state 0 is
> > unknown, and the vif interface (while grub is running) is in state 1
> > (initializing) so I thought I would try it, and if you replace "0" with
> > "1" in the above patch then the kernel does boot.
> Thanks.
> http://git.savannah.gnu.org/cgit/grub.git/commit/?id=c7995256e410c5272e2be2f94faf62d3c9d57b61
> and
> http://git.savannah.gnu.org/cgit/grub.git/commit/?id=e1aa5b662088cea329fc968af7c819784b6da068
> >      Michael Young
Thanks for all that have worked for xen support on upstream grub2.

I did a test following informations on one of post before:
git clone git://git.sv.gnu.org/grub.git # commit 
61e1b9a49d48035bde52784abb54c3212b647fc8
./autogen.sh
./configure --target=x86_64 --with-platform=xen
mkdir -p boot/grub/
cat > boot/grub/grub.cfg <<EOF
search -s root -f /boot/grub/grub.cfg
configfile /boot/grub/grub.cfg
EOF
./grub-mkstandalone --grub-mkimage=./grub-mkimage -o pvgrub2.xen -O 
x86_64-xen -d grub-core/ boot/grub/grub.cfg
Latest command give me this warning:
./grub-mkstandalone: warning: cannot open directory 
`/usr/local/share/locale': File o directory non esistente.
I tried to use it on Sid domU adding this line on domU's xl cfg:
kernel = "/mnt/vm/pvgrub2/grub/pvgrub2.xen"
But vnc show black screen and xl console white screen with only this 
line on start before refresh:
Welcome to GRUB!

I also tried to add this line:
extra = "(hd0,msdos1)/grub/grub.cfg"
but the result on vnc  and xl console is the same.

I did something wrong?
Output of xl -vvv create on attachment.
If you need more tests and/or details tell me and I'll post them.
Thanks for any reply and sorry for my bad english.

> _______________________________________________
> Xen-devel mailing list
> Xen-devel@xxxxxxxxxxxxx
> http://lists.xen.org/xen-devel

Attachment: xl-create-vvv.txt
Description: Text document

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel