Grub2 on Xen PV

Grub2 on Xen PV

[Ferenc Wagner]

Hi,

Let me start a new thread for this.  I contacted the Grub people, and
they seem more interested in creating a native Xen port of Grub than
piggybacking the Mini-OS environment usin kexec as I tried.  But they
need some documentation on the Xen "firmware" to assess the task at
least.  What could be given to them apart from hvc_xen.c and
xen-blkfront.c in the Linux sources?  blkif-drivers-explained.txt?

For a start, Grub has a Coreboot port, which is ELF, but the Xen 3.2
domain builder refuses to load it saying:

xc_dom_parse_elf_kernel: ELF image has no shstrtab
-- 
Thanks,
Feri.

Re: Grub2 on Xen PV

[Ferenc Wagner]

Ferenc Wagner <wferi@niif.hu> writes:

> Let me start a new thread for this.  I contacted the Grub people, and
> they seem more interested in creating a native Xen port of Grub than
> piggybacking the Mini-OS environment usin kexec as I tried.  But they
> need some documentation on the Xen "firmware" to assess the task at
> least.  What could be given to them apart from hvc_xen.c and
> xen-blkfront.c in the Linux sources?  blkif-drivers-explained.txt?

After a second thought, the mini-os console.c and blkfront.c are
probably a better choice.

> For a start, Grub has a Coreboot port, which is ELF, but the Xen 3.2
> domain builder refuses to load it saying:
>
> xc_dom_parse_elf_kernel: ELF image has no shstrtab

I guess it tries to look up the Xen notes section, but there are no
section headers in the Grub binary, only program headers.
-- 
Feri.

USB floppy issue in Xen 3.4

[Patro, Sumant]

Hello,

	I want to access USB floppy from HVM guest (Windows, Linux) using Xen 3.4. I checked with the version 3.4.0-rc4-pre. I have tried with USB floppy drives from three different vendors. The device is not accessible in both Windows and Linux.
 
	I have usb and usbdevice entry in the HVM config file. The device is listed in Windows Device Manager with a yellow bang. In RHEL 5.3 guest lsusb displays it, but is not associated with a device name. The same device works fine in Xen 3.3.
     
      Is there any workaround/fix for this in Xen 3.4?

Regards,

Sumant

RE: USB floppy issue in Xen 3.4

[Patro, Sumant]

Hello,

	I tried with the below patch to access the USB floppy in GOS. With this patch, the yellow bang in Device Manager does not appear, however, the device (a:) is not shown by the Windows Guest.

	Any pointers on what could be wrong or workaround to access the USB floppy ?

Regards,

Sumant

