[Qemu-devel] the problem of booting linux kernel from NFS
Hi,All: I want to boot kernel from NFS, so I compile a kernel supported NFS & TUN/TAP device and change the /etc/qemu-ifup like this: #!/bin/sh sudo -p "Password for $0:" /sbin/ifconfig $1 192.168.15.1 when I boot the new kernel, there is the message : IP-Config: No network device available Looking up port of RPC 13/2 on 192.168.15.1 and the kernel cannot mount the root fs.but the kernel has the network device driver. What is the reason? and What should I solve it? the command is : qemu -net nic -net tap -kernel /usr/src/linux/arch/i386/boot/bzImage -hda /dev/zero -append "ip=192.168.15.110 root=/dev/nfs nfsroot= 192.168.15.1:/scratchbox/users/newbee/targets/ambition" Thanks Regards, HanLiang -- Mail:[EMAIL PROTECTED] MSN:[EMAIL PROTECTED] Keep Contact^_^
Re: [Qemu-devel] [PATCH] fix possible NULL pointer use in hw/ptimer.c
Paul Brook wrote: s = (ptimer_state *)qemu_mallocz(sizeof(ptimer_state)); +if (!s) +return NULL; None of the callers bother to check the return value, And even if they did I don't think there's any point trying to gracefully handle OOM. Just abort and be done with it. I am in the process of fixing the sparc ptimer caller to gracefully handle OOM. We currently don't check the return value in the init function where the new timer is created but do check it wherever it is used which is backwards and wasteful. You would prefer that qemu just segfaults rather than die gracefully?
Re: [Qemu-devel] [PATCH] fix possible NULL pointer use in hw/ptimer.c
> s = (ptimer_state *)qemu_mallocz(sizeof(ptimer_state)); > + if (!s) > + return NULL; None of the callers bother to check the return value, And even if they did I don't think there's any point trying to gracefully handle OOM. Just abort and be done with it. I suggest guaranteeing that qemu_malloc will never return NULL, and removing the null checks from all the various users. Paul
[Qemu-devel] [PATCH] fix possible NULL pointer use in hw/ptimer.c
diff -p -u -r1.5 ptimer.c --- hw/ptimer.c 17 Nov 2007 17:14:47 - 1.5 +++ hw/ptimer.c 3 Jan 2008 02:27:18 - @@ -185,6 +185,8 @@ ptimer_state *ptimer_init(QEMUBH *bh) ptimer_state *s; s = (ptimer_state *)qemu_mallocz(sizeof(ptimer_state)); +if (!s) +return NULL; s->bh = bh; s->timer = qemu_new_timer(vm_clock, ptimer_tick, s); return s;
[Qemu-devel] [PATCH] fix possible NULL pointer use in vl.c
diff -p -u -r1.392 vl.c --- vl.c28 Dec 2007 20:59:23 - 1.392 +++ vl.c3 Jan 2008 02:20:42 - @@ -985,6 +985,8 @@ QEMUTimer *qemu_new_timer(QEMUClock *clo QEMUTimer *ts; ts = qemu_mallocz(sizeof(QEMUTimer)); +if (!ts) +return NULL; ts->clock = clock; ts->cb = cb; ts->opaque = opaque;
Re: [Qemu-devel] qemu cpu-all.h exec.c
On Wednesday 02 January 2008, Blue Swirl wrote: > On 1/2/08, Paul Brook <[EMAIL PROTECTED]> wrote: > > > Also the opaque parameter may need to be different for each function, > > > it just didn't matter for the unassigned memory case. > > > > Do you really have systems where independent devices need to respond to > > different sized accesses to the same address? > > I don't think so. But one day unassigned or even normal RAM memory > access may need an opaque parameter, so passing the device's opaque to > unassigned memory handler is wrong. I'm not convinced. Your current implementation seems to introduce an extra level of indirection without any plausible benefit. If you're treating unassigned memory differently it needs to be handled much earlier that so you can raise CPU exceptions. Paul
Re: [Qemu-devel] [PATCH][PPC] Use float32/64 instead of float/double
On Sun, Dec 30, 2007 at 06:32:45PM +0200, Blue Swirl wrote:
> On 12/30/07, Aurelien Jarno <[EMAIL PROTECTED]> wrote:
> > The patch below changes the float and double types into float32 and
> > and float64 types in the PPC code. This doesn't change anything when
> > using softfloat-native as the types are the same, but that helps
> > compiling the PPC target with softfloat.
>
> You could also consider replacing the unions with the common
> definition CPU_DoubleU in cpu-all.h and also add CPU_FloatU.
Good idea. Please find and updated patch below.
The patch below uses the float32 and float64 types instead of the float
and double types in the PPC code. This doesn't change anything when
using softfloat-native as the types are the same, but that helps
compiling the PPC target with softfloat.
It also defines a new union CPU_FloatU in addition to CPU_DoubleU, and
use them instead of identical unions that are defined in numerous
places.
cpu-all.h |5
target-ppc/op.c| 83 ++--
target-ppc/op_helper.c | 418 +++--
target-ppc/op_helper.h | 104 +++
target-ppc/op_helper_mem.h | 18 -
target-ppc/op_mem.h| 69 ++-
6 files changed, 240 insertions(+), 457 deletions(-)
Index: cpu-all.h
===
RCS file: /sources/qemu/qemu/cpu-all.h,v
retrieving revision 1.81
diff -u -d -p -r1.81 cpu-all.h
--- cpu-all.h 1 Jan 2008 16:57:19 - 1.81
+++ cpu-all.h 2 Jan 2008 23:21:06 -
@@ -116,6 +116,11 @@ static inline void tswap64s(uint64_t *s)
#define bswaptls(s) bswap64s(s)
#endif
+typedef union {
+float32 f;
+uint32_t l;
+} CPU_FloatU;
+
/* NOTE: arm FPA is horrible as double 32 bit words are stored in big
endian ! */
typedef union {
Index: target-ppc/op.c
===
RCS file: /sources/qemu/qemu/target-ppc/op.c,v
retrieving revision 1.68
diff -u -d -p -r1.68 op.c
--- target-ppc/op.c 16 Nov 2007 14:11:28 - 1.68
+++ target-ppc/op.c 2 Jan 2008 23:21:06 -
@@ -585,47 +585,28 @@ void OPPROTO op_float_check_status (void
}
#endif
-#if defined(WORDS_BIGENDIAN)
-#define WORD0 0
-#define WORD1 1
-#else
-#define WORD0 1
-#define WORD1 0
-#endif
void OPPROTO op_load_fpscr_FT0 (void)
{
/* The 32 MSB of the target fpr are undefined.
* They'll be zero...
*/
-union {
-float64 d;
-struct {
-uint32_t u[2];
-} s;
-} u;
+CPU_DoubleU u;
-u.s.u[WORD0] = 0;
-u.s.u[WORD1] = env->fpscr;
+u.l.upper = 0;
+u.l.lower = env->fpscr;
FT0 = u.d;
RETURN();
}
void OPPROTO op_set_FT0 (void)
{
-union {
-float64 d;
-struct {
-uint32_t u[2];
-} s;
-} u;
+CPU_DoubleU u;
-u.s.u[WORD0] = 0;
-u.s.u[WORD1] = PARAM1;
+u.l.upper = 0;
+u.l.lower = PARAM1;
FT0 = u.d;
RETURN();
}
-#undef WORD0
-#undef WORD1
void OPPROTO op_load_fpscr_T0 (void)
{
@@ -3241,27 +3222,21 @@ void OPPROTO op_efststeq (void)
void OPPROTO op_efdsub (void)
{
-union {
-uint64_t u;
-float64 f;
-} u1, u2;
-u1.u = T0_64;
-u2.u = T1_64;
-u1.f = float64_sub(u1.f, u2.f, &env->spe_status);
-T0_64 = u1.u;
+CPU_DoubleU u1, u2;
+u1.ll = T0_64;
+u2.ll = T1_64;
+u1.d = float64_sub(u1.d, u2.d, &env->spe_status);
+T0_64 = u1.ll;
RETURN();
}
void OPPROTO op_efdadd (void)
{
-union {
-uint64_t u;
-float64 f;
-} u1, u2;
-u1.u = T0_64;
-u2.u = T1_64;
-u1.f = float64_add(u1.f, u2.f, &env->spe_status);
-T0_64 = u1.u;
+CPU_DoubleU u1, u2;
+u1.ll = T0_64;
+u2.ll = T1_64;
+u1.d = float64_add(u1.d, u2.d, &env->spe_status);
+T0_64 = u1.ll;
RETURN();
}
@@ -3297,27 +3272,21 @@ void OPPROTO op_efdneg (void)
void OPPROTO op_efddiv (void)
{
-union {
-uint64_t u;
-float64 f;
-} u1, u2;
-u1.u = T0_64;
-u2.u = T1_64;
-u1.f = float64_div(u1.f, u2.f, &env->spe_status);
-T0_64 = u1.u;
+CPU_DoubleU u1, u2;
+u1.ll = T0_64;
+u2.ll = T1_64;
+u1.d = float64_div(u1.d, u2.d, &env->spe_status);
+T0_64 = u1.ll;
RETURN();
}
void OPPROTO op_efdmul (void)
{
-union {
-uint64_t u;
-float64 f;
-} u1, u2;
-u1.u = T0_64;
-u2.u = T1_64;
-u1.f = float64_mul(u1.f, u2.f, &env->spe_status);
-T0_64 = u1.u;
+CPU_DoubleU u1, u2;
+u1.ll = T0_64;
+u2.ll = T1_64;
+u1.d = float64_mul(u1.d, u2.d, &env->spe_status);
+T0_64 = u1.ll;
RETURN();
}
Index: target-ppc/op_helper.c
===
RCS file: /sources/qemu/qemu/target-ppc/op_helper.c,v
retrieving revision 1.73
diff -u -d -p -r1.73 op_helper.c
--- target-ppc/op_helper.c 24 Nov 2007 02:03:55 - 1.73
+++ target-ppc
[Qemu-devel] qemu exec.c
CVSROOT:/cvsroot/qemu Module name:qemu Changes by: Blue Swirl 08/01/02 19:45:26 Modified files: . : exec.c Log message: Fix dynamically changed memory callbacks and passed opaque parameter CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/qemu/exec.c?cvsroot=qemu&r1=1.121&r2=1.122
Re: [Qemu-devel] Re: [RFC] 64 bit i/o
On 1/2/08, Brian Johnson <[EMAIL PROTECTED]> wrote: > Robert Reif wrote: > > Paul Brook wrote: > >> > >> Couldn't you just latch the value when one half is accessed? > >> > > In this one specific case you could do that but this is not the only > > case in sparc32 (TOD, MXCC, ...) and other architectures with 64 bit > > hardware have similar requirements. > > > > This is a generic solution that fills a hole in the qemu > > implementation. > > Agreed. Some non-PC hardware has 64-bit registers which need to be > accessed as 64-bit quantities, in order to read or write all fields at > once. Qemu should support 64-bit I/O. On Sparc64 many registers can only be handled using 64 bit accesses, other methods should raise an exception.
Re: [Qemu-devel] qemu cpu-all.h exec.c
On 1/2/08, Paul Brook <[EMAIL PROTECTED]> wrote: > > Also the opaque parameter may need to be different for each function, > > it just didn't matter for the unassigned memory case. > > Do you really have systems where independent devices need to respond to > different sized accesses to the same address? I don't think so. But one day unassigned or even normal RAM memory access may need an opaque parameter, so passing the device's opaque to unassigned memory handler is wrong.
Re: [Qemu-devel] qemu cpu-all.h exec.c
> Also the opaque parameter may need to be different for each function, > it just didn't matter for the unassigned memory case. Do you really have systems where independent devices need to respond to different sized accesses to the same address? Paul
Re: [Qemu-devel] qemu cpu-all.h exec.c
On 1/1/08, Fabrice Bellard <[EMAIL PROTECTED]> wrote: > This patch breaks the behaviour of the memory callbacks if the callbacks > are changed dynamically (see cirrus_update_memory_access() to see what I > mean). You are lucky that no one does that in the subpage case ! I'll change the function pointer to a pointer to function pointer. Also the opaque parameter may need to be different for each function, it just didn't matter for the unassigned memory case.
[Qemu-devel] Usb mouse fix
Hi,
i think ive found a little bug on the usb mouse emulation (only with the
mouse, not the tablet), the wheel doesnt seem to work (it just doesnt do
anything). Ive tracked the problem down to usb-hid.c:
static const uint8_t qemu_mouse_hid_report_descriptor[] = {
0x05, 0x01, 0x09, 0x02, 0xA1, 0x01, 0x09, 0x01,
0xA1, 0x00, 0x05, 0x09, 0x19, 0x01, 0x29, 0x03,
0x15, 0x00, 0x25, 0x01, 0x95, 0x03, 0x75, 0x01,
0x81, 0x02, 0x95, 0x01, 0x75, 0x05, 0x81, 0x01,
0x05, 0x01, 0x09, 0x30, 0x09, 0x31, 0x15, 0x81,
0x25, 0x7F, 0x75, 0x08, 0x95, 0x02, 0x81, 0x06,
0xC0, 0xC0,
};
That descriptor doesnt contain a 'wheel' section so when the virtualized OS
gives me the TD it only has space for dx and dy and not for the wheel delta
(its got a maximum length of 3). To fix the problem i just modified the
descriptor, here is the new one:
static const uint8_t qemu_mouse_hid_report_descriptor[] = {
0x05, 0x01, 0x09, 0x02, 0xA1, 0x01, 0x09, 0x01,
0xA1, 0x00, 0x05, 0x09, 0x19, 0x01, 0x29, 0x03,
0x15, 0x00, 0x25, 0x01, 0x95, 0x03, 0x75, 0x01,
0x81, 0x02, 0x95, 0x01, 0x75, 0x05, 0x81, 0x01,
0x05, 0x01, 0x09, 0x30, 0x09, 0x31, 0x15, 0x81,
0x25, 0x7F, 0x75, 0x08, 0x95, 0x02, 0x81, 0x06,
0x05, 0x01, 0x09, 0x38, 0x15, 0x81, 0x25, 0x7F,
0x35, 0x00, 0x45, 0x00, 0x75, 0x08, 0x95, 0x01,
0x81, 0x02, 0xC0, 0xC0,
};
Now the virtualized OS gives me a TD with a maximum length of 4 and the
wheel works just fine.
Cheers,
Daniel
[Qemu-devel] Re: [RFC] 64 bit i/o
Robert Reif wrote: Paul Brook wrote: Couldn't you just latch the value when one half is accessed? In this one specific case you could do that but this is not the only case in sparc32 (TOD, MXCC, ...) and other architectures with 64 bit hardware have similar requirements. This is a generic solution that fills a hole in the qemu implementation. Agreed. Some non-PC hardware has 64-bit registers which need to be accessed as 64-bit quantities, in order to read or write all fields at once. Qemu should support 64-bit I/O. Brian
Re: [Qemu-devel] [RFC] 64 bit i/o
Paul Brook wrote: On Wednesday 02 January 2008, Robert Reif wrote: Sparc32 has a 64 bit counter that should be read and written as 64 bits but that isn't supported in QEMU. I did a quick hack to add 64 bit i/o and converted sparc32 to use it and it seems to work. I'm suppling the sparc changes to get comments on if this is worth pursuing. Couldn't you just latch the value when one half is accessed? Paul In this one specific case you could do that but this is not the only case in sparc32 (TOD, MXCC, ...) and other architectures with 64 bit hardware have similar requirements. This is a generic solution that fills a hole in the qemu implementation.
Re: [Qemu-devel] [RFC] 64 bit i/o
On Wednesday 02 January 2008, Robert Reif wrote: > Sparc32 has a 64 bit counter that should be read and written as 64 > bits but that isn't supported in QEMU. I did a quick hack to add > 64 bit i/o and converted sparc32 to use it and it seems to work. > I'm suppling the sparc changes to get comments on if this is worth > pursuing. Couldn't you just latch the value when one half is accessed? Paul
Re: [Qemu-devel] bug in qemu last win32 snapshot (12132007)
On Wed, 2 Jan 2008 01:09:09 -0700, "c.w. Betts" <[EMAIL PROTECTED]> said: > You have to use double slashes, like "\\". > - Original Message - > > "-hda ..\toto.img" does not works > > moving toto.img to the directory and modify commandline to "-hda > > toto.img" works ! hello, thanks of your answer. it works well... ... but it is a new information to write inside win documentation because if i use qemu-0.9.0 windows stable build "\\" is not mandatory... --- Sébastien WILLEMIJNS
Re: [Qemu-devel] bug in qemu last win32 snapshot (12132007)
You have to use double slashes, like "\\". On POSIX systems, the "\" basically says to use a special character (i.e. \n is a new line \t is a tab). However, on DOS systems, it is used to show a directory. Using two of those slashes, you will be passing to qemu that you want to use a directory, and not a special character - Original Message - From: "Sebastien WILLEMIJNS" <[EMAIL PROTECTED]> To: Sent: Tuesday, January 01, 2008 5:05 PM Subject: [Qemu-devel] bug in qemu last win32 snapshot (12132007) (cc to the windows dev port) hello, happy new year C:\qemu4windows\qemu-0.9.0-windows>if exist ..\qemusave\kqemu-1.3.0pre11.tar.gz qemu -kernel-kqemu -soundhw all -m 256 -L \qemu4windows\qemu-0.9.0-windows -cdro m e:\knoppix.iso -boot d -hda ..\toto.img -net nic,vlan=0,model=rtl8139 -net use r,vlan=0,hostname=foo qemu: could not open disk image ..toto.img "-hda ..\toto.img" does not works moving toto.img to the directory and modify commandline to "-hda toto.img" works ! config: XP SP2 French 100% patched.
