grub-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] pvgrub2 is merged


From: M A Young
Subject: Re: [Xen-devel] pvgrub2 is merged
Date: Thu, 14 Nov 2013 21:11:22 +0000 (GMT)
User-agent: Alpine 2.00 (DEB 1167 2008-08-23)

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.

        Michael Young

reply via email to

[Prev in Thread] Current Thread [Next in Thread]