diff --git a/hw/usb-uhci.c b/hw/usb-uhci.c
index d42d394..70ed338 100644
--- a/hw/usb-uhci.c
+++ b/hw/usb-uhci.c
@@ -794,7 +794,7 @@ static int uhci_handle_td(UHCIState *s, uint32_t addr, UHCI_TD *td, uint32_t *in
     if (!async)
         return 1;
 
-    async->valid = 10;
+    async->valid = 32;
     async->td    = addr;
     async->token = td->token;
 
diff --git a/hw/usb.c b/hw/usb.c
diff --git a/usb-linux.c b/usb-linux.c
index 5dfed8c..f8046ba 100644
--- a/usb-linux.c
+++ b/usb-linux.c
@@ -144,6 +144,10 @@ static int is_isoc(USBHostDevice *s, int ep)
 {
     return s->endp_table[ep - 1].type == USBDEVFS_URB_TYPE_ISO;
 }
+static int is_intr(USBHostDevice *s, int ep)
+{
+    return s->endp_table[ep - 1].type == USBDEVFS_URB_TYPE_INTERRUPT;
+}
 
 static int is_halted(USBHostDevice *s, int ep)
 {
@@ -274,7 +278,6 @@ static void async_complete(void *opaque)
                 if (aurb->urb.type == USBDEVFS_URB_TYPE_CONTROL)
                     async_complete_ctrl(s, p);
                 break;
-
             case -EPIPE:
                 set_halt(s, p->devep);
                 /* fall through */
@@ -472,6 +475,9 @@ static int usb_host_handle_data(USBHostDevice *s, USBPacket *p)
         urb->flags    = USBDEVFS_URB_ISO_ASAP;
         urb->number_of_packets = 1;
         urb->iso_frame_desc[0].length = p->len;
+    } else if (is_intr(s, p->devep)) {
+        /* Setup interrupt transfer */
+        urb->type     = USBDEVFS_URB_TYPE_INTERRUPT;
     } else {
         /* Setup bulk transfer */
         urb->type     = USBDEVFS_URB_TYPE_BULK;





-----Original Message-----
From: xen-devel-bounces@lists.xensource.com [mailto:xen-devel-bounces@lists.xensource.com] On Behalf Of Patro, Sumant
Sent: Friday, May 15, 2009 11:50 AM
To: xen-devel@lists.xensource.com; 'xen-users@lists.xensource.com'
Subject: [Xen-devel] USB floppy issue in Xen 3.4

Hello,

	I want to access USB floppy from HVM guest (Windows, Linux) using Xen 3.4. I checked with the version 3.4.0-rc4-pre. I have tried with USB floppy drives from three different vendors. The device is not accessible in both Windows and Linux.
 
	I have usb and usbdevice entry in the HVM config file. The device is listed in Windows Device Manager with a yellow bang. In RHEL 5.3 guest lsusb displays it, but is not associated with a device name. The same device works fine in Xen 3.3.
     
      Is there any workaround/fix for this in Xen 3.4?

Regards,

Sumant

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

Re: Grub2 on Xen PV

[Ferenc Wagner]

Ferenc Wagner <wferi@niif.hu> writes:

> I contacted the Grub people, and they seem more interested in
> creating a native Xen port of Grub than piggybacking the Mini-OS
> environment using kexec as I tried.

Just to report back on the stubdom approach as well: grub-emu is
running and is capable of reading its config from an XFS LV via
blkfront.  Being a debugging tool, it has no loader support, though,
and the menu is redrawing continuously, so it's unusable.
-- 
Feri.

Re: Grub2 on Xen PV

[Samuel Thibault]

Hello,

Ferenc Wagner, le Fri 15 May 2009 16:57:01 +0200, a écrit :
> Let me start a new thread for this.  I contacted the Grub people, and
> they seem more interested in creating a native Xen port of Grub than
> piggybacking the Mini-OS environment

We actually had discussed a bit about that at XenSource.  If they have
the will to maintain it then it's all the best I guess.

> usin kexec as I tried.

They can reuse my kexec code.

> But they need some documentation on the Xen "firmware" to assess the
> task at least.  What could be given to them apart from hvc_xen.c and
> xen-blkfront.c in the Linux sources? blkif-drivers-explained.txt?
> After a second thought, the mini-os console.c and blkfront.c are
> probably a better choice.

I'd rather provide them the MiniOS code which is more simple, yes. But
instead of giving them only a few files, show them the whole code, as
it's not really just a "firmware".

> > For a start, Grub has a Coreboot port, which is ELF, but the Xen 3.2
> > domain builder refuses to load it saying:
> >
> > xc_dom_parse_elf_kernel: ELF image has no shstrtab
> 
> I guess it tries to look up the Xen notes section, but there are no
> section headers in the Grub binary, only program headers.

Yes, there's all the magic stuff that needs to be included, see
arch/x86/x86_32.S

Samuel

Re: Grub2 on Xen PV

[Ferenc Wagner]

Samuel Thibault <samuel.thibault@ens-lyon.org> writes:

> Ferenc Wagner, le Fri 15 May 2009 16:57:01 +0200, a écrit :
>
>> I contacted the Grub people, and they seem more interested in
>> creating a native Xen port of Grub than piggybacking the Mini-OS
>> environment
>
> We actually had discussed a bit about that at XenSource.  If they have
> the will to maintain it then it's all the best I guess.

I wonder if that approach would turn out much different in the end...

> They can reuse my kexec code.

Only if you relicense it.  If you're still subscribed to grub-devel,
you already know this but if not: Grub is GPLv3+, Xen is GPLv2, so
they can't use Xen code.  Parts of MiniOS are licensed differently,
but it's still too swampy to work with, as it looks.  :(
-- 
Feri.

Re: Grub2 on Xen PV

[Samuel Thibault]

Ferenc Wagner, le Tue 19 May 2009 00:15:39 +0200, a écrit :
> Samuel Thibault <samuel.thibault@ens-lyon.org> writes:
> 
> > Ferenc Wagner, le Fri 15 May 2009 16:57:01 +0200, a écrit :
> >
> >> I contacted the Grub people, and they seem more interested in
> >> creating a native Xen port of Grub than piggybacking the Mini-OS
> >> environment
> >
> > We actually had discussed a bit about that at XenSource.  If they have
> > the will to maintain it then it's all the best I guess.
> 
> I wonder if that approach would turn out much different in the end...
> 
> > They can reuse my kexec code.
> 
> Only if you relicense it.  If you're still subscribed to grub-devel,
> you already know this but if not: Grub is GPLv3+, Xen is GPLv2, so
> they can't use Xen code.  Parts of MiniOS are licensed differently,
> but it's still too swampy to work with, as it looks.  :(

Ah, damn licences issues.  For the kexec code, XenSource can decide
to relicence it under GPLv3+, as it was all written by me while I was
working there. For MiniOS that can't be done as there have been many
contributions from many parts.

Samuel

RE: Re: Grub2 on Xen PV

[Ian Pratt]

> Ah, damn licences issues.  For the kexec code, XenSource can decide
> to relicence it under GPLv3+, as it was all written by me while I was
> working there. For MiniOS that can't be done as there have been many
> contributions from many parts.

Isn't MiniOS BSD? In which case presumably the Grub guys can incorporate it.

Ian

Re: Re: Grub2 on Xen PV

[Stefano Stabellini]

Ian Pratt wrote:

>> Ah, damn licences issues.  For the kexec code, XenSource can decide
>> to relicence it under GPLv3+, as it was all written by me while I was
>> working there. For MiniOS that can't be done as there have been many
>> contributions from many parts.
> 
> Isn't MiniOS BSD? In which case presumably the Grub guys can incorporate it.


Yes, MiniOS is BSD indeed.

Re: Grub2 on Xen PV

[Ferenc Wagner]

Stefano Stabellini <stefano.stabellini@eu.citrix.com> writes:

> Ian Pratt wrote:
>
>>> Ah, damn licences issues.  For the kexec code, XenSource can decide
>>> to relicence it under GPLv3+, as it was all written by me while I was
>>> working there. For MiniOS that can't be done as there have been many
>>> contributions from many parts.
>> 
>> Isn't MiniOS BSD? In which case presumably the Grub guys can incorporate it.
>
> Yes, MiniOS is BSD indeed.

If it's new BSD (without the advertising clause), then that's
perfectly fine.  Unfortunately I couldn't read so however hard I
tried.  From the top level COPYING file:

   Licensing Exceptions (the relaxed BSD-style license)
   ----------------------------------------------------
   
   For the convenience of users and those who are porting OSes to run
   as Xen guests, certain files in this repository are not subject to
   the GPL when distributed separately or included in software
   packages outside this repository. Instead we specify a much more
   relaxed BSD-style license. Affected files include the Xen interface
   headers (xen/include/public/COPYING), and various drivers, support
   functions and header files within the Linux source trees on
   http://xenbits.xensource.com/linux-2.6.X-xen.hg. In all such cases,
   license terms are stated at the top of the file or in a COPYING
   file in the same directory. Note that _any_ file that is modified
   and then distributed within a Linux kernel is still subject to the
   GNU GPL.

But there's no COPYING file under extras, nor the above mentions
MiniOS.  The comment in blkfront.c says it's based on netfront.c,
whose comment says it's based on Xen Linux, which is BSD by the above,
so that may be OK.  But other parts of MiniOS haven't got any license
declaration, so it isn't obvious, for the very least...  I wonder how
it could be better communicated.

Meanwhile I'll try to proceed nevertheless.
-- 
Thanks,
Feri.

Re: Grub2 on Xen PV

[Stefano Stabellini]

Ferenc Wagner wrote:

> If it's new BSD (without the advertising clause), then that's
> perfectly fine.  Unfortunately I couldn't read so however hard I
> tried.  From the top level COPYING file:
> 
>    Licensing Exceptions (the relaxed BSD-style license)
>    ----------------------------------------------------
>    
>    For the convenience of users and those who are porting OSes to run
>    as Xen guests, certain files in this repository are not subject to
>    the GPL when distributed separately or included in software
>    packages outside this repository. Instead we specify a much more
>    relaxed BSD-style license. Affected files include the Xen interface
>    headers (xen/include/public/COPYING), and various drivers, support
>    functions and header files within the Linux source trees on
>    http://xenbits.xensource.com/linux-2.6.X-xen.hg. In all such cases,
>    license terms are stated at the top of the file or in a COPYING
>    file in the same directory. Note that _any_ file that is modified
>    and then distributed within a Linux kernel is still subject to the
>    GNU GPL.
> 
> But there's no COPYING file under extras, nor the above mentions
> MiniOS.  The comment in blkfront.c says it's based on netfront.c,
> whose comment says it's based on Xen Linux, which is BSD by the above,
> so that may be OK.  But other parts of MiniOS haven't got any license
> declaration, so it isn't obvious, for the very least...  I wonder how
> it could be better communicated.
> 
> Meanwhile I'll try to proceed nevertheless.


Yeah, we'll try to make it more clear.

Re: Grub2 on Xen PV

[Ferenc Wagner]

Stefano Stabellini <stefano.stabellini@eu.citrix.com> writes:

> Ferenc Wagner wrote:
>
>> If it's new BSD (without the advertising clause), then that's
>> perfectly fine.  Unfortunately I couldn't read so however hard I
>> tried.  From the top level COPYING file:
>> 
>>    Licensing Exceptions (the relaxed BSD-style license)
>>    ----------------------------------------------------
>>    
>>    For the convenience of users and those who are porting OSes to run
>>    as Xen guests, certain files in this repository are not subject to
>>    the GPL when distributed separately or included in software
>>    packages outside this repository. Instead we specify a much more
>>    relaxed BSD-style license. Affected files include the Xen interface
>>    headers (xen/include/public/COPYING), and various drivers, support
>>    functions and header files within the Linux source trees on
>>    http://xenbits.xensource.com/linux-2.6.X-xen.hg. In all such cases,
>>    license terms are stated at the top of the file or in a COPYING
>>    file in the same directory. Note that _any_ file that is modified
>>    and then distributed within a Linux kernel is still subject to the
>>    GNU GPL.
>> 
>> But there's no COPYING file under extras, nor the above mentions
>> MiniOS.  The comment in blkfront.c says it's based on netfront.c,
>> whose comment says it's based on Xen Linux, which is BSD by the above,
>> so that may be OK.  But other parts of MiniOS haven't got any license
>> declaration, so it isn't obvious, for the very least...  I wonder how
>> it could be better communicated.
>> 
>> Meanwhile I'll try to proceed nevertheless.
>
> Yeah, we'll try to make it more clear.

Great!

And what about stubdom/grub/kexec.c & co.?  Is that in a different bag?
-- 
Thanks,
Feri.

Re: Grub2 on Xen PV

[Stefano Stabellini]

Ferenc Wagner wrote:

> Stefano Stabellini <stefano.stabellini@eu.citrix.com> writes:
> 
>> Ferenc Wagner wrote:
>>
>>> If it's new BSD (without the advertising clause), then that's
>>> perfectly fine.  Unfortunately I couldn't read so however hard I
>>> tried.  From the top level COPYING file:
>>>
>>>    Licensing Exceptions (the relaxed BSD-style license)
>>>    ----------------------------------------------------
>>>    
>>>    For the convenience of users and those who are porting OSes to run
>>>    as Xen guests, certain files in this repository are not subject to
>>>    the GPL when distributed separately or included in software
>>>    packages outside this repository. Instead we specify a much more
>>>    relaxed BSD-style license. Affected files include the Xen interface
>>>    headers (xen/include/public/COPYING), and various drivers, support
>>>    functions and header files within the Linux source trees on
>>>    http://xenbits.xensource.com/linux-2.6.X-xen.hg. In all such cases,
>>>    license terms are stated at the top of the file or in a COPYING
>>>    file in the same directory. Note that _any_ file that is modified
>>>    and then distributed within a Linux kernel is still subject to the
>>>    GNU GPL.
>>>
>>> But there's no COPYING file under extras, nor the above mentions
>>> MiniOS.  The comment in blkfront.c says it's based on netfront.c,
>>> whose comment says it's based on Xen Linux, which is BSD by the above,
>>> so that may be OK.  But other parts of MiniOS haven't got any license
>>> declaration, so it isn't obvious, for the very least...  I wonder how
>>> it could be better communicated.
>>>
>>> Meanwhile I'll try to proceed nevertheless.
>> Yeah, we'll try to make it more clear.
> 
> Great!
> 
> And what about stubdom/grub/kexec.c & co.?  Is that in a different bag?


That code was written entirely by Samuel, so he can easily dual license it.
Being MiniOS BSD licensed it would make sense for kexec to be BSD as well.
Samuel, what do you think?

Re: Grub2 on Xen PV

[Samuel Thibault]

Stefano Stabellini, le Tue 19 May 2009 15:18:57 +0100, a écrit :
> > And what about stubdom/grub/kexec.c & co.?  Is that in a different bag?
> 
> 
> That code was written entirely by Samuel, so he can easily dual license it.
> Being MiniOS BSD licensed it would make sense for kexec to be BSD as well.
> Samuel, what do you think?

I'm completely fine with it.  Anyway that's Citrix' decision as my
employer at the time.

Samuel