[Qemu-devel] Qemu forum down again
http://qemu-forum.ipi.fi/ General Error SQL ERROR [ mysql4 ] Lost connection to MySQL server during query [2013] An sql error occurred while fetching this page. Please contact an administrator if this problem persists. I have emailed Pablo but to no avail. Has anybody a direct contact with Pablo and inform him of the incident? -- Ottavio Caruso http://www.pledgebank.com/boycottvista
Re: [Qemu-devel] qemu on alpha
It seems I cannot send email to the mailing list from
my personal email account. Anyway...
Here is what I discovered debugging the failure.
Is there anyone who can direct me to the next step?
thanks,
GG
> Forwarded Message
> From: Gabriele Gorla <[EMAIL PROTECTED]>
> To: qemu-devel@nongnu.org
> Subject: Re: [Qemu-devel] qemu on alpha
> Date: Sat, 16 Feb 2008 22:11:21 -0800
>
> Thiemo,
> thanks for your previous reply.
> I finally managed to compile qemu 0.9.1 on my
> machine (alpha ev68).
>
> I had to add (as you suggested) the definition for
> GOTO_LABEL_PARAM:
> #define GOTO_LABEL_PARAM(n) asm volatile ("jmp
> "ASM_NAME(__op_gen_label)
> #n)
>
> and I had to remove the -msmall-data option from the
> Makefile.target to
> make qemu link proprely.
>
> Unfortunately I still can't run anything as qemu
> crashes very quickly
> when trying to execute the generated code.
>
> Using gdb combined with qemu debug features I was
> able to narrow down
> the crash to the following instruction sequence:
>
>
> IN:
> 0x400839f9: pop%ebx
> 0x400839fa: add$0x1104f,%ebx
> 0x40083a00: xor%eax,%eax
> 0x40083a02: lea0xfdec(%ebp),%edi
> 0x40083a08: lea0xfffeefa0(%ebx),%esi
> 0x40083a0e: sub0x84(%ebx),%esi
> 0x40083a14: lea0xfdbc(%ebp),%edx
> 0x40083a1a: mov%edx,0xfd90(%ebp)
> 0x40083a20: lea0xfdc0(%ebp),%ecx
> 0x40083a26: mov%ecx,0xfda0(%ebp)
> 0x40083a2c: lea0xfdc4(%ebp),%edx
> 0x40083a32: mov%edx,0xfd9c(%ebp)
> 0x40083a38: lea0xfdd4(%ebp),%ecx
> 0x40083a3e: mov%ecx,0xfd94(%ebp)
> 0x40083a44: mov%edi,%edx
> 0x40083a46: movl $0x0,(%edx,%eax,4)
> 0x40083a4d: inc%eax
> 0x40083a4e: cmp$0x61,%eax
> 0x40083a51: jbe0x40083a46
>
> OUT: [size=936]
> 0x60589bb0: mov s4,s2
> 0x60589bb4: zapnot s2,0xf,t0
> 0x60589bb8: ldl s0,0(t0)
> 0x60589bbc: lda s4,4(s4)
> 0x60589bc0: stl s0,12(fp)
> 0x60589bc4: ldah gp,24606
> ...
> ...
> 0x60589e7c: ldah t0,0
> 0x60589e80: lda t0,16(t0)
> 0x60589e84: mov t0,t1
> 0x60589e88: stl t1,48(fp)
> 0x60589e8c: ldl t1,40(fp)
> 0x60589e90: ldl t0,44(fp)
> 0x60589e94: addl t0,t1,t0
> 0x60589e98: cmpule t0,t1,t0
> 0x60589e9c: beq t0,0x60589ea8
> 0x60589ea0: lda t12,-22256(gp)
> 0x60589ea4: br0x6071d244 < branch to
> uninitialized memory
> 0x60589ea8: ldah gp,24606
> 0x60589eac: lda gp,-12160(gp)
> 0x60589eb0: ldah t0,24613
> 0x60589eb4: lda t0,-25936(t0)
> ...
> ...
>
> given the original instruction sequence I am a bit
> puzzled about the
> source of the offending branch instruction in the
> generated code.
>
> do you have any suggestion on how to proceed?
>
> thank,
> GG
>
Be a better friend, newshound, and
know-it-all with Yahoo! Mobile. Try it now.
http://mobile.yahoo.com/;_ylt=Ahu06i62sR8HDtDypao8Wcj9tAcJ
[Qemu-devel] bug (?) related to kqemu and/or Minix3
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hello, I (and others) have observed the following problem with kqemu If you take Minix3 harddisk image such as: http://altair.sk/uploads/minix.img.gz and if you try to boot it via QEMU without kqemu qemu -hda minix.img -no-kqemu there are no problems. http://altair.sk/uploads/no-problem.png However, if you do the same but you try to use kqemu qemu -hda minix.img booting of the kernel halts in the middle. http://altair.sk/uploads/problem.png Do you think that this is a bug in Minix or in kqemu module? Best regards - -- Matej -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFHw+aQL+CaXfJI/hgRAlepAJ4hqKv1P51pm+k/rebxNHCzaTW7iACgwKrT Rgv4l+3YW2CJybke119obEI= =0veM -END PGP SIGNATURE-
Re: [Qemu-devel] Qemu forum down again
Ottavio Caruso wrote: http://qemu-forum.ipi.fi/ General Error SQL ERROR [ mysql4 ] Lost connection to MySQL server during query [2013] An sql error occurred while fetching this page. Please contact an administrator if this problem persists. I have emailed Pablo but to no avail. Has anybody a direct contact with Pablo and inform him of the incident? mysqld is back on qemu-forum.ipi.fi The database was corrupted. Pablo
Re: [Qemu-devel] qemu on alpha
Gabriele Gorla wrote: > It seems I cannot send email to the mailing list from > my personal email account. Anyway... > Here is what I discovered debugging the failure. > Is there anyone who can direct me to the next step? Things have changed considerably in the last few weeks. The code generator is now TCG, which works currently only on x86 and x86_64 hosts. So you would need to create a TCG version for Alpha. Have a look at the tcg subdirectory in the CVS version. Thiemo
Re: [Qemu-devel] [PATCH] ide.c make write cacheing controllable by guest
Jamie Lokier writes ("Re: [Qemu-devel] [PATCH] ide.c make write cacheing
controllable by guest"):
> However, I notice that it tells the guest that data is committed to
> hard storage when the host has merely called fsync().
Yes, that's what fsync is supposed to do.
> On Linux (and other host OSes), fdatsync() and fsync() don't always
> commit data to hard storage; it sometimes only commits it to the hard
> drive cache. (Seriously, just look at fs/ext3/fsync.c; only journal
> writes cause the flush, and they aren't done if the inode itself
> hasn't changed).
As Chris Wedgwood says, I think this is a bug. I was going to quote
SuSv3 but sadly it's very vague.
> Ideally, the host would provide variation of fdatasync() which flushes
> data to hard storage in the same way that kernel filesystem journal
> writes can do, and Qemu would use that.
Another question arises: do we want bdrv_flush to call (eventually)
fsync or fdatasync ? If the latter we need to make sure that we call
fsync instead when necessary, for example when a cow file is extended.
Ian.
[Qemu-devel] [PATCH] don't die if switching to fullscreen mode fails
hi,
the attached patch fixes some glitches when switching to fullscreen mode
using ctrl+alt+f or when booting using -full-screen.
up to now the VM simply dies if one of the following situations occur:
* user switches from windowed to fullscreen mode using a resolution
which is too high (meaning higher than the maximum resolution of the
display)
* guest boots in fullscreen mode using a resolution which is too high
* guest is in fullscreen mode and the user switches to a resolution
which is too high
IMO this is not what the "normal" user would expect.
This patch changes the behaviour as follows:
* deny switching to fullscreen mode if the resolution is too high and
print a message to the console
* use windowed mode as fallback option if we are already in
fullscreen mode and the new resolution is too high and print a message
to the console
cheers,
Andi
--- qemu/sdl.c 2007-11-17 18:14:38.0 +0100
+++ qemu/sdl.c 2008-02-26 13:32:29.0 +0100
@@ -56,46 +56,60 @@ static void sdl_update(DisplayState *ds,
SDL_UpdateRect(screen, x, y, w, h);
}
-static void sdl_resize(DisplayState *ds, int w, int h)
+static int sdl_resize2(DisplayState *ds, int w, int h, int full_screen, int no_frame)
{
+SDL_Surface *screen_tmp;
int flags;
-//printf("resizing to %d %d\n", w, h);
+//printf("trying to resize from w=%d h=%d %s to w=%d h=%d %s\n", width, height, gui_fullscreen ? "fullscreen" : "windowed", w, h, full_screen ? "fullscreen" : "windowed");
flags = SDL_HWSURFACE|SDL_ASYNCBLIT|SDL_HWACCEL;
-if (gui_fullscreen)
+if (full_screen)
flags |= SDL_FULLSCREEN;
-if (gui_noframe)
+if (no_frame)
flags |= SDL_NOFRAME;
-width = w;
-height = h;
-
- again:
-screen = SDL_SetVideoMode(w, h, 0, flags);
-if (!screen) {
-fprintf(stderr, "Could not open SDL display\n");
-exit(1);
-}
-if (!screen->pixels && (flags & SDL_HWSURFACE) && (flags & SDL_FULLSCREEN)) {
-flags &= ~SDL_HWSURFACE;
-goto again;
+if (!(screen_tmp = SDL_SetVideoMode(w, h, 0, flags))) {
+//fprintf(stderr, "Could not open SDL display (try #1)\n");
+return -1;
+} else if (!screen_tmp->pixels && (flags & SDL_HWSURFACE) && (flags & SDL_FULLSCREEN)) {
+screen_tmp = SDL_SetVideoMode(w, h, 0, flags & ~SDL_HWSURFACE);
}
-if (!screen->pixels) {
-fprintf(stderr, "Could not open SDL display\n");
-exit(1);
-}
-ds->data = screen->pixels;
-ds->linesize = screen->pitch;
-ds->depth = screen->format->BitsPerPixel;
-if (screen->format->Bshift > screen->format->Rshift) {
-ds->bgr = 1;
+if (!screen_tmp || !screen_tmp->pixels) {
+//fprintf(stderr, "Could not open SDL display (try #2)\n");
+return -1;
} else {
-ds->bgr = 0;
+screen = screen_tmp;
+gui_fullscreen = full_screen;
+gui_noframe = no_frame;
+
+ds->data = screen->pixels;
+ds->linesize = screen->pitch;
+ds->depth = screen->format->BitsPerPixel;
+if (screen->format->Bshift > screen->format->Rshift) {
+ds->bgr = 1;
+} else {
+ds->bgr = 0;
+}
+ds->width = width = w;
+ds->height = height = h;
+}
+}
+
+static void sdl_resize(DisplayState *ds, int w, int h)
+{
+if (sdl_resize2(ds, w, h, gui_fullscreen, gui_noframe) == -1) {
+fprintf(stderr, "Could not resize display to %d x %d (%s)\n",
+ w, h, gui_fullscreen ? "fullscreen" : "windowed");
+
+/* if we are in fullscreen mode use windowed mode as fallback */
+if (!gui_fullscreen || sdl_resize2(ds, w, h, 0, gui_noframe) == -1) {
+exit(1);
+} else {
+fprintf(stderr, "Using windowed mode as fallback\n");
+}
}
-ds->width = w;
-ds->height = h;
}
/* generic keyboard conversion */
@@ -330,17 +344,21 @@ static void sdl_send_mouse_event(int dz)
static void toggle_full_screen(DisplayState *ds)
{
-gui_fullscreen = !gui_fullscreen;
-sdl_resize(ds, screen->w, screen->h);
-if (gui_fullscreen) {
-gui_saved_grab = gui_grab;
-sdl_grab_start();
-} else {
-if (!gui_saved_grab)
-sdl_grab_end();
+if (sdl_resize2(ds, screen->w, screen->h, !gui_fullscreen, gui_noframe) != -1) {
+if (gui_fullscreen) {
+gui_saved_grab = gui_grab;
+sdl_grab_start();
+} else {
+if (!gui_saved_grab)
+sdl_grab_end();
+}
+vga_hw_invalidate();
+vga_hw_update();
+}
+else {
+fprintf(stderr, "Could not switch to %s mode\n",
+ !gui_fullscreen ? "fullscreen" : "windowed");
}
-vga_hw_invalidate();
-vga_hw_update();
}
static void sdl_refresh(DisplayState *ds)
@@ -603,14 +621,14 @@ void sdl_display_init(DisplayState *ds,
exit(1);
}
-if (no_frame)
-
Re: [Qemu-devel] [PATCH] ide.c make write cacheing controllable by guest
Ian Jackson wrote: > > Ideally, the host would provide variation of fdatasync() which flushes > > data to hard storage in the same way that kernel filesystem journal > > writes can do, and Qemu would use that. > > Another question arises: do we want bdrv_flush to call (eventually) > fsync or fdatasync ? If the latter we need to make sure that we call > fsync instead when necessary, for example when a cow file is extended. I'm imagining that fdatasync() will flush the necessary metadata, including file size, when a file is extended. As would O_DSYNC. I could be wrong, but I think it's expected to do that, as I recall VxFS doing something like that with O_DSYNC. Then again, even if it's meant to, that doesn't mean it does... -- Jamie
Re: [Qemu-devel] [PATCH] SDL mouse events smoothness
Hi, On Tue, 26 Feb 2008, Samuel Thibault wrote: > I asked on the SDL mailing list, and they answered that qemu should > indeed not use SDL_GetRelativeMouseState(), since that only provides the > latest mouse position, not the position at the time of the event. AFAIR this is done so that your guest system does not spend ages processing mouse events from 10 minutes ago. This could happen easily if your guest is on high load. IOW I am not quite sure if I want the behaviour your patch provides, so if that patch should be taken, there should be at least an option to turn that behaviour off. Ciao, Dscho
Re: [Qemu-devel] [PATCH] SDL mouse events smoothness
Johannes Schindelin, le Tue 26 Feb 2008 12:57:25 +, a écrit : > On Tue, 26 Feb 2008, Samuel Thibault wrote: > > > I asked on the SDL mailing list, and they answered that qemu should > > indeed not use SDL_GetRelativeMouseState(), since that only provides the > > latest mouse position, not the position at the time of the event. > > AFAIR this is done so that your guest system does not spend ages > processing mouse events from 10 minutes ago. This could happen easily if > your guest is on high load. Mmm, but these events currently _are_ sent to the guest... Events could be coalesced indeed (and an option provided to choose whether to do it or not), but that's not currently the case. > IOW I am not quite sure if I want the behaviour your patch provides, so if > that patch should be taken, there should be at least an option to turn > that behaviour off. Well, at least compared to the current situation (a lot of undeeded events pushed to the guest), my patch is just an improvement, because at least these events are now useful. Samuel
[Qemu-devel] [PATCH] SDL mouse events smoothness
Hello,
I was having a look at the mouse events that the guest receives, and was
surprised to get
pos x:452 y:220 z:0
pos x:452 y:220 z:0
pos x:452 y:220 z:0
pos x:452 y:220 z:0
pos x:452 y:220 z:0
pos x:430 y:304 z:0
pos x:430 y:304 z:0
pos x:430 y:304 z:0
pos x:430 y:304 z:0
pos x:430 y:304 z:0
pos x:430 y:304 z:0
pos x:430 y:304 z:0
pos x:430 y:304 z:0
pos x:430 y:304 z:0
pos x:350 y:344 z:0
pos x:350 y:344 z:0
pos x:350 y:344 z:0
i.e. the guest receives the same position several times. This revealed
to be because sdl.c uses SDL_GetRelativeMouseState() instead of just
using the value from the event, and thus when several X11 events are
processed in one execution of sdl_refresh(), the intermediate positions
are not taken into account. I asked on the SDL mailing list, and they
answered that qemu should indeed not use SDL_GetRelativeMouseState(),
since that only provides the latest mouse position, not the position at
the time of the event. The patch below fixes this, and now I am getting
pos x:401 y:457 z:0
pos x:393 y:461 z:0
pos x:387 y:465 z:0
pos x:384 y:465 z:0
pos x:378 y:469 z:0
pos x:378 y:470 z:0
pos x:379 y:472 z:0
pos x:387 y:478 z:0
pos x:385 y:494 z:0
pos x:381 y:512 z:0
which provides a much more smooth feedback of the mouse cursor. It also
permits accessibility features such as mouse trail to work much better.
It also fixes some of the double-clic issues noticed when the machine is
sluggish (since it now always uses the button state at the time of the
event, not the current button state).
Samuel
Index: sdl.c
===
RCS file: /sources/qemu/qemu/sdl.c,v
retrieving revision 1.45
diff -u -p -r1.45 sdl.c
--- sdl.c 17 Nov 2007 17:14:38 - 1.45
+++ sdl.c 26 Feb 2008 12:24:33 -
@@ -276,8 +276,6 @@ static void sdl_grab_start(void)
} else
sdl_hide_cursor();
SDL_WM_GrabInput(SDL_GRAB_ON);
-/* dummy read to avoid moving the mouse */
-SDL_GetRelativeMouseState(NULL, NULL);
gui_grab = 1;
sdl_update_caption();
}
@@ -290,10 +288,9 @@ static void sdl_grab_end(void)
sdl_update_caption();
}
-static void sdl_send_mouse_event(int dz)
+static void sdl_send_mouse_event(int dx, int dy, int dz, int x, int y, int
state)
{
-int dx, dy, state, buttons;
-state = SDL_GetRelativeMouseState(&dx, &dy);
+int buttons;
buttons = 0;
if (state & SDL_BUTTON(SDL_BUTTON_LEFT))
buttons |= MOUSE_EVENT_LBUTTON;
@@ -311,18 +308,18 @@ static void sdl_send_mouse_event(int dz)
absolute_enabled = 1;
}
- SDL_GetMouseState(&dx, &dy);
- dx = dx * 0x7FFF / width;
- dy = dy * 0x7FFF / height;
+ dx = x * 0x7FFF / width;
+ dy = y * 0x7FFF / height;
} else if (absolute_enabled) {
sdl_show_cursor();
absolute_enabled = 0;
} else if (guest_cursor) {
-SDL_GetMouseState(&dx, &dy);
-dx -= guest_x;
-dy -= guest_y;
-guest_x += dx;
-guest_y += dy;
+x -= guest_x;
+y -= guest_y;
+guest_x += x;
+guest_y += y;
+dx = x;
+dy = y;
}
kbd_mouse_event(dx, dy, dz, buttons);
@@ -347,6 +344,7 @@ static void sdl_refresh(DisplayState *ds
{
SDL_Event ev1, *ev = &ev1;
int mod_state;
+int buttonstate = SDL_GetMouseState(NULL, NULL);
if (last_vm_running != vm_running) {
last_vm_running = vm
Re: [Qemu-devel] [PATCH] don't die if switching to fullscreen mode fails
Hi, On Tue, 26 Feb 2008, Andreas Winkelbauer wrote: > the attached patch fixes some glitches when switching to fullscreen mode > using ctrl+alt+f or when booting using -full-screen. Wow. This patch is messy, if I may say so. There must be a more elegant way to do this, especially given the fact that you remove atexit(sdl_cleanup)s without explanation. Ciao, Dscho
Re: [Qemu-devel] [PATCH] don't die if switching to fullscreen mode fails
Am 26.02.2008 um 13:48 schrieb Andreas Winkelbauer: This patch changes the behaviour as follows: * deny switching to fullscreen mode if the resolution is too high and print a message to the console Very good idea. * use windowed mode as fallback option if we are already in fullscreen mode and the new resolution is too high and print a message to the console Do you end up with a window bigger than the screen, then? Is there a chance the user can escape from this situation, i.e. reach all parts of the virtual screen to find the switch for setting the resolution? Another option would be to simply display an "Out of range error" across the screen, like a real monitor would do. Usually, operations systems feature a protection against setting a resolution higher than supported by hardware already (set back to a lower reolution after some delay). Markus - - - - - - - - - - - - - - - - - - - Dipl. Ing. Markus Hitter http://www.jump-ing.de/
[Qemu-devel] Keymap selection not working properly
Hi, I'm using Qemu 0.9.0 on Kubuntu, and I have issues with the keymap selection: * When KDE is configured with the French keyboard, then in Qemu, the keymap is English (qwerty) ; * When KDE is configured with the French keyboard, and Qemu is run with "-k fr", then the keymap remains in English (qwerty) in Qemu ; * When KDE is configured with the English keyboard, and Qemu is run with "-k fr", then the keymap in Qemu is French (azerty). So, something seems to be going wrong. Moreover, the documentation says that the -k option should not be needed on PC/Linux hosts. But I can see on a PC/Linux host that the qemu keymap is not the same as the system keymap. How can I fix that ? Thanks, Thomas -- Thomas Petazzoni, [EMAIL PROTECTED], http://thomas.enix.org Jabber, [EMAIL PROTECTED] Toulibre, http://www.toulibre.org - APRIL, http://www.april.org Fingerprint : 0BE1 4CF3 CEA4 AC9D CC6E 1624 F653 CB30 98D3 F7A7 signature.asc Description: PGP signature
Re: [Qemu-devel] Keymap selection not working properly
Thomas Petazzoni, le Tue 26 Feb 2008 14:51:21 +0100, a écrit : > I'm using Qemu 0.9.0 on Kubuntu, and I have issues with the keymap > selection: How is the guest configured? Samuel
Re: [Qemu-devel] [PATCH] linux-user, fix getgroups/getgroups32 when both args are zero.
On [Sat, 23.02.2008 09:25], Kirill A. Shutemov wrote:
> On [Sat, 23.02.2008 12:00], Takashi Yoshii wrote:
> > getgroups() and getgroups32() returns NGROUPS_MAX when both its two args are
> > zero. But because we pass a ptr to allocated space as 2nd arg, this function
> > are interfered. The patch attached fixed it.
> > /yoshii
> > ---
> > linux-user/syscall.c: fix getgroups{,32} when both args are zero.
> >
>
> My version of patch to fix same problem:
>
> getgroups: return total number of supplementary group IDs for the
> process if size == 0
>
> diff --git a/linux-user/syscall.c b/linux-user/syscall.c
> index ad97871..96a11a9 100644
> --- a/linux-user/syscall.c
> +++ b/linux-user/syscall.c
> @@ -5029,6 +5029,8 @@ abi_long do_syscall(void *cpu_env, int num, abi_long
> arg1,
>
> grouplist = alloca(gidsetsize * sizeof(gid_t));
> ret = get_errno(getgroups(gidsetsize, grouplist));
> +if (gidsetsize == 0)
> +break;
> if (!is_error(ret)) {
> target_grouplist = lock_user(VERIFY_WRITE, arg2, gidsetsize
> * 2, 0);
> if (!target_grouplist)
> @@ -5179,6 +5181,8 @@ abi_long do_syscall(void *cpu_env, int num, abi_long
> arg1,
>
> grouplist = alloca(gidsetsize * sizeof(gid_t));
> ret = get_errno(getgroups(gidsetsize, grouplist));
> +if (gidsetsize == 0)
> +break;
> if (!is_error(ret)) {
> target_grouplist = lock_user(VERIFY_WRITE, arg2, gidsetsize
> * 4, 0);
> if (!target_grouplist) {
>
> Another patch for getgroups:
>
> Trivial optimization of getgroups syscall implementation:
> swap only returned groups, not all group in list.
>
> diff --git a/linux-user/syscall.c b/linux-user/syscall.c
> index 6f2872f..ad97871 100644
> --- a/linux-user/syscall.c
> +++ b/linux-user/syscall.c
> @@ -5033,7 +5033,7 @@ abi_long do_syscall(void *cpu_env, int num, abi_long
> arg1,
> target_grouplist = lock_user(VERIFY_WRITE, arg2, gidsetsize
> * 2, 0);
> if (!target_grouplist)
> goto efault;
> -for(i = 0;i < gidsetsize; i++)
> +for(i = 0;i < ret; i++)
> target_grouplist[i] = tswap16(grouplist[i]);
> unlock_user(target_grouplist, arg2, gidsetsize * 2);
> }
> @@ -5185,7 +5185,7 @@ abi_long do_syscall(void *cpu_env, int num, abi_long
> arg1,
> ret = -TARGET_EFAULT;
> goto fail;
> }
> -for(i = 0;i < gidsetsize; i++)
> +for(i = 0;i < ret; i++)
> target_grouplist[i] = tswap32(grouplist[i]);
> unlock_user(target_grouplist, arg2, gidsetsize * 4);
> }
>
> It makes getgroups much faster in some cases.
Can anybody commit it?
--
Regards, Kirill A. Shutemov
+ Belarus, Minsk
+ Velesys Ltd, http://www.velesys.com/
+ ALT Linux Team, http://www.altlinux.com/
signature.asc
Description: Digital signature
Re: [Qemu-devel] [PATCH] ide.c make write cacheing controllable by guest
Jamie Lokier writes ("Re: [Qemu-devel] [PATCH] ide.c make write cacheing
controllable by guest"):
> I'm imagining that fdatasync() will flush the necessary metadata,
> including file size, when a file is extended. As would O_DSYNC.
Do you have a reference to support this supposition ? SuSv3's
specification for fdatasync is (astonishingly!) even vaguer and less
meaningful than that for fsync.
The closest I've come to finding answers are these:
HP-UX 11i's fdatasync manpage:
fdatasync() causes all modified data and file attributes of fildes
required to retrieve the data to be written to disk.
The glibc info manual:
Sometimes it is not even necessary to write all data associated with
a file descriptor. E.g., in database files which do not change in size
it is enough to write all the file content data to the device.
The Solaris manpage says that fdatasync does the same as O_DSYNC, and
it calls the service "synchronized I/O data integrity completion"
which is defined by the `Programming Interfaces Guide' to include
this:
* For writes, the operation has been completed, or diagnosed if
unsuccessful. The write operation succeeds when the data specified
in the write request is successfully transferred. Furthermore, all
file system information required to retrieve the data must be
successfully transferred.
But then the next bullet point is this:
* File attributes that are not necessary for data retrieval are not
transferred prior to returning to the calling process.
which says `are not transferred' when it ought to say `are not
necessarily transferred' so it may be unwise to rely on the precise
wording.
I looked at various other manpages but they all say useless things
like `metadata such as modification time' which leaves open the
question of whether the file size is included.
If the size is supposed to be included then the OS is required to keep
a flag to say whether the file has been extended so that it knows that
the next fdatasync ought really to be an fsync and write the inode
too. (In a traditional filesystem structure.) Or perhaps fsck needs
to extend the file as necessary to include the data blocks past the
nominal end of file.
This seems like rather a minefield.
Ian.
Re: [Qemu-devel] [PATCH] ide.c make write cacheing controllable by guest
Ian Jackson wrote:
> Jamie Lokier writes ("Re: [Qemu-devel] [PATCH] ide.c make write cacheing
> controllable by guest"):
> > I'm imagining that fdatasync() will flush the necessary metadata,
> > including file size, when a file is extended. As would O_DSYNC.
>
> Do you have a reference to support this supposition ?
Not a _standard_, of course, as you found with SuSv3. More a folk
understanding, which admittedly might be lacking in some
implementations (like Linux perhaps...).
Take a look at your references.
> HP-UX 11i's fdatasync manpage:
>
> fdatasync() causes all modified data and file attributes of fildes
^
> required to retrieve the data to be written to disk.
^
That means size, bitmap updates, block pointers, extents etc. needed
to retrieve the data.
> The glibc info manual:
>
> Sometimes it is not even necessary to write all data associated with
> a file descriptor. E.g., in database files which do not change in size
> it is enough to write all the file content data to the device.
A bit more from Glibc:
Meta-information, like the modification time etc., are not that
important and leaving such information uncommitted does not prevent a
successful recovering of the file in case of a problem.
When a call to the `fdatasync' function returns, it is ensured
that all of the file data is written to the device. For all
pending I/O operations, the parts guaranteeing data integrity
^
finished.
Draw your own conclusion.
> The Solaris manpage says that fdatasync does the same as O_DSYNC,
That's right, it's the common meaning of O_DSYNC.
> and it calls the service "synchronized I/O data integrity
> completion" which is defined by the `Programming Interfaces Guide'
> to include this:
>
> * For writes, the operation has been completed, or diagnosed if
>unsuccessful. The write operation succeeds when the data specified
>in the write request is successfully transferred. Furthermore, all
>file system information required to retrieve the data must be
^
>successfully transferred.
That's quite clear.
> But then the next bullet point is this:
>
> * File attributes that are not necessary for data retrieval are not
>transferred prior to returning to the calling process.
>
> which says `are not transferred' when it ought to say `are not
> necessarily transferred' so it may be unwise to rely on the precise
> wording.
That's fine and consistent with the previous text. It means size
increase, bitmaps, pointers, extents etc. are written (those are the
attributes necessary for data retrieval).
Attributes like modification time, access time, change time,
permissions etc. are not (necessarily) transferred. You're right it
should say "not necessarily", but that's implicit: they can be
transferred at any time anyway, by normal background writeback.
> I looked at various other manpages but they all say useless things
> like `metadata such as modification time' which leaves open the
> question of whether the file size is included.
I agree it's a bit ambiguous. My understanding is that _increases_ in
size are included, by convention as much as anything, since the larger
size is necessary to retrieve the data later.
This is supported by the fact that O_DSYNC has a tendancy to become
very slow on some systems when extending a file, compared with writing
in place.
> If the size is supposed to be included then the OS is required to keep
> a flag to say whether the file has been extended so that it knows that
> the next fdatasync ought really to be an fsync and write the inode
> too. (In a traditional filesystem structure.)
That's right.
> Or perhaps fsck needs
> to extend the file as necessary to include the data blocks past the
> nominal end of file.
Well, in general, if your system is such that fsck following a crash
is part of normal filesystem operations, then fsck could be allowed to
do a lot more than extend the size attribute.
That doesn't matter to the application, though. What matters is that
it writes data (including extending the file), calls fdatasync() (or
uses O_DSYNC), and when the fdatasync returns it knows after a crash
and recovery that it will be able to retrieve that data with the
appropriate confidence level.
> This seems like rather a minefield.
The implementation details seem like a minefield, but the intent and
documentation and tradition of fdatasync() seems quite clear to me.
However, I suppose you might want to be careful and check, when
deploying your new database which depends on fdatasync(), if the
target systems really do sync size changes :-)
It's easy enough to check, as it greatly slows down extending writes.
But I suppose, for
[Qemu-devel] [PATCH] MIPS_R4K: add optionnal 4MB cfi flash and allow to boot from it
Signed-off-by: Jean-Christophe PLAGNIOL-VILLARD <[EMAIL PROTECTED]>
diff --git a/hw/mips_r4k.c b/hw/mips_r4k.c
index 63bd158..fca5651 100644
--- a/hw/mips_r4k.c
+++ b/hw/mips_r4k.c
@@ -14,6 +14,7 @@
#include "net.h"
#include "sysemu.h"
#include "boards.h"
+#include "flash.h"
#ifdef TARGET_WORDS_BIGENDIAN
#define BIOS_FILENAME "mips_bios.bin"
@@ -144,6 +145,7 @@ static void main_cpu_reset(void *opaque)
load_kernel (env);
}
+static const int sector_len = 32 * 1024;
static
void mips_r4k_init (int ram_size, int vga_ram_size,
const char *boot_device, DisplayState *ds,
@@ -197,7 +199,17 @@ void mips_r4k_init (int ram_size, int vga_ram_size,
if ((bios_size > 0) && (bios_size <= BIOS_SIZE)) {
cpu_register_physical_memory(0x1fc0,
BIOS_SIZE, bios_offset | IO_MEM_ROM);
-} else {
+} else if ((index = drive_get_index(IF_PFLASH, 0, 0)) > -1) {
+uint32_t mips_rom = 0x0040;
+cpu_register_physical_memory(0x1fc0, mips_rom,
+qemu_ram_alloc(mips_rom) | IO_MEM_ROM);
+if (!pflash_cfi01_register(0x1fc0, qemu_ram_alloc(mips_rom),
+drives_table[index].bdrv, sector_len, mips_rom / sector_len,
+4, 0, 0, 0, 0)) {
+fprintf(stderr, "qemu: Error registering flash memory.\n");
+ }
+}
+else {
/* not fatal */
fprintf(stderr, "qemu: Warning, could not load MIPS bios '%s'\n",
buf);
--
1.5.4
Re: [Qemu-devel] [PATCH] ide.c make write cacheing controllable by guest
Jamie Lokier writes ("Re: [Qemu-devel] [PATCH] ide.c make write cacheing
controllable by guest"):
> I agree it's a bit ambiguous. My understanding is that _increases_ in
> size are included, by convention as much as anything, since the larger
> size is necessary to retrieve the data later.
Yes. Well, if you're sufficiently convinced then I think the right
thing for you to do is to submit a patch to change the calls to fsync
to calls to fdatasync.
Sadly my patches don't seem to have been applied in CVS yet. I'll
arrange to publish my git tree and then you can make a diff that will
sit properly on top of my tree (which is what you want because I have
added error checking, so otherwise we get a conflict).
Ian.
Re: [Qemu-devel] Re: qemu unchecked block read/write vulnerability
On Tue, Feb 19, 2008 at 04:39:07PM +, Ian Jackson wrote: Content-Description: message body text > I was doing some merging of qemu and I noticed that the block driver > backends don't check the guest's read/write attempts against the > nominal size of the block device. > > I haven't checked all of the backends but I have verified the bug with > block-cow.c, which I have in my test induced to set a bitmap bit at an > address which is not actually part of the bitmap. In my tests I used > as my guest a Linux kernel which I'd specially modifed to allow me to > access out-of-range blocks. > > I think the fix is probably to insert a couple of range checks in the > generic block dispatch layer and I attach a patch to achieve this. FYI, this patch appears to cause massive unrecoverable data corruption for qcow2 format disks. It looks like the sector range check is being applied to the total sector count of the actual qcow datafile on disk, rather than the total sector count of the logical disk. I suspect the same may occur with other non-raw disk formats, so be wary Dan. -- |=- Red Hat, Engineering, Emerging Technologies, Boston. +1 978 392 2496 -=| |=- Perl modules: http://search.cpan.org/~danberr/ -=| |=- Projects: http://freshmeat.net/~danielpb/ -=| |=- GnuPG: 7D3B9505 F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 -=|
[Qemu-devel] TCG on i386 can't generate qemu_st64 for 32-bit target
Hi,
There is a problem with the Sparc32 target on i386 host. Store double
word op (std) cannot be generated and TCG just aborts. It looks like
the registers are so few on i386 that TCG can't find registers for the
qemu_st64 call. The problem does not appear on x86_64 host, or for
Sparc64 target (stx/ldx) on i386, or with 64-bit load (ldd) on Sparc32
target.
The attached patch would work around the problem, but I agree that
it's ugly and it would bring back one instance of T2 use. I also tried
preallocating a 64-bit register but that didn't help.
I suppose instead the following piece (tcg/i386/tcg-target.c:737)
could be modified to lower the pressure for registers but I'm not that
familiar with x86 assembly.
#if TARGET_LONG_BITS == 32
if (opc == 3) {
tcg_out_mov(s, TCG_REG_EDX, data_reg);
tcg_out_mov(s, TCG_REG_ECX, data_reg2);
tcg_out8(s, 0x6a); /* push Ib */
tcg_out8(s, mem_index);
tcg_out8(s, 0xe8);
tcg_out32(s, (tcg_target_long)qemu_st_helpers[s_bits] -
(tcg_target_long)s->code_ptr - 4);
tcg_out_addi(s, TCG_REG_ESP, 4);
} else {
Index: qemu/target-sparc/translate.c
===
--- qemu.orig/target-sparc/translate.c 2008-02-26 19:48:38.0 +
+++ qemu/target-sparc/translate.c 2008-02-26 19:48:38.0 +
@@ -192,6 +192,9 @@
#endif
#ifndef CONFIG_USER_ONLY
+#ifdef __i386__
+OP_LD_TABLE(std);
+#endif /* __i386__ */
OP_LD_TABLE(stf);
OP_LD_TABLE(stdf);
OP_LD_TABLE(ldf);
@@ -231,6 +234,13 @@
gen_movl_reg_TN(reg, cpu_T[1]);
}
+#ifdef __i386__
+static inline void gen_movl_reg_T2(int reg)
+{
+gen_movl_reg_TN(reg, cpu_T[2]);
+}
+
+#endif /* __i386__ */
static inline void gen_movl_TN_reg(int reg, TCGv tn)
{
if (reg == 0)
@@ -3275,6 +3285,7 @@
case 0x7: /* store double word */
if (rd & 1)
goto illegal_insn;
+#ifndef __i386__
else {
TCGv r_dword, r_low;
@@ -3286,6 +3297,12 @@
r_low);
tcg_gen_qemu_st64(r_dword, cpu_T[0], dc->mem_idx);
}
+#else /* __i386__ */
+gen_op_check_align_T0_7();
+flush_T2(dc);
+gen_movl_reg_T2(rd + 1);
+gen_op_ldst(std);
+#endif /* __i386__ */
break;
#if !defined(CONFIG_USER_ONLY) || defined(TARGET_SPARC64)
case 0x14: /* store word alternate */
Index: qemu/target-sparc/op_mem.h
===
--- qemu.orig/target-sparc/op_mem.h 2008-02-26 19:48:38.0 +
+++ qemu/target-sparc/op_mem.h 2008-02-26 19:48:38.0 +
@@ -4,6 +4,16 @@
#define ADDR(x) (x)
#endif
+#ifdef __i386__
+/*** Integer store***/
+void OPPROTO glue(op_std, MEMSUFFIX)(void)
+{
+uint64_t tmp = ((uint64_t)T1 << 32) | (uint64_t)(T2 & 0x);
+
+glue(stq, MEMSUFFIX)(ADDR(T0), tmp);
+}
+
+#endif /* __i386__ */
/*** Floating-point store ***/
void OPPROTO glue(op_stf, MEMSUFFIX) (void)
{
[Qemu-devel] [PATCH 1/15] Make a GPE register block be acessible.
gpe is acessible when its address listed by BIOS is !0. This patch makes gpe blk 0 available, and 4 bytes in length Signed-off-by: Glauber Costa <[EMAIL PROTECTED]> --- bios/rombios32.c |2 ++ 1 files changed, 2 insertions(+), 0 deletions(-) diff --git a/bios/rombios32.c b/bios/rombios32.c index 5365b5f..3ec85cb 100755 --- a/bios/rombios32.c +++ b/bios/rombios32.c @@ -1441,6 +1441,8 @@ #endif fadt->pm_tmr_len = 4; fadt->plvl2_lat = cpu_to_le16(0x0fff); // C2 state not supported fadt->plvl3_lat = cpu_to_le16(0x0fff); // C3 state not supported +fadt->gpe0_blk = cpu_to_le32(0xafe0); +fadt->gpe0_blk_len = 4; /* WBINVD + PROC_C1 + SLP_BUTTON + FIX_RTC */ fadt->flags = cpu_to_le32((1 << 0) | (1 << 2) | (1 << 5) | (1 << 6)); acpi_build_table_header((struct acpi_table_header *)fadt, "FACP", -- 1.4.2
[Qemu-devel] [PATCH 2/15] mark extra cpus as present
Mark cpus over smp_cpus as present, but disable.
The OS can then recognize it and make room for future hotplug
Signed-off-by: Glauber Costa <[EMAIL PROTECTED]>
---
bios/rombios.h |2 ++
bios/rombios32.c | 21 +
2 files changed, 15 insertions(+), 8 deletions(-)
diff --git a/bios/rombios.h b/bios/rombios.h
index 412c5e9..2cf2bb3 100644
--- a/bios/rombios.h
+++ b/bios/rombios.h
@@ -58,6 +58,8 @@ #define PM_IO_BASE0xb000
#define SMB_IO_BASE 0xb100
#define CPU_COUNT_ADDR0xf000
+#define MAX_CPUS 16
+
// Define the application NAME
#if defined(BX_QEMU)
# define BX_APPNAME "QEMU"
diff --git a/bios/rombios32.c b/bios/rombios32.c
index 3ec85cb..f2db740 100755
--- a/bios/rombios32.c
+++ b/bios/rombios32.c
@@ -948,20 +948,22 @@ #endif
putstr(&q, "0.1 "); /* vendor id */
putle32(&q, 0); /* OEM table ptr */
putle16(&q, 0); /* OEM table size */
-putle16(&q, smp_cpus + 18); /* entry count */
+putle16(&q, MAX_CPUS + 18); /* entry count */
putle32(&q, 0xfee0); /* local APIC addr */
putle16(&q, 0); /* ext table length */
putb(&q, 0); /* ext table checksum */
putb(&q, 0); /* reserved */
-for(i = 0; i < smp_cpus; i++) {
+for(i = 0; i < MAX_CPUS ; i++) {
putb(&q, 0); /* entry type = processor */
putb(&q, i); /* APIC id */
putb(&q, 0x11); /* local APIC version number */
if (i == 0)
putb(&q, 3); /* cpu flags: enabled, bootstrap cpu */
-else
+else if ( i < smp_cpus)
putb(&q, 1); /* cpu flags: enabled */
+else
+putb(&q, 0); /* cpu flags: disabled */
putb(&q, 0); /* cpu signature */
putb(&q, 6);
putb(&q, 0);
@@ -981,7 +983,7 @@ #endif
putstr(&q, "ISA ");
/* ioapic */
-ioapic_id = smp_cpus;
+ioapic_id = MAX_CPUS;
putb(&q, 2); /* entry type = I/O APIC */
putb(&q, ioapic_id); /* apic ID */
putb(&q, 0x11); /* I/O APIC version number */
@@ -1393,7 +1395,7 @@ #endif
addr = (addr + 7) & ~7;
madt_addr = addr;
madt_size = sizeof(*madt) +
-sizeof(struct madt_processor_apic) * smp_cpus +
+sizeof(struct madt_processor_apic) * MAX_CPUS +
sizeof(struct madt_io_apic);
madt = (void *)(addr);
addr += madt_size;
@@ -1466,18 +1468,21 @@ #endif
madt->local_apic_address = cpu_to_le32(0xfee0);
madt->flags = cpu_to_le32(1);
apic = (void *)(madt + 1);
-for(i=0;itype = APIC_PROCESSOR;
apic->length = sizeof(*apic);
apic->processor_id = i;
apic->local_apic_id = i;
-apic->flags = cpu_to_le32(1);
+if (i < smp_cpus)
+apic->flags = cpu_to_le32(1);
+else
+apic->flags = 0;
apic++;
}
io_apic = (void *)apic;
io_apic->type = APIC_IO;
io_apic->length = sizeof(*io_apic);
-io_apic->io_apic_id = smp_cpus;
+io_apic->io_apic_id = MAX_CPUS;
io_apic->address = cpu_to_le32(0xfec0);
io_apic->interrupt = cpu_to_le32(0);
--
1.4.2
[Qemu-devel] [PATCH 4/15] mark processors as presents
mark processors as present through the _STA method
Signed-off-by: Glauber Costa <[EMAIL PROTECTED]>
---
bios/acpi-dsdt.dsl | 18 ++
1 files changed, 18 insertions(+), 0 deletions(-)
diff --git a/bios/acpi-dsdt.dsl b/bios/acpi-dsdt.dsl
index e900795..244e906 100755
--- a/bios/acpi-dsdt.dsl
+++ b/bios/acpi-dsdt.dsl
@@ -25,6 +25,24 @@ DefinitionBlock (
0x1 // OEM Revision
)
{
+ Scope (\_PR)
+ {
+Processor (CPU0, 0x00, 0xb010, 0x06) {Method (_STA) { Return(0xF)}}
+Processor (CPU1, 0x01, 0xb010, 0x06) {Method (_STA) { Return(0xF)}}
+Processor (CPU2, 0x02, 0xb010, 0x06) {Method (_STA) { Return(0xF)}}
+Processor (CPU3, 0x03, 0xb010, 0x06) {Method (_STA) { Return(0xF)}}
+Processor (CPU4, 0x04, 0xb010, 0x06) {Method (_STA) { Return(0xF)}}
+Processor (CPU5, 0x05, 0xb010, 0x06) {Method (_STA) { Return(0xF)}}
+Processor (CPU6, 0x06, 0xb010, 0x06) {Method (_STA) { Return(0xF)}}
+Processor (CPU7, 0x07, 0xb010, 0x06) {Method (_STA) { Return(0xF)}}
+Processor (CPU8, 0x08, 0xb010, 0x06) {Method (_STA) { Return(0xF)}}
+Processor (CPU9, 0x09, 0xb010, 0x06) {Method (_STA) { Return(0xF)}}
+Processor (CPUA, 0x0a, 0xb010, 0x06) {Method (_STA) { Return(0xF)}}
+Processor (CPUB, 0x0b, 0xb010, 0x06) {Method (_STA) { Return(0xF)}}
+Processor (CPUC, 0x0c, 0xb010, 0x06) {Method (_STA) { Return(0xF)}}
+Processor (CPUD, 0x0d, 0xb010, 0x06) {Method (_STA) { Return(0xF)}}
+Processor (CPUE, 0x0e, 0xb010, 0x06) {Method (_STA) { Return(0xF)}}
+}
Scope (\)
{
--
1.4.2
[Qemu-devel] [PATCH 0/15] acpi processor hotplug
Hi, I'm resending the series with avi's few comments merged, and a couple of others on my own: * _STA returns 0xF instead of 0x1. According to the specification, it means that the device, besides present, is also functional, enabled, and a couple of other cool things. * gpe_base and proc_base as #defines, not unsigned long * _EJ method out. It's causing a lot of troubles, and I'm not even sure it makes sense for processors. We can live without it by now, and if it is needed, it can be added later. Have a safe trip back home,
[Qemu-devel] [PATCH 3/15] introduce cpu_set to qemu monitor
in this patch, cpu_set is introduced to qemu monitor
semantics is : cpu_set x online|offline.
it will then tell the acpi backend to signal cpu x.
Signed-off-by: Glauber Costa <[EMAIL PROTECTED]>
---
qemu/hw/acpi.c |4
qemu/monitor.c | 16
qemu/sysemu.h |3 +++
3 files changed, 23 insertions(+), 0 deletions(-)
diff --git a/qemu/hw/acpi.c b/qemu/hw/acpi.c
index e21ded0..d2e2e3e 100644
--- a/qemu/hw/acpi.c
+++ b/qemu/hw/acpi.c
@@ -533,3 +533,7 @@ void qemu_system_powerdown(void)
}
}
#endif
+
+void qemu_system_cpu_hot_add(int cpu, int state)
+{
+}
diff --git a/qemu/monitor.c b/qemu/monitor.c
index e8022c8..09f84a9 100644
--- a/qemu/monitor.c
+++ b/qemu/monitor.c
@@ -345,6 +345,21 @@ static void do_cpu_set(int index)
term_printf("Invalid CPU index\n");
}
+static void do_cpu_set_nr(int value, const char *status)
+{
+int state;
+
+if (!strcmp(status, "online"))
+ state = 1;
+else if (!strcmp(status, "offline"))
+ state = 0;
+else {
+ term_printf("invalid status: %s\n", status);
+ return;
+}
+qemu_system_cpu_hot_add(value, state);
+}
+
static void do_info_jit(void)
{
dump_exec_info(NULL, monitor_fprintf);
@@ -1338,6 +1353,7 @@ #endif
"", "cancel the current VM migration" },
{ "migrate_set_speed", "s", do_migrate_set_speed,
"value", "set maximum speed (in bytes) for migrations" },
+{ "cpu_set", "is", do_cpu_set_nr, "cpu [online|offline]", "change cpu
state" },
{ NULL, NULL, },
};
diff --git a/qemu/sysemu.h b/qemu/sysemu.h
index ffc468a..fe929b4 100644
--- a/qemu/sysemu.h
+++ b/qemu/sysemu.h
@@ -153,6 +153,9 @@ int extboot_drive;
extern int drive_get_index(BlockInterfaceType type, int bus, int unit);
extern int drive_get_max_bus(BlockInterfaceType type);
+/* acpi */
+void qemu_system_cpu_hot_add(int cpu, int state);
+
/* vmchannel devices */
#define MAX_VMCHANNEL_DEVICES 4
--
1.4.2
[Qemu-devel] [PATCH 5/15] provide gpe _L0x methods
provide methods for gpe blk 0, even though they do nothing atm
Signed-off-by: Glauber Costa <[EMAIL PROTECTED]>
---
bios/acpi-dsdt.dsl | 51 +++
1 files changed, 51 insertions(+), 0 deletions(-)
diff --git a/bios/acpi-dsdt.dsl b/bios/acpi-dsdt.dsl
index 244e906..392d402 100755
--- a/bios/acpi-dsdt.dsl
+++ b/bios/acpi-dsdt.dsl
@@ -578,4 +578,55 @@ DefinitionBlock (
0x00, // reserved
0x00, // reserved
})
+Scope (\_GPE)
+{
+Method(_L00) {
+Return(0x01)
+}
+Method(_L01) {
+Return(0x01)
+}
+Method(_L02) {
+Return(0x01)
+}
+Method(_L03) {
+Return(0x01)
+}
+Method(_L04) {
+Return(0x01)
+}
+Method(_L05) {
+Return(0x01)
+}
+Method(_L06) {
+Return(0x01)
+}
+Method(_L07) {
+Return(0x01)
+}
+Method(_L08) {
+Return(0x01)
+}
+Method(_L09) {
+Return(0x01)
+}
+Method(_L0A) {
+Return(0x01)
+}
+Method(_L0B) {
+Return(0x01)
+}
+Method(_L0C) {
+Return(0x01)
+}
+Method(_L0D) {
+Return(0x01)
+}
+Method(_L0E) {
+Return(0x01)
+}
+Method(_L0F) {
+Return(0x01)
+}
+}
}
--
1.4.2
[Qemu-devel] [PATCH 8/15] isolate cpu initialization function in hw/pc.c
This patch wraps up the piece of code in hw/pc.c that
actually allocates and initializates a cpu. After that,
plan is to be able to start it later on.
Signed-off-by: Glauber Costa <[EMAIL PROTECTED]>
---
qemu/hw/pc.c | 40 +++-
qemu/hw/pc.h |1 +
2 files changed, 24 insertions(+), 17 deletions(-)
diff --git a/qemu/hw/pc.c b/qemu/hw/pc.c
index 77a7d53..982377d 100644
--- a/qemu/hw/pc.c
+++ b/qemu/hw/pc.c
@@ -740,6 +740,28 @@ static int load_option_rom(const char *f
return size;
}
+CPUState *pc_new_cpu(int cpu, const char *cpu_model, int pci_enabled)
+{
+CPUState *env = cpu_init(cpu_model);
+if (!env) {
+fprintf(stderr, "Unable to find x86 CPU definition\n");
+exit(1);
+}
+if (cpu != 0)
+env->hflags |= HF_HALTED_MASK;
+if (smp_cpus > 1) {
+/* XXX: enable it in all cases */
+env->cpuid_features |= CPUID_APIC;
+}
+register_savevm("cpu", cpu, 4, cpu_save, cpu_load, env);
+qemu_register_reset(main_cpu_reset, env);
+if (pci_enabled) {
+apic_init(env);
+}
+vmport_init(env);
+ return env;
+}
+
/* PC hardware initialisation */
static void pc_init1(ram_addr_t ram_size, int vga_ram_size,
const char *boot_device, DisplayState *ds,
@@ -779,23 +801,7 @@ #endif
}
for(i = 0; i < smp_cpus; i++) {
-env = cpu_init(cpu_model);
-if (!env) {
-fprintf(stderr, "Unable to find x86 CPU definition\n");
-exit(1);
-}
-if (i != 0)
-env->hflags |= HF_HALTED_MASK;
-if (smp_cpus > 1) {
-/* XXX: enable it in all cases */
-env->cpuid_features |= CPUID_APIC;
-}
-register_savevm("cpu", i, 4, cpu_save, cpu_load, env);
-qemu_register_reset(main_cpu_reset, env);
-if (pci_enabled) {
-apic_init(env);
-}
-vmport_init(env);
+ env = pc_new_cpu(i, cpu_model, pci_enabled);
}
/* allocate RAM */
diff --git a/qemu/hw/pc.h b/qemu/hw/pc.h
index f640395..f70ab55 100644
--- a/qemu/hw/pc.h
+++ b/qemu/hw/pc.h
@@ -85,6 +85,7 @@ extern int fd_bootchk;
void ioport_set_a20(int enable);
int ioport_get_a20(void);
+CPUState *pc_new_cpu(int cpu, const char *cpu_model, int pci_enabled);
/* acpi.c */
extern int acpi_enabled;
--
1.4.2
[Qemu-devel] [PATCH 6/15] provide operation region for pio to the gpes
Signed-off-by: Glauber Costa <[EMAIL PROTECTED]>
---
bios/acpi-dsdt.dsl |7 +++
1 files changed, 7 insertions(+), 0 deletions(-)
diff --git a/bios/acpi-dsdt.dsl b/bios/acpi-dsdt.dsl
index 392d402..1dba157 100755
--- a/bios/acpi-dsdt.dsl
+++ b/bios/acpi-dsdt.dsl
@@ -27,6 +27,13 @@ DefinitionBlock (
{
Scope (\_PR)
{
+ OperationRegion( PRST, SystemIO, 0xaf00, 0x02)
+ Field (PRST, ByteAcc, NoLock, WriteAsZeros)
+ {
+ PRU, 8,
+ PRD, 8,
+ }
+
Processor (CPU0, 0x00, 0xb010, 0x06) {Method (_STA) { Return(0xF)}}
Processor (CPU1, 0x01, 0xb010, 0x06) {Method (_STA) { Return(0xF)}}
Processor (CPU2, 0x02, 0xb010, 0x06) {Method (_STA) { Return(0xF)}}
--
1.4.2
[Qemu-devel] [PATCH 7/15] implement method _L00 for GPE0
This corresponds to the cpu hotplug functionality
Signed-off-by: Glauber Costa <[EMAIL PROTECTED]>
---
bios/acpi-dsdt.dsl | 114
1 files changed, 114 insertions(+), 0 deletions(-)
diff --git a/bios/acpi-dsdt.dsl b/bios/acpi-dsdt.dsl
index 1dba157..194a051 100755
--- a/bios/acpi-dsdt.dsl
+++ b/bios/acpi-dsdt.dsl
@@ -588,6 +588,120 @@ DefinitionBlock (
Scope (\_GPE)
{
Method(_L00) {
+/* Up status */
+If (And(\_PR.PRU, 0x2)) {
+Notify(\_PR.CPU1,1)
+}
+
+If (And(\_PR.PRU, 0x4)) {
+Notify(\_PR.CPU2,1)
+}
+
+If (And(\_PR.PRU, 0x8)) {
+Notify(\_PR.CPU3,1)
+}
+
+If (And(\_PR.PRU, 0x10)) {
+Notify(\_PR.CPU4,1)
+}
+
+If (And(\_PR.PRU, 0x20)) {
+Notify(\_PR.CPU5,1)
+}
+
+If (And(\_PR.PRU, 0x40)) {
+Notify(\_PR.CPU6,1)
+}
+
+If (And(\_PR.PRU, 0x80)) {
+Notify(\_PR.CPU7,1)
+}
+
+If (And(\_PR.PRU, 0x100)) {
+Notify(\_PR.CPU8,1)
+}
+
+If (And(\_PR.PRU, 0x200)) {
+Notify(\_PR.CPU9,1)
+}
+
+If (And(\_PR.PRU, 0x400)) {
+Notify(\_PR.CPUA,1)
+}
+
+If (And(\_PR.PRU, 0x800)) {
+Notify(\_PR.CPUB,1)
+}
+
+If (And(\_PR.PRU, 0x1000)) {
+Notify(\_PR.CPUC,1)
+}
+
+If (And(\_PR.PRU, 0x2000)) {
+Notify(\_PR.CPUD,1)
+}
+
+If (And(\_PR.PRU, 0x4000)) {
+Notify(\_PR.CPUE,1)
+}
+
+/* Down status */
+If (And(\_PR.PRD, 0x2)) {
+Notify(\_PR.CPU1,3)
+}
+
+If (And(\_PR.PRD, 0x4)) {
+Notify(\_PR.CPU2,3)
+}
+
+If (And(\_PR.PRD, 0x8)) {
+Notify(\_PR.CPU3,3)
+}
+
+If (And(\_PR.PRD, 0x10)) {
+Notify(\_PR.CPU4,3)
+}
+
+If (And(\_PR.PRD, 0x20)) {
+Notify(\_PR.CPU5,3)
+}
+
+If (And(\_PR.PRD, 0x40)) {
+Notify(\_PR.CPU6,3)
+}
+
+If (And(\_PR.PRD, 0x80)) {
+Notify(\_PR.CPU7,3)
+}
+
+If (And(\_PR.PRD, 0x100)) {
+Notify(\_PR.CPU8,3)
+}
+
+If (And(\_PR.PRD, 0x200)) {
+Notify(\_PR.CPU9,3)
+}
+
+If (And(\_PR.PRD, 0x400)) {
+Notify(\_PR.CPUA,3)
+}
+
+If (And(\_PR.PRD, 0x800)) {
+Notify(\_PR.CPUB,3)
+}
+
+If (And(\_PR.PRD, 0x1000)) {
+Notify(\_PR.CPUC,3)
+}
+
+If (And(\_PR.PRD, 0x2000)) {
+Notify(\_PR.CPUD,3)
+}
+
+If (And(\_PR.PRD, 0x4000)) {
+Notify(\_PR.CPUE,3)
+}
+
Return(0x01)
}
Method(_L01) {
--
1.4.2
[Qemu-devel] [PATCH 9/15] initialize hot add system.
Register the pios, and grab cpu_model for future usage.
Signed-off-by: Glauber Costa <[EMAIL PROTECTED]>
---
qemu/hw/acpi.c | 34 ++
qemu/hw/pc.c |1 +
qemu/sysemu.h |1 +
3 files changed, 36 insertions(+), 0 deletions(-)
diff --git a/qemu/hw/acpi.c b/qemu/hw/acpi.c
index d2e2e3e..119b59a 100644
--- a/qemu/hw/acpi.c
+++ b/qemu/hw/acpi.c
@@ -533,6 +533,40 @@ void qemu_system_powerdown(void)
}
}
#endif
+#define GPE_BASE 0xafe0
+
+struct gpe_regs {
+uint16_t sts; /* status */
+uint16_t en; /* enabled */
+};
+
+static struct gpe_regs gpe;
+
+static uint32_t gpe_readb(void *opaque, uint32_t addr)
+{
+uint32_t val = 0;
+#if defined(DEBUG)
+printf("gpe read %lx == %lx\n", addr, val);
+#endif
+return val;
+}
+
+static void gpe_writeb(void *opaque, uint32_t addr, uint32_t val)
+{
+#if defined(DEBUG)
+printf("gpe write %lx <== %d\n", addr, val);
+#endif
+}
+
+static char *model;
+
+void qemu_system_hot_add_init(char *cpu_model)
+{
+register_ioport_write(GPE_BASE, 4, 1, gpe_writeb, &gpe);
+register_ioport_read(GPE_BASE, 4, 1, gpe_readb, &gpe);
+
+model = cpu_model;
+}
void qemu_system_cpu_hot_add(int cpu, int state)
{
diff --git a/qemu/hw/pc.c b/qemu/hw/pc.c
index 982377d..ab69e5c 100644
--- a/qemu/hw/pc.c
+++ b/qemu/hw/pc.c
@@ -1020,6 +1020,7 @@ #endif
}
}
+qemu_system_hot_add_init(cpu_model);
#define USE_HYPERCALL
#ifdef USE_HYPERCALL
pci_hypercall_init(pci_bus);
diff --git a/qemu/sysemu.h b/qemu/sysemu.h
index fe929b4..5692114 100644
--- a/qemu/sysemu.h
+++ b/qemu/sysemu.h
@@ -155,6 +155,7 @@ extern int drive_get_max_bus(BlockInterf
/* acpi */
void qemu_system_cpu_hot_add(int cpu, int state);
+void qemu_system_hot_add_init(char *cpu_model);
/* vmchannel devices */
--
1.4.2
[Qemu-devel] [PATCH 11/15] manipulate the gpe bits and send sci up the os.
Signed-off-by: Glauber Costa <[EMAIL PROTECTED]>
---
qemu/hw/acpi.c | 42 ++
1 files changed, 42 insertions(+), 0 deletions(-)
diff --git a/qemu/hw/acpi.c b/qemu/hw/acpi.c
index 7340f15..5a6d1a8 100644
--- a/qemu/hw/acpi.c
+++ b/qemu/hw/acpi.c
@@ -534,10 +534,13 @@ void qemu_system_powerdown(void)
}
#endif
#define GPE_BASE 0xafe0
+#define PROC_BASE 0xaf00
struct gpe_regs {
uint16_t sts; /* status */
uint16_t en; /* enabled */
+uint8_t up;
+uint8_t down;
};
static struct gpe_regs gpe;
@@ -547,6 +550,13 @@ static uint32_t gpe_readb(void *opaque,
uint32_t val = 0;
struct gpe_regs *g = opaque;
switch (addr) {
+case PROC_BASE:
+val = g->up;
+break;
+case PROC_BASE + 1:
+val = g->down;
+break;
+
case GPE_BASE:
val = g->sts & 0xFF;
break;
@@ -573,6 +583,13 @@ static void gpe_writeb(void *opaque, uin
{
struct gpe_regs *g = opaque;
switch (addr) {
+case PROC_BASE:
+g->up = val;
+break;
+case PROC_BASE + 1:
+g->down = val;
+break;
+
case GPE_BASE:
g->sts = (g->sts & ~0x) | (val & 0x);
break;
@@ -601,9 +618,34 @@ void qemu_system_hot_add_init(char *cpu_
register_ioport_write(GPE_BASE, 4, 1, gpe_writeb, &gpe);
register_ioport_read(GPE_BASE, 4, 1, gpe_readb, &gpe);
+register_ioport_write(PROC_BASE, 4, 1, gpe_writeb, &gpe);
+register_ioport_read(PROC_BASE, 4, 1, gpe_readb, &gpe);
+
model = cpu_model;
}
+static void enable_processor(struct gpe_regs *g, int cpu)
+{
+g->sts |= 1;
+g->en |= 1;
+g->up |= (1 << cpu);
+}
+
+static void disable_processor(struct gpe_regs *g, int cpu)
+{
+g->sts |= 1;
+g->en |= 1;
+g->down |= (1 << cpu);
+}
+
void qemu_system_cpu_hot_add(int cpu, int state)
{
+qemu_set_irq(pm_state->irq, 1);
+gpe.up = 0;
+gpe.down = 0;
+if (state)
+enable_processor(&gpe, cpu);
+else
+disable_processor(&gpe, cpu);
+qemu_set_irq(pm_state->irq, 0);
}
--
1.4.2
[Qemu-devel] [PATCH 12/15] isolate cpu thread creation in qemu-kvm.c
Signed-off-by: Glauber Costa <[EMAIL PROTECTED]>
---
qemu/qemu-kvm.c |9 +++--
qemu/qemu-kvm.h |1 +
2 files changed, 8 insertions(+), 2 deletions(-)
diff --git a/qemu/qemu-kvm.c b/qemu/qemu-kvm.c
index ffc59d5..59fe9df 100644
--- a/qemu/qemu-kvm.c
+++ b/qemu/qemu-kvm.c
@@ -351,6 +351,11 @@ static void kvm_add_signal(struct qemu_k
sigdelset(&sigtab->negsigset, signum);
}
+void kvm_init_new_ap(int cpu, CPUState *env)
+{
+pthread_create(&vcpu_info[cpu].thread, NULL, ap_main_loop, env);
+}
+
int kvm_init_ap(void)
{
CPUState *env = first_cpu->next_cpu;
@@ -371,8 +376,8 @@ #endif
vcpu->env = first_cpu;
signal(SIG_IPI, sig_ipi_handler);
for (i = 1; i < smp_cpus; ++i) {
- pthread_create(&vcpu_info[i].thread, NULL, ap_main_loop, env);
- env = env->next_cpu;
+kvm_init_new_ap(i, env);
+env = env->next_cpu;
}
return 0;
}
diff --git a/qemu/qemu-kvm.h b/qemu/qemu-kvm.h
index a637d71..8e45f30 100644
--- a/qemu/qemu-kvm.h
+++ b/qemu/qemu-kvm.h
@@ -13,6 +13,7 @@ #include "cpu.h"
int kvm_main_loop(void);
int kvm_qemu_init(void);
int kvm_qemu_create_context(void);
+void kvm_init_new_ap(int cpu, CPUState *env);
int kvm_init_ap(void);
void kvm_qemu_destroy(void);
void kvm_load_registers(CPUState *env);
--
1.4.2
[Qemu-devel] [PATCH 10/15] handle gpe data for pio
actually grab and return data, instead of just being two
bogus functions.
Signed-off-by: Glauber Costa <[EMAIL PROTECTED]>
---
qemu/hw/acpi.c | 36
1 files changed, 36 insertions(+), 0 deletions(-)
diff --git a/qemu/hw/acpi.c b/qemu/hw/acpi.c
index 119b59a..7340f15 100644
--- a/qemu/hw/acpi.c
+++ b/qemu/hw/acpi.c
@@ -545,6 +545,24 @@ static struct gpe_regs gpe;
static uint32_t gpe_readb(void *opaque, uint32_t addr)
{
uint32_t val = 0;
+struct gpe_regs *g = opaque;
+switch (addr) {
+case GPE_BASE:
+val = g->sts & 0xFF;
+break;
+case GPE_BASE + 1:
+val = (g->sts >> 8) & 0xFF;
+break;
+case GPE_BASE + 2:
+val = g->en & 0xFF;
+break;
+case GPE_BASE + 3:
+val = (g->en >> 8) & 0xFF;
+break;
+default:
+break;
+}
+
#if defined(DEBUG)
printf("gpe read %lx == %lx\n", addr, val);
#endif
@@ -553,6 +571,24 @@ #endif
static void gpe_writeb(void *opaque, uint32_t addr, uint32_t val)
{
+struct gpe_regs *g = opaque;
+switch (addr) {
+case GPE_BASE:
+g->sts = (g->sts & ~0x) | (val & 0x);
+break;
+case GPE_BASE + 1:
+g->sts = (g->sts & 0x) | (val << 8);
+break;
+case GPE_BASE + 2:
+g->en = (g->en & ~0x) | (val & 0x);
+break;
+case GPE_BASE + 3:
+g->en = (g->en & 0x) | (val << 8);
+break;
+default:
+break;
+ }
+
#if defined(DEBUG)
printf("gpe write %lx <== %d\n", addr, val);
#endif
--
1.4.2
[Qemu-devel] [PATCH 15/15] remove acpi_build_processor_ssdt
Signed-off-by: Glauber Costa <[EMAIL PROTECTED]>
---
bios/rombios32.c | 55 --
1 files changed, 0 insertions(+), 55 deletions(-)
diff --git a/bios/rombios32.c b/bios/rombios32.c
index f2db740..77e71ac 100755
--- a/bios/rombios32.c
+++ b/bios/rombios32.c
@@ -1294,57 +1294,6 @@ #endif
h->checksum = acpi_checksum((void *)h, len);
}
-int acpi_build_processor_ssdt(uint8_t *ssdt)
-{
-uint8_t *ssdt_ptr = ssdt;
-int i, length;
-int acpi_cpus = smp_cpus > 0xff ? 0xff : smp_cpus;
-
-ssdt_ptr[9] = 0; // checksum;
-ssdt_ptr += sizeof(struct acpi_table_header);
-
-// caluculate the length of processor block and scope block excluding
PkgLength
-length = 0x0d * acpi_cpus + 4;
-
-// build processor scope header
-*(ssdt_ptr++) = 0x10; // ScopeOp
-if (length <= 0x3e) {
-*(ssdt_ptr++) = length + 1;
-} else {
-*(ssdt_ptr++) = 0x7F;
-*(ssdt_ptr++) = (length + 2) >> 6;
-}
-*(ssdt_ptr++) = '_'; // Name
-*(ssdt_ptr++) = 'P';
-*(ssdt_ptr++) = 'R';
-*(ssdt_ptr++) = '_';
-
-// build object for each processor
-for(i=0;i> 4) < 0xa ? (i >> 4) + '0' : (i >> 4) + 'A' -
0xa;
-else
-*(ssdt_ptr++) = 'U';
-*(ssdt_ptr++) = (i & 0xf) < 0xa ? (i & 0xf) + '0' : (i & 0xf) + 'A' -
0xa;
-*(ssdt_ptr++) = i;
-*(ssdt_ptr++) = 0x10; // Processor block address
-*(ssdt_ptr++) = 0xb0;
-*(ssdt_ptr++) = 0;
-*(ssdt_ptr++) = 0;
-*(ssdt_ptr++) = 6;// Processor block length
-}
-
-acpi_build_table_header((struct acpi_table_header *)ssdt,
-"SSDT", ssdt_ptr - ssdt, 1);
-
-return ssdt_ptr - ssdt;
-}
-
/* base_addr must be a multiple of 4KB */
void acpi_bios_init(void)
{
@@ -1388,10 +1337,6 @@ #endif
dsdt = (void *)(addr);
addr += sizeof(AmlCode);
-ssdt_addr = addr;
-ssdt = (void *)(addr);
-addr += acpi_build_processor_ssdt(ssdt);
-
addr = (addr + 7) & ~7;
madt_addr = addr;
madt_size = sizeof(*madt) +
--
1.4.2
[Qemu-devel] [PATCH 14/15] start a new cpu thread
spin up a new cpu thread if not yet running.
Signed-off-by: Glauber Costa <[EMAIL PROTECTED]>
---
qemu/hw/acpi.c | 16
1 files changed, 16 insertions(+), 0 deletions(-)
diff --git a/qemu/hw/acpi.c b/qemu/hw/acpi.c
index 5a6d1a8..e44c8b5 100644
--- a/qemu/hw/acpi.c
+++ b/qemu/hw/acpi.c
@@ -23,6 +23,9 @@ #include "qemu-timer.h"
#include "sysemu.h"
#include "i2c.h"
#include "smbus.h"
+#ifdef USE_KVM
+#include "qemu-kvm.h"
+#endif
//#define DEBUG
@@ -640,6 +643,19 @@ static void disable_processor(struct gpe
void qemu_system_cpu_hot_add(int cpu, int state)
{
+CPUState *env;
+
+if ((state) && (!qemu_kvm_cpu_env(cpu))) {
+env = pc_new_cpu(cpu, model, 1);
+if (!env) {
+fprintf(stderr, "cpu %d creation failed\n", cpu);
+return;
+}
+#ifdef USE_KVM
+kvm_init_new_ap(cpu, env);
+#endif
+}
+
qemu_set_irq(pm_state->irq, 1);
gpe.up = 0;
gpe.down = 0;
--
1.4.2
[Qemu-devel] [PATCH 13/15] provide _MAT to acpi processor
Signed-off-by: Glauber Costa <[EMAIL PROTECTED]>
---
bios/acpi-dsdt.dsl | 154 +++-
1 files changed, 140 insertions(+), 14 deletions(-)
diff --git a/bios/acpi-dsdt.dsl b/bios/acpi-dsdt.dsl
index 194a051..7dffb6d 100755
--- a/bios/acpi-dsdt.dsl
+++ b/bios/acpi-dsdt.dsl
@@ -35,20 +35,146 @@ DefinitionBlock (
}
Processor (CPU0, 0x00, 0xb010, 0x06) {Method (_STA) { Return(0xF)}}
-Processor (CPU1, 0x01, 0xb010, 0x06) {Method (_STA) { Return(0xF)}}
-Processor (CPU2, 0x02, 0xb010, 0x06) {Method (_STA) { Return(0xF)}}
-Processor (CPU3, 0x03, 0xb010, 0x06) {Method (_STA) { Return(0xF)}}
-Processor (CPU4, 0x04, 0xb010, 0x06) {Method (_STA) { Return(0xF)}}
-Processor (CPU5, 0x05, 0xb010, 0x06) {Method (_STA) { Return(0xF)}}
-Processor (CPU6, 0x06, 0xb010, 0x06) {Method (_STA) { Return(0xF)}}
-Processor (CPU7, 0x07, 0xb010, 0x06) {Method (_STA) { Return(0xF)}}
-Processor (CPU8, 0x08, 0xb010, 0x06) {Method (_STA) { Return(0xF)}}
-Processor (CPU9, 0x09, 0xb010, 0x06) {Method (_STA) { Return(0xF)}}
-Processor (CPUA, 0x0a, 0xb010, 0x06) {Method (_STA) { Return(0xF)}}
-Processor (CPUB, 0x0b, 0xb010, 0x06) {Method (_STA) { Return(0xF)}}
-Processor (CPUC, 0x0c, 0xb010, 0x06) {Method (_STA) { Return(0xF)}}
-Processor (CPUD, 0x0d, 0xb010, 0x06) {Method (_STA) { Return(0xF)}}
-Processor (CPUE, 0x0e, 0xb010, 0x06) {Method (_STA) { Return(0xF)}}
+Processor (CPU1, 0x01, 0xb010, 0x06) {
+Name (TMP, Buffer(0x8) {0x0, 0x8, 0x01, 0x01, 0x1, 0x0, 0x0, 0x0})
+Method(_MAT, 0) {
+If (And(\_PR.PRU, 0x2)) { Return(TMP) }
+Else { Return(0x0) }
+}
+Method (_STA) {
+Return(0xF)
+}
+}
+Processor (CPU2, 0x02, 0xb010, 0x06) {
+Name (TMP, Buffer(0x8) {0x0, 0x8, 0x02, 0x02, 0x1, 0x0, 0x0, 0x0})
+Method(_MAT, 0) {
+If (And(\_PR.PRU, 0x4)) { Return(TMP) }
+Else { Return(0x0) }
+}
+Method (_STA) {
+Return(0xF)
+}
+}
+Processor (CPU3, 0x03, 0xb010, 0x06) {
+Name (TMP, Buffer(0x8) {0x0, 0x8, 0x03, 0x03, 0x1, 0x0, 0x0, 0x0})
+Method(_MAT, 0) {
+If (And(\_PR.PRU, 0x8)) { Return(TMP) }
+Else { Return(0x0) }
+}
+Method (_STA) {
+Return(0xF)
+}
+}
+Processor (CPU4, 0x04, 0xb010, 0x06) {
+Name (TMP, Buffer(0x8) {0x0, 0x8, 0x04, 0x04, 0x1, 0x0, 0x0, 0x0})
+Method(_MAT, 0) {
+If (And(\_PR.PRU, 0x10)) { Return(TMP) }
+Else { Return(0x0) }
+}
+Method (_STA) {
+Return(0xF)
+}
+}
+Processor (CPU5, 0x05, 0xb010, 0x06) {
+Name (TMP, Buffer(0x8) {0x0, 0x8, 0x05, 0x05, 0x1, 0x0, 0x0, 0x0})
+Method(_MAT, 0) {
+If (And(\_PR.PRU, 0x20)) { Return(TMP) }
+Else { Return(0x0) }
+}
+Method (_STA) {
+Return(0xF)
+}
+}
+Processor (CPU6, 0x06, 0xb010, 0x06) {
+Name (TMP, Buffer(0x8) {0x0, 0x8, 0x06, 0x06, 0x1, 0x0, 0x0, 0x0})
+Method(_MAT, 0) {
+If (And(\_PR.PRU, 0x40)) { Return(TMP) }
+Else { Return(0x0) }
+}
+Method (_STA) {
+Return(0xF)
+}
+}
+Processor (CPU7, 0x07, 0xb010, 0x06) {
+Name (TMP, Buffer(0x8) {0x0, 0x8, 0x07, 0x07, 0x1, 0x0, 0x0, 0x0})
+Method(_MAT, 0) {
+If (And(\_PR.PRU, 0x80)) { Return(TMP) }
+Else { Return(0x0) }
+}
+Method (_STA) {
+Return(0xF)
+}
+}
+Processor (CPU8, 0x08, 0xb010, 0x06) {
+Name (TMP, Buffer(0x8) {0x0, 0x8, 0x08, 0x08, 0x1, 0x0, 0x0, 0x0})
+Method(_MAT, 0) {
+If (And(\_PR.PRU, 0x100)) { Return(TMP) }
+Else { Return(0x0) }
+}
+Method (_STA) {
+Return(0xF)
+}
+}
+Processor (CPU9, 0x09, 0xb010, 0x06) {
+Name (TMP, Buffer(0x8) {0x0, 0x8, 0x09, 0x09, 0x1, 0x0, 0x0, 0x0})
+Method(_MAT, 0) {
+If (And(\_PR.PRU, 0x200)) { Return(TMP) }
+Else { Return(0x0) }
+}
+Method (_STA) {
+Return(0xF)
+}
+}
+Processor (CPUA, 0x0a, 0xb010, 0x06) {
+Name (TMP, Buffer(0x8) {0x0, 0x8, 0x0A, 0x0A, 0x1, 0x0, 0x0, 0x0})
+Method(_MAT, 0) {
+If (And(\_PR
[Qemu-devel] Re: TCG on i386 can't generate qemu_st64 for 32-bit target
Blue Swirl wrote: > Hi, > > There is a problem with the Sparc32 target on i386 host. Store double > word op (std) cannot be generated and TCG just aborts. It looks like > the registers are so few on i386 that TCG can't find registers for the > qemu_st64 call. The problem does not appear on x86_64 host, or for > Sparc64 target (stx/ldx) on i386, or with 64-bit load (ldd) on Sparc32 > target. > > The attached patch would work around the problem, but I agree that > it's ugly and it would bring back one instance of T2 use. I also tried > preallocating a 64-bit register but that didn't help. > > I suppose instead the following piece (tcg/i386/tcg-target.c:737) > could be modified to lower the pressure for registers but I'm not that > familiar with x86 assembly. > [...] There are not enough free registers because of the legacy 3 cpu_T[n] fixed registers. Once you have no helpers using cpu_T[n] implicitely, it will be possible to allocate cpu_T[n] as normal temporaries and to free the associated fixed registers. Before that your solution is acceptable. Another hack would be to force the 'r_dword' variable to be stored in cpu_T[1] and cpu_T[2], but TCG gives no clean way to do it. Fabrice.
[Qemu-devel] Re: [kvm-devel] [PATCH 4/15] mark processors as presents
On Feb 27, 2008, at 12:05 AM, Alexander Graf wrote:
On Feb 26, 2008, at 8:56 PM, Glauber Costa wrote:
mark processors as present through the _STA method
Signed-off-by: Glauber Costa <[EMAIL PROTECTED]>
---
bios/acpi-dsdt.dsl | 18 ++
1 files changed, 18 insertions(+), 0 deletions(-)
diff --git a/bios/acpi-dsdt.dsl b/bios/acpi-dsdt.dsl
index e900795..244e906 100755
--- a/bios/acpi-dsdt.dsl
+++ b/bios/acpi-dsdt.dsl
@@ -25,6 +25,24 @@ DefinitionBlock (
0x1 // OEM Revision
)
{
+ Scope (\_PR)
+ {
+Processor (CPU0, 0x00, 0xb010, 0x06) {Method (_STA)
{ Return(0xF)}}
+Processor (CPU1, 0x01, 0xb010, 0x06) {Method (_STA)
{ Return(0xF)}}
+Processor (CPU2, 0x02, 0xb010, 0x06) {Method (_STA)
{ Return(0xF)}}
+Processor (CPU3, 0x03, 0xb010, 0x06) {Method (_STA)
{ Return(0xF)}}
+Processor (CPU4, 0x04, 0xb010, 0x06) {Method (_STA)
{ Return(0xF)}}
+Processor (CPU5, 0x05, 0xb010, 0x06) {Method (_STA)
{ Return(0xF)}}
+Processor (CPU6, 0x06, 0xb010, 0x06) {Method (_STA)
{ Return(0xF)}}
+Processor (CPU7, 0x07, 0xb010, 0x06) {Method (_STA)
{ Return(0xF)}}
+Processor (CPU8, 0x08, 0xb010, 0x06) {Method (_STA)
{ Return(0xF)}}
+Processor (CPU9, 0x09, 0xb010, 0x06) {Method (_STA)
{ Return(0xF)}}
+Processor (CPUA, 0x0a, 0xb010, 0x06) {Method (_STA)
{ Return(0xF)}}
+Processor (CPUB, 0x0b, 0xb010, 0x06) {Method (_STA)
{ Return(0xF)}}
+Processor (CPUC, 0x0c, 0xb010, 0x06) {Method (_STA)
{ Return(0xF)}}
+Processor (CPUD, 0x0d, 0xb010, 0x06) {Method (_STA)
{ Return(0xF)}}
+Processor (CPUE, 0x0e, 0xb010, 0x06) {Method (_STA)
{ Return(0xF)}}
So if I understand this correctly, you set all possible CPUs on active
and available. What exactly happens if one of these is not usable?
I know that Darwin broke on the _PR description quite badly, as it
just allocates possible execution engines using the ACPI Processor
specification and I do not know what happens if the engine is not
available.
I have to admit that I have not tested it as I do not have the time to
do so though, so maybe it works.
I just read patch 13 ... nevermind
[Qemu-devel] Re: [kvm-devel] [PATCH 4/15] mark processors as presents
On Feb 26, 2008, at 8:56 PM, Glauber Costa wrote:
mark processors as present through the _STA method
Signed-off-by: Glauber Costa <[EMAIL PROTECTED]>
---
bios/acpi-dsdt.dsl | 18 ++
1 files changed, 18 insertions(+), 0 deletions(-)
diff --git a/bios/acpi-dsdt.dsl b/bios/acpi-dsdt.dsl
index e900795..244e906 100755
--- a/bios/acpi-dsdt.dsl
+++ b/bios/acpi-dsdt.dsl
@@ -25,6 +25,24 @@ DefinitionBlock (
0x1 // OEM Revision
)
{
+ Scope (\_PR)
+ {
+Processor (CPU0, 0x00, 0xb010, 0x06) {Method (_STA)
{ Return(0xF)}}
+Processor (CPU1, 0x01, 0xb010, 0x06) {Method (_STA)
{ Return(0xF)}}
+Processor (CPU2, 0x02, 0xb010, 0x06) {Method (_STA)
{ Return(0xF)}}
+Processor (CPU3, 0x03, 0xb010, 0x06) {Method (_STA)
{ Return(0xF)}}
+Processor (CPU4, 0x04, 0xb010, 0x06) {Method (_STA)
{ Return(0xF)}}
+Processor (CPU5, 0x05, 0xb010, 0x06) {Method (_STA)
{ Return(0xF)}}
+Processor (CPU6, 0x06, 0xb010, 0x06) {Method (_STA)
{ Return(0xF)}}
+Processor (CPU7, 0x07, 0xb010, 0x06) {Method (_STA)
{ Return(0xF)}}
+Processor (CPU8, 0x08, 0xb010, 0x06) {Method (_STA)
{ Return(0xF)}}
+Processor (CPU9, 0x09, 0xb010, 0x06) {Method (_STA)
{ Return(0xF)}}
+Processor (CPUA, 0x0a, 0xb010, 0x06) {Method (_STA)
{ Return(0xF)}}
+Processor (CPUB, 0x0b, 0xb010, 0x06) {Method (_STA)
{ Return(0xF)}}
+Processor (CPUC, 0x0c, 0xb010, 0x06) {Method (_STA)
{ Return(0xF)}}
+Processor (CPUD, 0x0d, 0xb010, 0x06) {Method (_STA)
{ Return(0xF)}}
+Processor (CPUE, 0x0e, 0xb010, 0x06) {Method (_STA)
{ Return(0xF)}}
So if I understand this correctly, you set all possible CPUs on active
and available. What exactly happens if one of these is not usable?
I know that Darwin broke on the _PR description quite badly, as it
just allocates possible execution engines using the ACPI Processor
specification and I do not know what happens if the engine is not
available.
I have to admit that I have not tested it as I do not have the time to
do so though, so maybe it works.
+}
Scope (\)
{
--
1.4.2
Re: [Qemu-devel] Re: qemu unchecked block read/write vulnerability
On Tue, Feb 26, 2008 at 07:46:51PM +, Daniel P. Berrange wrote: > On Tue, Feb 19, 2008 at 04:39:07PM +, Ian Jackson wrote: > Content-Description: message body text > > I was doing some merging of qemu and I noticed that the block driver > > backends don't check the guest's read/write attempts against the > > nominal size of the block device. > > > > I haven't checked all of the backends but I have verified the bug with > > block-cow.c, which I have in my test induced to set a bitmap bit at an > > address which is not actually part of the bitmap. In my tests I used > > as my guest a Linux kernel which I'd specially modifed to allow me to > > access out-of-range blocks. > > > > I think the fix is probably to insert a couple of range checks in the > > generic block dispatch layer and I attach a patch to achieve this. > > FYI, this patch appears to cause massive unrecoverable data corruption for > qcow2 format disks. It looks like the sector range check is being applied > to the total sector count of the actual qcow datafile on disk, rather > than the total sector count of the logical disk. I suspect the same may > occur with other non-raw disk formats, so be wary The original patch adds checks to the main bdrv_XXX apis to validate that the I/O operation does not exceed the bounds of the disk - ie beyond the total_sectors count. This works correctly for bdrv_XXX calls from the IDE driver. With disk formats like QCow though, bdrv_XXX is re-entrant, because the QCow driver uses the block APIs for dealing with its underlying file. The problem is that QCow files are grow-on-demand, so writes will *explicitly* be beyond the end of the file. The original patch blocks any I/O operation which would cause the QCow file to grow, resulting it more or less catasatrophic data loss. Basically the bounds checking needs to distinguish between checking for the logical disk extents, vs the physical disk extents. For raw files these are the same so initial tests showed no problems, but for QCow format disks they are different & thus we see a problem What follows is a revised patch which introduces a flag BDRV_O_AUTOGROW which can be passed to bdrv_open to indicate that the files can be allowed to automatically extend their extents. This flag should only be used by internal block drivers such as block-qcow2.c, block-vmdk.c In my testing this has fixed the qcow corruption, and still maintains the goal of Ian's original patch which was to prevent the guest VM writing beyond the logical disk extents. block-qcow.c |2 - block-qcow2.c |2 - block-vmdk.c |2 - block.c | 74 ++ block.h |1 block_int.h |1 6 files changed, 79 insertions(+), 3 deletions(-) Dan. Index: block-qcow.c === RCS file: /sources/qemu/qemu/block-qcow.c,v retrieving revision 1.15 diff -u -p -r1.15 block-qcow.c --- block-qcow.c11 Nov 2007 02:51:16 - 1.15 +++ block-qcow.c26 Feb 2008 23:46:41 - @@ -95,7 +95,7 @@ static int qcow_open(BlockDriverState *b int len, i, shift, ret; QCowHeader header; -ret = bdrv_file_open(&s->hd, filename, flags); +ret = bdrv_file_open(&s->hd, filename, flags | BDRV_O_AUTOGROW); if (ret < 0) return ret; if (bdrv_pread(s->hd, 0, &header, sizeof(header)) != sizeof(header)) Index: block-qcow2.c === RCS file: /sources/qemu/qemu/block-qcow2.c,v retrieving revision 1.10 diff -u -p -r1.10 block-qcow2.c --- block-qcow2.c 11 Nov 2007 02:51:16 - 1.10 +++ block-qcow2.c 26 Feb 2008 23:46:41 - @@ -191,7 +191,7 @@ static int qcow_open(BlockDriverState *b int len, i, shift, ret; QCowHeader header; -ret = bdrv_file_open(&s->hd, filename, flags); +ret = bdrv_file_open(&s->hd, filename, flags | BDRV_O_AUTOGROW); if (ret < 0) return ret; if (bdrv_pread(s->hd, 0, &header, sizeof(header)) != sizeof(header)) Index: block-vmdk.c === RCS file: /sources/qemu/qemu/block-vmdk.c,v retrieving revision 1.19 diff -u -p -r1.19 block-vmdk.c --- block-vmdk.c14 Jan 2008 03:48:37 - 1.19 +++ block-vmdk.c26 Feb 2008 23:46:41 - @@ -378,7 +378,7 @@ static int vmdk_open(BlockDriverState *b flags = BDRV_O_RDONLY; fprintf(stderr, "(VMDK) image open: flags=0x%x filename=%s\n", flags, bs->filename); -ret = bdrv_file_open(&s->hd, filename, flags); +ret = bdrv_file_open(&s->hd, filename, flags | BDRV_O_AUTOGROW); if (ret < 0) return ret; if (bdrv_pread(s->hd, 0, &magic, sizeof(magic)) != sizeof(magic)) Index: block.c === RCS file: /sources/qemu/qemu/block.c,v retrieving revision 1.53 diff -u -p -r1.53 block.c -
Re: [Qemu-devel] [PATCH] don't die if switching to fullscreen mode fails
hi, > Wow. This patch is messy, if I may say so. There must be a more > elegant way to do this, especially given the fact that you remove > atexit(sdl_cleanup)s without explanation. well, the diff output is messy, because I added sdl_resize2() above sdl_resize() to avoid adding a forward declaration. the patch itself might be messy as well, but that depends on your point of view. I don't think it is too messy. I did it that way because I wanted the patch to be as less invasively as possible. I did not change any existing function prototypes and all the changes are restricted to one source file. just as an example: changing the function prototype of sdl_resize() would lead to much more changes at other places as well to make things consistent again. I don't think this would make the patch less messy. I didn't remove the atexit() call, it is just moved some lines upwards (look carefully) because now there is a check if the initial resize to 640x400 fails. If it fails we call exit() and that means the call to atexit() must be done before a possible call to exit(). However, I agree with you that there should exist another solution. Does qemu have access to the maximum resolution of the host display? cheers, Andi
Re: [Qemu-devel] [PATCH] don't die if switching to fullscreen mode fails
hi, >> use windowed mode as fallback option if we are already in fullscreen >> mode and the new resolution is too high and print a message to the >> console > > Do you end up with a window bigger than the screen, then? Is there a > chance the user can escape from this situation, i.e. reach all parts > of the virtual screen to find the switch for setting the resolution? yes, that's true, but it is no problem at all. First of all you can move the window around so it is possible to reach everything inside the window. in addition you can always use ctrl+alt+del under windows to shutdown. under X11 you can always escape using ctrl+alt+backspace. > Another option would be to simply display an "Out of range error" > across the screen, like a real monitor would do. Usually, operations > systems feature a protection against setting a resolution higher than > supported by hardware already (set back to a lower reolution after > some delay). to make that working we would need to know the maximum resolution of the host display. does qemu store this information somewhere? but I think this would not work anyway because the guest os might (at least windows does) crash if qemu resizes the display to an other resolution than the requested one. so testing if the new resolution is too high and in case using a lower resolution would crash windows xp, I have tried that already. I've extensively tested this patch using windows as guest os and it works perfectly for me. Maybe somebody could test the patch using other guest os as well. cheers, Andi
Re: [Qemu-devel] bug (?) related to kqemu and/or Minix3
Hi... The screen capture didn't show anything suspicious...maybe the issue is related to segmentation? Linux...AFAIK doesn't use CS segment that much in GDT regards, Mulyadi
