Re: [Qemu-devel] [PATCH] don't require a disk image for network boot
Hi,
Le Tue, 13 Feb 2007 15:58:13 +0100,
"andrzej zaborowski" <[EMAIL PROTECTED]> a écrit :
> Subject: don't require a disk image for network boot
BTW, is there a reason why a disk image is required when using the
-kernel option ?
In the following case: -kernel vmlinuz -append "nfsroot=blabla", we
could boot over the network, without the need for any disk image, but
Qemu wants to have a disk image. Is it mandatory ?
Thanks,
Thomas
--
Thomas Petazzoni - [EMAIL PROTECTED]
http://{thomas,sos,kos}.enix.org - http://www.toulibre.org
http://www.{livret,agenda}dulibre.org
___
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel
[Qemu-devel] Small patch to fix mingw32 build
When building windows binary (./configure --enable-mingw32) build fails
for following error message. Patch in the attachment.
gcc -Wall -O2 -g -fno-strict-aliasing -I. -D_GNU_SOURCE
-D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -o dyngen.exe dyngen.c
dyngen.c: In function `load_object':
dyngen.c:715: parse error before `const'
dyngen.c:718: `p' undeclared (first use in this function)
dyngen.c:718: (Each undeclared identifier is reported only once
dyngen.c:718: for each function it appears in.)
dyngen.c:759: parse error before `int'
dyngen.c:766: `aux_size' undeclared (first use in this function)
dyngen.c:768: `j' undeclared (first use in this function)
Only in qemu-snapshot-2007-02-13_05-patched: arm-linux-user
Only in qemu-snapshot-2007-02-13_05-patched: arm-softmmu
Only in qemu-snapshot-2007-02-13_05-patched: armeb-linux-user
Only in qemu-snapshot-2007-02-13_05-patched: config-host.h
Only in qemu-snapshot-2007-02-13_05-patched: config-host.mak
Only in qemu-snapshot-2007-02-13_05-patched: dyngen.E
diff -ru qemu-snapshot-2007-02-13_05/dyngen.c qemu-snapshot-2007-02-13_05-patched/dyngen.c
--- qemu-snapshot-2007-02-13_05/dyngen.c 2007-02-10 23:31:43.0 +0200
+++ qemu-snapshot-2007-02-13_05-patched/dyngen.c 2007-02-13 09:06:30.0 +0200
@@ -686,6 +686,8 @@
uint32_t *n_strtab;
EXE_SYM *sym;
EXE_RELOC *rel;
+const char *p;
+int aux_size, j;
fd = open(filename, O_RDONLY
#ifdef _WIN32
@@ -712,7 +714,6 @@
sdata = malloc(sizeof(void *) * fhdr.f_nscns);
memset(sdata, 0, sizeof(void *) * fhdr.f_nscns);
-const char *p;
for(i = 0;i < fhdr.f_nscns; i++) {
sec = &shdr[i];
if (!strstart(sec->s_name, ".bss", &p))
@@ -756,7 +757,6 @@
/* set coff symbol */
symtab = malloc(sizeof(struct coff_sym) * nb_syms);
- int aux_size, j;
for (i = 0, ext_sym = coff_symtab, sym = symtab; i < nb_syms; i++, ext_sym++, sym++) {
memset(sym, 0, sizeof(*sym));
sym->st_syment = ext_sym;
Only in qemu-snapshot-2007-02-13_05-patched: dyngen.c.~1.48.~
Only in qemu-snapshot-2007-02-13_05-patched: dyngen.exe
Only in qemu-snapshot-2007-02-13_05-patched: i386-linux-user
Only in qemu-snapshot-2007-02-13_05-patched: i386-softmmu
Only in qemu-snapshot-2007-02-13_05-patched: m68k-linux-user
Only in qemu-snapshot-2007-02-13_05-patched: mips-linux-user
Only in qemu-snapshot-2007-02-13_05-patched: mips-softmmu
Only in qemu-snapshot-2007-02-13_05-patched: mipsel-linux-user
Only in qemu-snapshot-2007-02-13_05-patched: mipsel-softmmu
Only in qemu-snapshot-2007-02-13_05-patched: ppc-linux-user
Only in qemu-snapshot-2007-02-13_05-patched: ppc-softmmu
Only in qemu-snapshot-2007-02-13_05-patched: qemu-doc.html
Only in qemu-snapshot-2007-02-13_05-patched: qemu-img.1
Only in qemu-snapshot-2007-02-13_05-patched: qemu-img.exe
Only in qemu-snapshot-2007-02-13_05-patched: qemu-img.pod
Only in qemu-snapshot-2007-02-13_05-patched: qemu-tech.html
Only in qemu-snapshot-2007-02-13_05-patched: qemu.1
Only in qemu-snapshot-2007-02-13_05-patched: qemu.pod
Only in qemu-snapshot-2007-02-13_05-patched: sparc-linux-user
Only in qemu-snapshot-2007-02-13_05-patched: sparc-softmmu
Only in qemu-snapshot-2007-02-13_05-patched: x86_64-softmmu
___
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel
RE: [Qemu-devel] USB storage cannot be recognized on guest Linux domain?
On Thu, 2007-02-15 at 15:44 +0800, Yu, Xiaoyang wrote:
> Hi Lonnie,
>
> Thanks a lot for the information.
>
> In our use case, we do not know the USB disk information before it is plugged
> by customer, so we cannot start qemu with -usbdevice.
>
> For Linux, reload the uhci_hcd driver works. If we use this solution in our
> use case, then we need to issue an interrupt (maybe by pic_set_irq_new?) to
> the guest OS when QEMU detect a USB device is attached, and then the guest OS
> will reload the uhci_hcd driver. Is that right? Currently there is something
> wrong with the list archive server, so I haven't search out any example code
> from it :-(
>
> I found that there is a patch to add the UHCI suspend/resume support in the
> archive posted by you, but it cannot be applied to QEMU-DM 0.8.2 directly:
> http://lists.gnu.org/archive/html/qemu-devel/2006-04/msg00576.html
>
> I wonder why there is no official UHCI suspend/resume support in QEMU. To
> reload the uhci_hcd driver seems to be only a work around. Sometimes it even
> cause kernel oops.
>
> I also wonder why the kernel 2.6.11-1.1369_FC4 can recognize USB storage
> without UHCI suspend/resume support.
The attached patch is enough to have a device on linux recognized after
usb_add. However, the device must be attached to the uhci controller's
root hub. If a device is attached to an emulated usb hub device it will
not be detected.
? qemu-uhci-resume.diff
Index: hw/usb-uhci.c
===
RCS file: /sources/qemu/qemu/hw/usb-uhci.c,v
retrieving revision 1.13
diff -u -r1.13 usb-uhci.c
--- hw/usb-uhci.c 17 Jan 2007 23:08:17 - 1.13
+++ hw/usb-uhci.c 15 Feb 2007 14:44:40 -
@@ -26,6 +26,8 @@
//#define DEBUG
//#define DEBUG_PACKET
+#define UHCI_CMD_FGR (1 << 4)
+#define UHCI_CMD_EGSM (1 << 3)
#define UHCI_CMD_GRESET (1 << 2)
#define UHCI_CMD_HCRESET (1 << 1)
#define UHCI_CMD_RS (1 << 0)
@@ -327,6 +329,21 @@
return val;
}
+/* signal resume if controller suspended */
+static void uhci_resume (void *opaque)
+{
+UHCIState *s = (UHCIState *)opaque;
+
+if (!s)
+return;
+
+if (s->cmd & UHCI_CMD_EGSM) {
+s->cmd |= UHCI_CMD_FGR;
+s->status |= UHCI_STS_RD;
+uhci_update_irq(s);
+}
+}
+
static void uhci_attach(USBPort *port1, USBDevice *dev)
{
UHCIState *s = port1->opaque;
@@ -344,6 +361,9 @@
port->ctrl |= UHCI_PORT_LSDA;
else
port->ctrl &= ~UHCI_PORT_LSDA;
+
+uhci_resume(s);
+
port->port.dev = dev;
/* send the attach message */
usb_send_msg(dev, USB_MSG_ATTACH);
@@ -358,6 +378,9 @@
port->ctrl &= ~UHCI_PORT_EN;
port->ctrl |= UHCI_PORT_ENC;
}
+
+uhci_resume(s);
+
dev = port->port.dev;
if (dev) {
/* send the detach message */
___
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] [PATCH] don't require a disk image for network boot
On 2/15/07, Thomas Petazzoni <[EMAIL PROTECTED]> wrote: BTW, is there a reason why a disk image is required when using the -kernel option ? In the following case: -kernel vmlinuz -append "nfsroot=blabla", we could boot over the network, without the need for any disk image, but Qemu wants to have a disk image. Is it mandatory ? On Linux, -hda /dev/zero works fine, so I'd say there's no reason a disk image is necessary. --Ed ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] [PATCH] don't require a disk image for network boot
On Thursday 15 February 2007 09:17, Thomas Petazzoni wrote: > Hi, > > Le Tue, 13 Feb 2007 15:58:13 +0100, > > "andrzej zaborowski" <[EMAIL PROTECTED]> a écrit : > > Subject: don't require a disk image for network boot > > BTW, is there a reason why a disk image is required when using the > -kernel option ? > > In the following case: -kernel vmlinuz -append "nfsroot=blabla", we > could boot over the network, without the need for any disk image, but > Qemu wants to have a disk image. Is it mandatory ? The BIOS doesn't know about the -kernel option, so qemu replaces the first sector of the disk image with a dummy bootloader that jumps to the preloaded kernel. It can only do that if there is an image to replace. Paul ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
[Qemu-devel] [kqemu] make clean should remove generated files
Hi, When running make clean, the following files arent removed for now : config-host.mak (generated by configure) kqemu.mod.c Module.symvers (generated both by kernel build part) Dont know for the last 2, but IMHO config-host.mak has to be removed. Kind regards, Sylvain Petreolle (aka Usurp) --- --- --- --- --- --- --- --- --- --- --- --- --- Run your favorite Windows apps with free ReactOS : http://www.reactos.org Listen to non-DRMised Music: http://www.jamendo.com ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
[Qemu-devel] qemu Changelog
CVSROOT:/sources/qemu Module name:qemu Changes by: Fabrice Bellard07/02/15 22:49:45 Modified files: . : Changelog Log message: update author CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/qemu/Changelog?cvsroot=qemu&r1=1.128&r2=1.129 ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
[Qemu-devel] qemu configure
CVSROOT:/sources/qemu Module name:qemu Changes by: Fabrice Bellard07/02/15 22:58:18 Modified files: . : configure Log message: fixed cross win32 build CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/qemu/configure?cvsroot=qemu&r1=1.123&r2=1.124 ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] [PATCH 1/1] Making pxe working in the "NAT" mode
Erwan Velu wrote:
Hey folks,
I saw the lastest qemu support pxe so I tried it using the following
command:
qemu -hda /tmp/a.img -net nic n- user -boot n
Note that now qemu support pxe mode, the mandatory -hda option is no
more mandatory but this is not directly linked to my patch.
I saw qemu integrates a dhcp & a tftp server but they don't seems to
be configured/developped for a pxe boot process.
Qemu says "no filename" and exits.
Hi Erwan,
I really like the idea of your patch. Of course, the hard coding is not
really reasonable :-) Also, PXE is an x86-ism. What you've really done
is added a mechanism to publish a BOOTP name. We do need to add a new
option too as one may want to use -boot n without publishing a BOOTP
filename.
Using your patch as a basis, I've written three patches. The first one
is the tsize negotiation fix for the TFTP server. The second adds a
-bootp option for specifying the location of the BOOTP image. The third
changes the -tftp option to take root directory. The end result, is
that now you can say:
qemu -hda /tmp/a.img -boot n -tftp ~/tftpboot -bootp /pxelinux.0
And you get the same results without the hard coding. What do you think?
Regards,
Anthony Liguori
A friend of I asked me "how do you boot using pxe in qemu when you
don't have a dhcp & a tftp server ?".
So I started to look how we can do that, I modified bootp to catch the
field 60 of a dhcp request to find if its a pxe request or not.
If yes, I set the filename to "/pxelinux.0", currently this is
harcoded, maybe you can help me to find a better way to specify a
bootloader.
Then, I've patched the tftp server to change the default rootdir in my
home dir. "~/tftpboot". This is just for a Proof-of-concept, other
methods could be fine. We can also imagine searching in a path
restricted to the admin and then in the user dir. So it can give the
admin the ability of defining some pxe boot for all the vm of a
system or in the user dir if the user wants to have a special pxe
boot scheme.
The last patch I did on the tftp server, is to allow the tsize
negociation because pxelinux needs it.
This patch apply to 0.9.0, once it is applied and compiled here come
the test procedure:
create a ~/tftpboot/pxelinux.cfg directory
copy pxelinux.0 in ~/tfptboot/
create a pxelinux configuration file called "default" in
~/tftpboot/pxelinux.cfg
Et voila ;)
Just call "qemu -hda /tmp/a.img -net nic n- user -boot n", it will
start pxelinux.
I think this patch is very usefull because it give users & admin the
ability to use pxe inside the VM without installing the full
configuration (dhcp,tftp).
This patch is mainly a proof-of-concept, this patch can be improved,
comments and feedback are welcome.
___
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel
diff -r ea5eb79ade8d slirp/bootp.c
--- a/slirp/bootp.c Thu Feb 15 16:49:28 2007 -0600
+++ b/slirp/bootp.c Thu Feb 15 16:49:30 2007 -0600
@@ -38,6 +38,8 @@ typedef struct {
BOOTPClient bootp_clients[NB_ADDR];
+const char *bootp_filename;
+
static const uint8_t rfc1533_cookie[] = { RFC1533_COOKIE };
#ifdef DEBUG
@@ -168,6 +170,10 @@ static void bootp_reply(struct bootp_t *
goto new_addr;
}
}
+
+if (bootp_filename)
+snprintf(rbp->bp_file, sizeof(rbp->bp_file), "%s", bootp_filename);
+
dprintf("offered addr=%08x\n", ntohl(daddr.sin_addr.s_addr));
saddr.sin_addr.s_addr = htonl(ntohl(special_addr.s_addr) | CTL_ALIAS);
diff -r ea5eb79ade8d vl.c
--- a/vl.c Thu Feb 15 16:49:28 2007 -0600
+++ b/vl.c Thu Feb 15 16:57:07 2007 -0600
@@ -6488,6 +6488,7 @@ void help(void)
"\n"
#ifdef CONFIG_SLIRP
"-tftp prefixallow tftp access to files starting with prefix [-net user]\n"
+ "-bootp file advertise file in BOOTP replies\n"
#ifndef _WIN32
"-smb dirallow SMB access to files in 'dir' [-net user]\n"
#endif
@@ -6576,6 +6577,7 @@ enum {
QEMU_OPTION_net,
QEMU_OPTION_tftp,
+QEMU_OPTION_bootp,
QEMU_OPTION_smb,
QEMU_OPTION_redir,
@@ -6652,6 +6654,7 @@ const QEMUOption qemu_options[] = {
{ "net", HAS_ARG, QEMU_OPTION_net},
#ifdef CONFIG_SLIRP
{ "tftp", HAS_ARG, QEMU_OPTION_tftp },
+{ "bootp", HAS_ARG, QEMU_OPTION_bootp },
#ifndef _WIN32
{ "smb", HAS_ARG, QEMU_OPTION_smb },
#endif
@@ -7185,6 +7188,9 @@ int main(int argc, char **argv)
case QEMU_OPTION_tftp:
tftp_prefix = optarg;
break;
+case QEMU_OPTION_bootp:
+bootp_filename = optarg;
+break;
#ifndef _WIN32
case QEMU_OPTION_smb:
net_slirp_smb(optarg);
diff -r ea5eb79ade8d vl.h
--- a/vl.h Thu Feb 15 16:49:28 2007 -0600
+++ b/vl.h Thu Feb 15 16:49:30 2007 -0600
@@ -163,6 +163,7 @@ extern int no_quit;
extern int no_quit;
extern int semihosting_enabled;
extern in
[Qemu-devel] Please help fix an illegal instruction / SSE problem
Every Cocoa application I try to run under i386-darwin-user/qemu-i386 exits on an illegal instruction: Starting /Applications/Calculator.app/Contents/MacOS/Calculator with qemu queue_signal: sig=4 qemu: uncaught target signal 4 (Illegal instruction) - exiting The last block always executes SSE instructions: IN: 0x0ab7: movdqa 0xfffa(%esi,%edx,1),%xmm0 0x0abd: movdqa 0xa(%esi,%edx,1),%xmm1 0x0ac3: movdqa 0x1a(%esi,%edx,1),%xmm2 0x0ac9: movdqa 0x2a(%esi,%edx,1),%xmm3 0x0acf: movdqa 0x3a(%esi,%edx,1),%xmm4 0x0ad5: movdqa %xmm0,%xmm5 0x0ad9: movdqa %xmm4,%xmm0 0x0add: data16 0x0ade: (bad) Non-graphics applications run fine. Could it be a configuration/compilation problem (although some SEE instructions seem to be handled fine)? If not, is there a way to better diagnose the problem? I on Mac OS Intel with QEMU 0.9.0. Thank you for your help! Ilya 8:00? 8:25? 8:40? Find a flick in no time with the Yahoo! Search movie showtime shortcut. http://tools.search.yahoo.com/shortcuts/#news ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
RE: [Qemu-devel] USB storage cannot be recognized on guest Linuxdomain?
Lonnie, Thank you so much for write the patch for me! It works well with Fedora Core 4. Since it added UHCI suspend/resume support, so I guess it should also work with Windows XP :-) Thanks Xiaoyang -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Lonnie Mendez Sent: 2007年2月15日 22:49 To: qemu-devel@nongnu.org Subject: RE: [Qemu-devel] USB storage cannot be recognized on guest Linuxdomain? On Thu, 2007-02-15 at 15:44 +0800, Yu, Xiaoyang wrote: > Hi Lonnie, > > Thanks a lot for the information. > > In our use case, we do not know the USB disk information before it is plugged > by customer, so we cannot start qemu with -usbdevice. > > For Linux, reload the uhci_hcd driver works. If we use this solution in our > use case, then we need to issue an interrupt (maybe by pic_set_irq_new?) to > the guest OS when QEMU detect a USB device is attached, and then the guest OS > will reload the uhci_hcd driver. Is that right? Currently there is something > wrong with the list archive server, so I haven't search out any example code > from it :-( > > I found that there is a patch to add the UHCI suspend/resume support in the > archive posted by you, but it cannot be applied to QEMU-DM 0.8.2 directly: > http://lists.gnu.org/archive/html/qemu-devel/2006-04/msg00576.html > > I wonder why there is no official UHCI suspend/resume support in QEMU. To > reload the uhci_hcd driver seems to be only a work around. Sometimes it even > cause kernel oops. > > I also wonder why the kernel 2.6.11-1.1369_FC4 can recognize USB storage > without UHCI suspend/resume support. The attached patch is enough to have a device on linux recognized after usb_add. However, the device must be attached to the uhci controller's root hub. If a device is attached to an emulated usb hub device it will not be detected. ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
