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: Vladimir 'φ-coder/phcoder' Serbinenko
Subject: Re: [Xen-devel] pvgrub2 is merged
Date: Thu, 14 Nov 2013 22:43:39 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20131005 Icedove/17.0.9

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


Attachment: signature.asc
Description: OpenPGP digital signature


reply via email to

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