[Qemu-devel] [PATCH] mount syscall
In the attachment fixed Debian patch(with lock_user_string).
Index: linux-user/syscall.c
===
RCS file: /sources/qemu/qemu/linux-user/syscall.c,v
retrieving revision 1.86
diff -u -r1.86 syscall.c
--- linux-user/syscall.c11 Feb 2007 20:03:13 - 1.86
+++ linux-user/syscall.c12 Feb 2007 10:49:07 -
@@ -2163,8 +2163,18 @@
ret = get_errno(getpid());
break;
case TARGET_NR_mount:
-/* need to look at the data field */
-goto unimplemented;
+ {
+ /* need to look at the data field */
+ void *p2, *p3;
+ p = lock_user_string(arg1);
+ p2 = lock_user_string(arg2);
+ p3 = lock_user_string(arg3);
+ ret = get_errno(mount(p, p2, p3, (unsigned long)arg4,
(const void *)arg5));
+ unlock_user(p, arg1, 0);
+ unlock_user(p2, arg2, 0);
+ unlock_user(p3, arg3, 0);
+ break;
+ }
case TARGET_NR_umount:
p = lock_user_string(arg1);
ret = get_errno(umount(p));
signature.asc
Description: Digital signature
___
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?
I just found that using an older kernel in Fedora Core 4 may “solve” the problem. When I tested Fedora Core 4 guest domain, the kernel version I used was 2.6.17-1.2142_FC4, and it cannot recognized the USB disk. I just changed the kernel in guest domain to version 2.6.11-1.1369_FC4. Then the guest domain can recognized the USB disk. I am wondering why the USB support in QEMU depend on the guest domain kernel. And I would like to know which kernel version can support QEMU USB emulation. BTW, I also found that Windows XP guest domain can not recognize the USB disk, while Windows XP SP2 guest domain can recognize the USB disk. So it seems like that the guest Linux/Windows domain should have some “special feature” to work with the QEMU USB emulation successfully. Isn’t it strange? Sent: 2007年2月14日 15:06 To: qemu-devel@nongnu.org Subject: [Qemu-devel] USB storage cannot be recognized on guest Linux domain? I am using Xen 3.0.3 with QEMU-DM 0.8.2 on a Intel VT platform. After insert a USB storage, and use “usb_add” command in QEMU monitor, the storage should be recognized on guest OS. I tested this with a Windows XP SP2 guest OS, it doing well. But when I test the “usb_add” command with some Linux guest OS, it seems that the guest OS cannot recognize the USB storage. And the device number and address in guest domain are always “0.0”. The Linux guest OS I tested including Fedora Core 4 and Fedora Core 5. Does any one also meet this problem or have some idea on this? Feedbacks will be highly appreciated. Thanks Xiaoyang ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
[Qemu-devel] [PATCH] mount syscall
Fixed Debian patch in the attachment(lock_user_string used).
Index: linux-user/syscall.c
===
RCS file: /sources/qemu/qemu/linux-user/syscall.c,v
retrieving revision 1.86
diff -u -r1.86 syscall.c
--- linux-user/syscall.c11 Feb 2007 20:03:13 - 1.86
+++ linux-user/syscall.c12 Feb 2007 10:49:07 -
@@ -2163,8 +2163,18 @@
ret = get_errno(getpid());
break;
case TARGET_NR_mount:
-/* need to look at the data field */
-goto unimplemented;
+ {
+ /* need to look at the data field */
+ void *p2, *p3;
+ p = lock_user_string(arg1);
+ p2 = lock_user_string(arg2);
+ p3 = lock_user_string(arg3);
+ ret = get_errno(mount(p, p2, p3, (unsigned long)arg4,
(const void *)arg5));
+ unlock_user(p, arg1, 0);
+ unlock_user(p2, arg2, 0);
+ unlock_user(p3, arg3, 0);
+ break;
+ }
case TARGET_NR_umount:
p = lock_user_string(arg1);
ret = get_errno(umount(p));
signature.asc
Description: Digital signature
___
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel
[Qemu-devel] [PATCH] mount syscall
Fixed(with lock_user_string) patch in the attachment.
Index: linux-user/syscall.c
===
RCS file: /sources/qemu/qemu/linux-user/syscall.c,v
retrieving revision 1.86
diff -u -r1.86 syscall.c
--- linux-user/syscall.c11 Feb 2007 20:03:13 - 1.86
+++ linux-user/syscall.c12 Feb 2007 10:49:07 -
@@ -2163,8 +2163,18 @@
ret = get_errno(getpid());
break;
case TARGET_NR_mount:
-/* need to look at the data field */
-goto unimplemented;
+ {
+ /* need to look at the data field */
+ void *p2, *p3;
+ p = lock_user_string(arg1);
+ p2 = lock_user_string(arg2);
+ p3 = lock_user_string(arg3);
+ ret = get_errno(mount(p, p2, p3, (unsigned long)arg4,
(const void *)arg5));
+ unlock_user(p, arg1, 0);
+ unlock_user(p2, arg2, 0);
+ unlock_user(p3, arg3, 0);
+ break;
+ }
case TARGET_NR_umount:
p = lock_user_string(arg1);
ret = get_errno(umount(p));
signature.asc
Description: Digital signature
___
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel
[Qemu-devel] QEMU in Solaris Zone?
Hi all, did anybody try to run QEMU inside a Solaris Zone? ASAIK kernel-modules cannot be loaded in non-global zone, so this needs to be done in global zone. I wonder if this would work. And what about stability, networking and security issues? Cheers, Nenad Cimerman - workaholic. ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
[Qemu-devel] PATCH: Whole kqemu module can be natively built on Solaris now
( ... not the kqemu-wrapper alone [and then linked against foreign built object files, as until recently]. ) Only Makefiles needed to be ported. No real porting. But more testing was required, than one might have expected (#0._gld_vs._ld #1._mcmodel=kernel vs. -fpic) gdiff -Nurb against http://qemu.com/kqemu-1.3.0pre11.tar.gz : http://opensolaris.org/os/project/qemu/downloads/kqemu-1.3.0pre11__osol20070214.gdiff.bz2 Same gdiff, but without Eric Lowe's CDDL licensed kqemu-solaris wrapper code : http://opensolaris.org/os/project/qemu/downloads/kqemu-1.3.0pre11__osol20070214_WithoutEricLowesWRAPPER__kqemu-solaris.c__.gdiff.bz2 OPEN kqemu accelerator FULL src bins : http://opensolaris.org/os/project/qemu/downloads/kqemu-1.3.0pre11__sol10FCSplus_20070214_src_and_bins.tar.bz2 Juergen Keil's latest patch (enabling kqemu on old Sol10FCS based hosts) is embedded and compiled in. Thanks for the steadily increasing community involvement, testing and comments. Speacial thanks to Juergen Keil, Ben Taylor and Eric Lowe. p.s. SUNWqemu 0.9.0 sparc and x86/x64 (with Sittichai's TAP patch) will be released on 20070218. Thanks. [EMAIL PROTECTED] btw: kqemu may not be a wonder pill. But it does increase performance dramatically in _certain_ scenarios. Please start by reading the docs: http://qemu.com/kqemu-tech.html http://qemu.com/kqemu-doc.html http://qemu.com/kqemu-changelog.html ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
[Qemu-devel] How to get started __/__ Re: PATCH: Whole kqemu module can be natively built on Solaris now
OPEN kqemu accelerator FULL src bins : http://opensolaris.org/os/project/qemu/downloads/kqemu-1.3.0pre11__sol10FCSplus_20070214_src_and_bins.tar.bz2 --- A) To install precompiled module (on eitehr amd64 or i386): Step 0.) Extract and go into folder Step 1.) # gmake osol-install Step 2.) reconfigure devices or reboot host Step 3.) use it (see kqemu docs at www.qemu.com) B) To compile yourself (on either amd64 or i386 Solaris10_FCS or higher): Step 0.) Extract and go into folder Step 1.) # ./configure Step 2.) # gmake Step 3.) # gmake osol-install Step 4.) reconfigure devices or reboot host Step 5.) use it (see kqemu docs at www.qemu.com) Very general note: kqemu will only work if host-system-kernel == qemu-binary-target == qemu-guest. Please ensure that first, before wondering about kqemu related stderr output. ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
AW: [Qemu-devel] USB storage cannot be recognized on guest Linuxdomain?
Hi Xiaoyang, did you check whether both kernels are configured to support USB? # cat /proc/config or # zcat /proc/config.gz Cheers, Nenad. _ Von: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Im Auftrag von Yu, Xiaoyang Gesendet: Mittwoch, 14. Februar 2007 11:26 An: qemu-devel@nongnu.org Betreff: RE: [Qemu-devel] USB storage cannot be recognized on guest Linuxdomain? I just found that using an older kernel in Fedora Core 4 may “solve” the problem. When I tested Fedora Core 4 guest domain, the kernel version I used was 2.6. 17-1.2142_FC4, and it cannot recognized the USB disk. I just changed the kernel in guest domain to version 2.6.11-1.1369_FC4. Then the guest domain can recognized the USB disk. I am wondering why the USB support in QEMU depend on the guest domain kernel. And I would like to know which kernel version can support QEMU USB emulation. BTW, I also found that Windows XP guest domain can not recognize the USB disk, while Windows XP SP2 guest domain can recognize the USB disk. So it seems like that the guest Linux/Windows domain should have some “special feature” to work with the QEMU USB emulation successfully. Isn’t it strange? Sent: 2007年2月14日 15:06 To: qemu-devel@nongnu.org Subject: [Qemu-devel] USB storage cannot be recognized on guest Linux domain? I am using Xen 3.0.3 with QEMU-DM 0.8.2 on a Intel VT platform. After insert a USB storage, and use “usb_add” command in QEMU monitor, the storage should be recognized on guest OS. I tested this with a Windows XP SP2 guest OS, it doing well. But when I test the “usb_add” command with some Linux guest OS, it seems that the guest OS cannot recognize the USB storage. And the device number and address in guest domain are always “0.0”. The Linux guest OS I tested including Fedora Core 4 and Fedora Core 5. Does any one also meet this problem or have some idea on this? Feedbacks will be highly appreciated. Thanks Xiaoyang ___ 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 guestLinuxdomain?
Also I have tested QEMU 0.9.0 using image “linux-0.2.img”. After invoked “usb_add” in QEMU monitor, nothing was shown in guest domain. Then I type “exit” to reboot the system, then the following message shown in guest domain: scsi 0:0:0:0: Direct-Access Kingston DataTraveler 2.0 1.00 PQ: 0 ANSI:2 It seems like that the USB disk can be recognized only after a system reboot of “linux-0.2.img”. From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Yu, Xiaoyang Sent: 2007年2月14日 20:24 To: [EMAIL PROTECTED]; qemu-devel@nongnu.org Subject: RE: [Qemu-devel] USB storage cannot be recognized on guestLinuxdomain? Hi Nenad, Both kernels are configured to support USB devices. The config files are put in the attachment. USB storages can be recognized by both kernels successfully if I install the systems directly on hardware, instead of install the systems as guest domains in Xen/VT environment. Thanks Xiaoyang From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Nenad Cimerman Sent: 2007年2月14日 19:28 To: qemu-devel@nongnu.org Subject: AW: [Qemu-devel] USB storage cannot be recognized on guestLinuxdomain? Hi Xiaoyang, did you check whether both kernels are configured to support USB? # cat /proc/config or # zcat /proc/config.gz Cheers, Nenad. Von: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Im Auftrag von Yu, Xiaoyang Gesendet: Mittwoch, 14. Februar 2007 11:26 An: qemu-devel@nongnu.org Betreff: RE: [Qemu-devel] USB storage cannot be recognized on guest Linuxdomain? I just found that using an older kernel in Fedora Core 4 may “solve” the problem. When I tested Fedora Core 4 guest domain, the kernel version I used was 2.6.17-1.2142_FC4, and it cannot recognized the USB disk. I just changed the kernel in guest domain to version 2.6.11-1.1369_FC4. Then the guest domain can recognized the USB disk. I am wondering why the USB support in QEMU depend on the guest domain kernel. And I would like to know which kernel version can support QEMU USB emulation. BTW, I also found that Windows XP guest domain can not recognize the USB disk, while Windows XP SP2 guest domain can recognize the USB disk. So it seems like that the guest Linux/Windows domain should have some “special feature” to work with the QEMU USB emulation successfully. Isn’t it strange? Sent: 2007年2月14日 15:06 To: qemu-devel@nongnu.org Subject: [Qemu-devel] USB storage cannot be recognized on guest Linux domain? I am using Xen 3.0.3 with QEMU-DM 0.8.2 on a Intel VT platform. After insert a USB storage, and use “usb_add” command in QEMU monitor, the storage should be recognized on guest OS. I tested this with a Windows XP SP2 guest OS, it doing well. But when I test the “usb_add” command with some Linux guest OS, it seems that the guest OS cannot recognize the USB storage. And the device number and address in guest domain are always “0.0”. The Linux guest OS I tested including Fedora Core 4 and Fedora Core 5. Does any one also meet this problem or have some idea on this? Feedbacks will be highly appreciated. Thanks Xiaoyang ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] QEMU in Solaris Zone?
Yes, I have a Solaris zone in which I am running QEMU with NetBSD 3.0.1. It connects via OpenVPN to the parent zone and I can ssh into it as if it were a separate machine. Obviously since the zones are just virtualized there is no separate kernel so no modules. jonahtan On 2/14/07, Nenad Cimerman [EMAIL PROTECTED] wrote: Hi all, did anybody try to run QEMU inside a Solaris Zone? ASAIK kernel-modules cannot be loaded in non-global zone, so this needs to be done in global zone. I wonder if this would work… And what about stability, networking and security issues? Cheers, Nenad Cimerman – workaholic. ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel -- -- Jonathan Kalbfeld +1 323 620 6682 ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
[Qemu-devel] libusb-win32-filter-bin-0.1.10.2.exe - please check your system if you used this!
We apologize to announce that the USB filter driver for Windows was infected by Win32.Parite.b. Please check your computer by an anti-virus software, if you use this driver: http://gnome.dnsalias.net/patches/libusb-win32-filter-bin-0.1.10.2.exe The server is hosted on Linux so we are not exactly sure how this file was infected. The file downloaded at 2006/11/21 is not infected. It seems that it has been infected recently. The file has been removed for inspection until a clean build can be uploaded. Sorry for the inconvenience. Lonnie Mendez, Kazu ___ 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 Wed, 2007-02-14 at 18:26 +0800, Yu, Xiaoyang wrote: BTW, I also found that Windows XP guest domain can not recognize the USB disk, while Windows XP SP2 guest domain can recognize the USB disk. So it seems like that the guest Linux/Windows domain should have some “special feature” to work with the QEMU USB emulation successfully. Isn’t it strange? The uhci emulation has no suspend/resume support. From your description this is exactly the problem you are seeing. ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
[Qemu-devel] [PATCH] Fix crash after char device read returns 0
qemu 0.9.0 on Linux crashes with SIGSEGV after read() on a char device
returns 0, which occurs if the char device is a fifo and the writer
closes the file.
In this case, fd_chr_read() and stdio_read() react by removing the IO
handler and freeing it. Unfortunately main_loop_wait() is unprepared
to deal with this (as the comment XXX: better handling of removal
suggests) and attempts to access the freed handler.
Even if main_loop_wait() were improved, it is not correct to remove
the IO handler just because read() returns 0: if the char device is a
fifo, a process may well reopen the fifo for writing at a later point.
The attached patch is a naive fix; feedback is welcome.
--Ed
Index: qemu-snapshot-2007-02-09_05/vl.c
===
--- qemu-snapshot-2007-02-09_05.orig/vl.c
+++ qemu-snapshot-2007-02-09_05/vl.c
@@ -1346,11 +1346,13 @@ static void fd_chr_read(void *opaque)
if (len == 0)
return;
size = read(s-fd_in, buf, len);
+#if 0
if (size == 0) {
/* FD has been closed. Remove it from the active list. */
qemu_set_fd_handler2(s-fd_in, NULL, NULL, NULL, NULL);
return;
}
+#endif
if (size 0) {
qemu_chr_read(chr, buf, size);
}
@@ -1546,11 +1548,13 @@ static void stdio_read(void *opaque)
uint8_t buf[1];
size = read(0, buf, 1);
+#if 0
if (size == 0) {
/* stdin has been closed. Remove it from the active list. */
qemu_set_fd_handler2(0, NULL, NULL, NULL, NULL);
return;
}
+#endif
if (size 0)
stdio_received_byte(buf[0]);
}
___
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel
[Qemu-devel] ARM post-decrement fix
I'm pretty sure that this is needed for strd r4, [r9], -#8 to work.
We start with 8, add -4 to offset for the 4 that was added (before the
second 32-bit store), negate it as requested yielding -4, add it to
the +4-adjusted offset, and get... net of zero.
--- target-arm/translate.c (revision 163253)
+++ target-arm/translate.c (local)
@@ -391,9 +391,9 @@ static inline void gen_add_datah_offset(
if (insn (1 22)) {
/* immediate */
val = (insn 0xf) | ((insn 4) 0xf0);
-val += extra;
if (!(insn (1 23)))
val = -val;
+val += extra;
if (val != 0)
gen_op_addl_T1_im(val);
} else {
--
Daniel Jacobowitz
CodeSourcery
___
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel
[Qemu-devel] qemu/target-arm translate.c
CVSROOT:/sources/qemu Module name:qemu Changes by: Paul Brook pbrook 07/02/14 20:17:04 Modified files: target-arm : translate.c Log message: ARM doubleword post-modify fix (Daniel Jacobowitz). CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/qemu/target-arm/translate.c?cvsroot=qemur1=1.44r2=1.45 ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
[Qemu-devel] Re: [PATCH] LinuxBIOS support: map BIOS into ISA address space as RAM instead of ROM
On 2/13/07, Ed Swierk [EMAIL PROTECTED] wrote: This patch changes qemu to map the BIOS into ISA address space as RAM instead of ROM, allowing LinuxBIOS to run on qemu with no further modifications (although the DRAM size is still not detected properly). Unfortunately this isn't the right answer, as modifying the BIOS area messes things up on soft reboot. What we really want is shadow RAM support, which Bochs seems to support but qemu doesn't. --Ed ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
[Qemu-devel] [PATCH 1/1] Making pxe working in the NAT mode
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.
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.
diff -rub slirp.old/bootp.c slirp/bootp.c
--- slirp.old/bootp.c 2007-02-06 00:01:54.0 +0100
+++ slirp/bootp.c 2007-02-14 22:44:02.0 +0100
@@ -82,7 +82,7 @@
}
static void dhcp_decode(const uint8_t *buf, int size,
-int *pmsg_type)
+int *pmsg_type, int *pxe_request)
{
const uint8_t *p, *p_end;
int len, tag;
@@ -114,6 +114,11 @@
if (len = 1)
*pmsg_type = p[0];
break;
+case RFC1533_CLASSIDENTIFIER:
+ if ((strncmp(p,PXEClient,9) == 0) || (strncmp(p,Etherboot,9) == 0)) {
+ *pxe_request=1;
+ }
+ break;
default:
break;
}
@@ -131,9 +136,10 @@
struct in_addr dns_addr;
int dhcp_msg_type, val;
uint8_t *q;
+int pxe_request=0;
/* extract exact DHCP msg type */
-dhcp_decode(bp-bp_vend, DHCP_OPT_LEN, dhcp_msg_type);
+dhcp_decode(bp-bp_vend, DHCP_OPT_LEN, dhcp_msg_type,pxe_request);
dprintf(bootp packet op=%d msgtype=%d\n, bp-bp_op, dhcp_msg_type);
if (dhcp_msg_type == 0)
@@ -168,6 +174,12 @@
goto new_addr;
}
}
+
+if (pxe_request==1) {
+ printf(PXE Request Detected, setting filename\n);
+ strcpy(rbp-bp_file,/pxelinux.0);
+}
+
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 -rub slirp.old/bootp.h slirp/bootp.h
--- slirp.old/bootp.h 2007-02-06 00:01:54.0 +0100
+++ slirp/bootp.h 2007-02-14 22:12:48.0 +0100
@@ -57,6 +57,7 @@
#define RFC1533_NBSCOPE 47
#define RFC1533_XFS 48
#define RFC1533_XDM 49
+#define RFC1533_CLASSIDENTIFIER 60
#define RFC2132_REQ_ADDR 50
#define RFC2132_LEASE_TIME 51
Seulement dans slirp: bootp.h~
Seulement dans slirp: debug.c~
diff -rub slirp.old/tftp.c slirp/tftp.c
--- slirp.old/tftp.c 2007-02-06 00:01:54.0 +0100
+++ slirp/tftp.c 2007-02-14 22:09:16.0 +0100
@@ -120,6 +120,49 @@
return bytes_read;
}
+static int tftp_send_oack(struct tftp_session *spt,
+ int errorcode, const char *msg,
+ struct tftp_t *recv_tp)
+{
+ struct sockaddr_in saddr, daddr;
+ struct mbuf *m;
+ struct tftp_t *tp;
+ int nobytes;
+ char errcode[16];
+ m = m_get();
+
+ if (!m) {
+return -1;
+ }
+
+ memset(m-m_data, 0, m-m_size);
+
+ m-m_data += if_maxlinkhdr;
+ tp = (void *)m-m_data;
+ m-m_data += sizeof(struct udpiphdr);
+
+ tp-tp_op = htons(TFTP_OACK);
+ strcpy(tp-x.tp_buf,msg);
+ sprintf(tp-x.tp_buf+strlen(msg)+1,%u,errorcode);
+ sprintf(errcode,%u,errorcode);
+
+ saddr.sin_addr = recv_tp-ip.ip_dst;
+ saddr.sin_port = recv_tp-udp.uh_dport;
+
+ daddr.sin_addr = spt-client_ip;
+ daddr.sin_port = spt-client_port;
+
+ nobytes = 2;
+
+ m-m_len = sizeof(struct tftp_t) - 514 + 2 + strlen(errcode) + strlen(msg) -
+sizeof(struct ip) - sizeof(struct udphdr);
+ udp_output2(NULL, m, saddr, daddr,
Re: [Qemu-devel] Re: [PATCH] LinuxBIOS support: map BIOS into ISA address space as RAM instead of ROM
Ed Swierk wrote: On 2/13/07, Ed Swierk [EMAIL PROTECTED] wrote: This patch changes qemu to map the BIOS into ISA address space as RAM instead of ROM, allowing LinuxBIOS to run on qemu with no further modifications (although the DRAM size is still not detected properly). Unfortunately this isn't the right answer, as modifying the BIOS area messes things up on soft reboot. What we really want is shadow RAM support, which Bochs seems to support but qemu doesn't. Shadow RAM is supported in QEMU and I modified the Bochs BIOS to use it. So you do not need to do any patch in QEMU for it. Please read the rombios32.c source in the Bochs BIOS to know what to do in LinuxBIOS. To be precise, one case of RAM shadowing is not implemented (read from BIOS, write to RAM), but it is not strictly needed to write data in the shadow RAM. I needed it once to run a real Award BIOS in QEMU, but I did not have the time to clean up the patch to commit it. Regards, Fabrice. ___ 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?
Thanks a lot for the instruction. Will the suspend/resume support be added in the future release? Without the suspend/resume support, is there anything can be done in the guest domain to help detect a USB device? Maybe patch the kernel? Thanks Xiaoyang -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Lonnie Mendez Sent: 2007年2月14日 23:01 To: qemu-devel@nongnu.org Subject: RE: [Qemu-devel] USB storage cannot be recognized on guest Linuxdomain? On Wed, 2007-02-14 at 18:26 +0800, Yu, Xiaoyang wrote: BTW, I also found that Windows XP guest domain can not recognize the USB disk, while Windows XP SP2 guest domain can recognize the USB disk. So it seems like that the guest Linux/Windows domain should have some “special feature” to work with the QEMU USB emulation successfully. Isn’t it strange? The uhci emulation has no suspend/resume support. From your description this is exactly the problem you are seeing. ___ 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?
On Thu, 2007-02-15 at 10:36 +0800, Yu, Xiaoyang wrote: Thanks a lot for the instruction. Will the suspend/resume support be added in the future release? Without the suspend/resume support, is there anything can be done in the guest domain to help detect a USB device? Maybe patch the kernel? For windows you can disable the power management for the controller. That will cause windows to constantly poll hub status. For linux you have to reload the uhci hcd driver. Notice that starting qemu with -usbdevice works. The code to implement this is very easy. You basically set/clear some bits and trigger an interrupt. See list archives for example code. ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
