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. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
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 shstrtabI guess it tries to look up the Xen notes section, but there are no section headers in the Grub binary, only program headers. -- Feri. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
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
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. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
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 environmentWe 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 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
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. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
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 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
> 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 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
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. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
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. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
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. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
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. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
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? _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
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 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
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
_______________________________________________
Xen-users mailing list
Xen-users@lists.xensource.com
http://lists.xensource.com/xen-users