Re: [Qemu-devel] virtio block device and sysfs
On Sat, Mar 06, 2010 at 11:42:34PM +0100, Marc Haber wrote: > My goal is to have a possibility to give a "speaking" name to any > block device handed into a guest instance by the host. That name > should be visible inside the guest, just as a LV is visible with its > name in the system running the LVM. At the risk of AOLing this old thread, /me too would like to see this. It would significantly improve the reliability of mapping libguestfs files to devices. Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Read my programming blog: http://rwmj.wordpress.com Fedora now supports 80 OCaml packages (the OPEN alternative to F#) http://cocan.org/getting_started_with_ocaml_on_red_hat_and_fedora
Re: [Qemu-devel] NetBSD qemu block device support
On Thu, Mar 18, 2010 at 10:32:36PM +0200, Blue Swirl wrote: > The patch does not apply to current development repository. > > There is no description of the change suitable for changelog without > any editing. > > Signed-off-by: line is missing. > > The patch combines formatting (whitespace) changes with functional > changes. The formatting changes seem useless. > > The essence of the patch is twofold, It adds NetBSD specific includes > and NetBSD specific code to raw_getlength(). These look OK, except > formatting may be a bit off (no space after if) and currently the code > probably should be surrounded by > #ifdef DIOCGWEDGEINFO > #endif > or just #ifdef __NetBSD__. Also given the extreme mess that raw_getlength is I would much prefer to give every new OS it's own copy of it, similar to how we already handle OpenBSD today.
[Qemu-devel] Re: Completing big real mode emulation
Am 20.03.2010 um 15:02 schrieb Mohammed Gamal : On Sat, Mar 20, 2010 at 3:18 PM, Avi Kivity wrote: On 03/20/2010 10:55 AM, Alexander Graf wrote: I'd say that a GSoC project would rather focus on making a guest OS work than working on generic big real mode. Having Windows 98 support is way more visible to the users. And hopefully more fun to implement too, as it's a visible goal :-). Big real mode allows you to boot various OSes, such as that old Ubuntu/SuSE boot loader which triggered the whole thing. I thought legacy Windows uses it too? IIRC even current Windows (last I checked was XP, but it's probably true for newer) invokes big real mode inadvertently. All it takes is not to clear fs and gs while switching to real mode. It works because the real mode code never uses gs and fs (i.e. while we are technically in big real mode, the guest never relies on this), and because there are enough hacks in vmx.c to make it work (restoring fs and gs after the switch back). IIRC there are other cases of invalid guest state that we hack into place during mode switches. Either way - then we should make the goal of the project to support those old boot loaders. IMHO it should contain visibility. Doing theoretical stuff is just less fun for all parties. Or does that stuff work already? Mostly those old guests aged beyond usefulness. They are still broken, but nobody installs new images. Old images installed via workarounds work. Goals for this task could include: - get those older guests working - get emulate_invalid_guest_state=1 to work on all supported guests - switch to emulate_invalid_guest_state=1 as the default - drop the code supporting emulate_invalid_guest_state=0 eventually To this end I guess the next logical step is to compile a list of guests that are currently not working/work with hacks only, and get them working. Here are some suggestions: - MINIX 3.1.6 (developers have been recently filing bug reports because of boot failures) - Win XP with emulation enabled - FreeDOS with memory extenders Any other guests you'd like to see on this list? I remember old openSUSE iso bootloaders had issues. I think it was around 10.3, but might have been earlier. Alex
[Qemu-devel] Re: Completing big real mode emulation
On Sat, Mar 20, 2010 at 3:18 PM, Avi Kivity wrote: > On 03/20/2010 10:55 AM, Alexander Graf wrote: >>> I'd say that a GSoC project would rather focus on making a guest OS work than working on generic big real mode. Having Windows 98 support is way more visible to the users. And hopefully more fun to implement too, as it's a visible goal :-). >>> >>> Big real mode allows you to boot various OSes, such as that old >>> Ubuntu/SuSE boot loader which triggered the whole thing. >>> >> >> I thought legacy Windows uses it too? >> > > IIRC even current Windows (last I checked was XP, but it's probably true for > newer) invokes big real mode inadvertently. All it takes is not to clear fs > and gs while switching to real mode. It works because the real mode code > never uses gs and fs (i.e. while we are technically in big real mode, the > guest never relies on this), and because there are enough hacks in vmx.c to > make it work (restoring fs and gs after the switch back). IIRC there are > other cases of invalid guest state that we hack into place during mode > switches. > >> Either way - then we should make the goal of the project to support those >> old boot loaders. IMHO it should contain visibility. Doing theoretical stuff >> is just less fun for all parties. Or does that stuff work already? >> > > Mostly those old guests aged beyond usefulness. They are still broken, but > nobody installs new images. Old images installed via workarounds work. > > Goals for this task could include: > > - get those older guests working > - get emulate_invalid_guest_state=1 to work on all supported guests > - switch to emulate_invalid_guest_state=1 as the default > - drop the code supporting emulate_invalid_guest_state=0 eventually To this end I guess the next logical step is to compile a list of guests that are currently not working/work with hacks only, and get them working. Here are some suggestions: - MINIX 3.1.6 (developers have been recently filing bug reports because of boot failures) - Win XP with emulation enabled - FreeDOS with memory extenders Any other guests you'd like to see on this list?
[Qemu-devel] Re: Completing big real mode emulation
On 03/20/2010 10:55 AM, Alexander Graf wrote: I'd say that a GSoC project would rather focus on making a guest OS work than working on generic big real mode. Having Windows 98 support is way more visible to the users. And hopefully more fun to implement too, as it's a visible goal :-). Big real mode allows you to boot various OSes, such as that old Ubuntu/SuSE boot loader which triggered the whole thing. I thought legacy Windows uses it too? IIRC even current Windows (last I checked was XP, but it's probably true for newer) invokes big real mode inadvertently. All it takes is not to clear fs and gs while switching to real mode. It works because the real mode code never uses gs and fs (i.e. while we are technically in big real mode, the guest never relies on this), and because there are enough hacks in vmx.c to make it work (restoring fs and gs after the switch back). IIRC there are other cases of invalid guest state that we hack into place during mode switches. Either way - then we should make the goal of the project to support those old boot loaders. IMHO it should contain visibility. Doing theoretical stuff is just less fun for all parties. Or does that stuff work already? Mostly those old guests aged beyond usefulness. They are still broken, but nobody installs new images. Old images installed via workarounds work. Goals for this task could include: - get those older guests working - get emulate_invalid_guest_state=1 to work on all supported guests - switch to emulate_invalid_guest_state=1 as the default - drop the code supporting emulate_invalid_guest_state=0 eventually -- Do not meddle in the internals of kernels, for they are subtle and quick to panic.
[Qemu-devel] Re: Completing big real mode emulation
On 20.03.2010, at 09:39, Avi Kivity wrote: > On 03/20/2010 10:34 AM, Alexander Graf wrote: >> >> Interestingly enough Hannes just tried to boot a Windows 98 VM on SVM >> yesterday and failed, while the same VM worked (mostly) with -no-kvm. So >> apparently there's more missing to it than just big real mode. >> > > Was there an error message? He got one. I just tried to boot up my test VM and it just hanged in that empty DOS prompt. > >> I'd say that a GSoC project would rather focus on making a guest OS work >> than working on generic big real mode. Having Windows 98 support is way more >> visible to the users. And hopefully more fun to implement too, as it's a >> visible goal :-). >> > > Big real mode allows you to boot various OSes, such as that old Ubuntu/SuSE > boot loader which triggered the whole thing. I thought legacy Windows uses it too? Either way - then we should make the goal of the project to support those old boot loaders. IMHO it should contain visibility. Doing theoretical stuff is just less fun for all parties. Or does that stuff work already? Alex
[Qemu-devel] Re: Completing big real mode emulation
On 03/20/2010 10:34 AM, Alexander Graf wrote: Interestingly enough Hannes just tried to boot a Windows 98 VM on SVM yesterday and failed, while the same VM worked (mostly) with -no-kvm. So apparently there's more missing to it than just big real mode. Was there an error message? I'd say that a GSoC project would rather focus on making a guest OS work than working on generic big real mode. Having Windows 98 support is way more visible to the users. And hopefully more fun to implement too, as it's a visible goal :-). Big real mode allows you to boot various OSes, such as that old Ubuntu/SuSE boot loader which triggered the whole thing. -- Do not meddle in the internals of kernels, for they are subtle and quick to panic.
[Qemu-devel] Re: Completing big real mode emulation
On 20.03.2010, at 08:49, Avi Kivity wrote: > On 03/19/2010 05:29 PM, Mohammed Gamal wrote: >> Hello all, >> As some of you might know, I've worked on supporting big real mode >> emulation on VMX back in GSoC 2008. Looking at the Qemu GSoC ideas >> list for this year, I found it among the possible ideas for a GSoC >> project. I'd be interested in driving this feature towards completion, >> and I have a few questions about it. >> >> - The kernel-space modifications needed to detect an invalid guest >> state on VMX and drive emulation from that point was almost complete. >> The part that was missing the most, is that the kvm x86 emulator >> wasn't complete and didn't support the entire instruction set. I've >> seen that the emulator has been the focus of some recent patches >> (namely by Gleb Natapov). Is there anything else required to get big >> real mode to work correctly on KVM? >> > > IIRC there are some bugs in invalid guest state detection, so it may need > some work. We don't support interrupt injection during invalid guest state, > that will be tricky since it needs access to memory and interrupt injection > currently happens from atomic context. Finally, there may still be missing > instructions. > >> - Do we have other problems supporting big real mode on non-VMX >> instruction sets? And do we have problems supporting it on the >> userspace side? >> > > No. Interestingly enough Hannes just tried to boot a Windows 98 VM on SVM yesterday and failed, while the same VM worked (mostly) with -no-kvm. So apparently there's more missing to it than just big real mode. I'd say that a GSoC project would rather focus on making a guest OS work than working on generic big real mode. Having Windows 98 support is way more visible to the users. And hopefully more fun to implement too, as it's a visible goal :-). Alex
Re: [Qemu-devel] build error in current master
On 3/20/10, Paul Bolle wrote:
> 0) Building current master (3290c4aac5b97bb1e3b2b28d94669f2c611ce84a,
> Introduce a default qmp session) fails here:
>
> $ make > /dev/null
> cc1: warnings being treated as errors
> curses.c: In function ‘curses_display_init’:
> curses.c:341: error: initialization from incompatible pointer type
> make: *** [curses.o] Error 1
>
> 1) It seems caused by commit d7234f4d (committed half a day ago):
>
> $ git blame curses.c | grep 341
> d7234f4d (Anthony Liguori 2010-03-17 17:59:26 -0500 341) static
> Notifier notifier = { .notify = curses_atexit };
>
> $ git log -1 d7234f4d --pretty=short
> commit d7234f4d7e373a708e1df9ab565a71b71b189025
> Author: Anthony Liguori
>
> Convert atexit users to exit_notifier
>
> Regards,
Fixed in HEAD.
[Qemu-devel] [PATCH] curses: Fix compilation error
d7234f4d7e373a708e1df9ab565a71b71b189025 was incomplete
and results in a compilation error when QEMU is configured
with curses support.
Fix this and clean up the code a little, too.
Signed-off-by: Stefan Weil
---
curses.c | 10 +++---
1 files changed, 3 insertions(+), 7 deletions(-)
diff --git a/curses.c b/curses.c
index f9a983a..9fd680e 100644
--- a/curses.c
+++ b/curses.c
@@ -294,16 +294,12 @@ static void curses_refresh(DisplayState *ds)
}
}
-static void curses_cleanup(void *opaque)
+static void curses_cleanup(Notifier *notifier)
{
+(void)notifier;
endwin();
}
-static void curses_atexit(void)
-{
-curses_cleanup(NULL);
-}
-
static void curses_setup(void)
{
int i, colour_default[8] = {
@@ -338,7 +334,7 @@ static void curses_keyboard_setup(void)
void curses_display_init(DisplayState *ds, int full_screen)
{
DisplayChangeListener *dcl;
-static Notifier notifier = { .notify = curses_atexit };
+static Notifier notifier = { .notify = curses_cleanup };
#ifndef _WIN32
if (!isatty(1)) {
fprintf(stderr, "We need a terminal output\n");
--
1.7.0
[Qemu-devel] [PATCH] Fix curses_atexit definition for use with exit_notifier.
Hello, As in subject. -- Jai Menon 0001-Fix-curses_atexit-definition-for-use-with-exit_notif.patch Description: Binary data
[Qemu-devel] Re: Completing big real mode emulation
On 03/19/2010 05:29 PM, Mohammed Gamal wrote: Hello all, As some of you might know, I've worked on supporting big real mode emulation on VMX back in GSoC 2008. Looking at the Qemu GSoC ideas list for this year, I found it among the possible ideas for a GSoC project. I'd be interested in driving this feature towards completion, and I have a few questions about it. - The kernel-space modifications needed to detect an invalid guest state on VMX and drive emulation from that point was almost complete. The part that was missing the most, is that the kvm x86 emulator wasn't complete and didn't support the entire instruction set. I've seen that the emulator has been the focus of some recent patches (namely by Gleb Natapov). Is there anything else required to get big real mode to work correctly on KVM? IIRC there are some bugs in invalid guest state detection, so it may need some work. We don't support interrupt injection during invalid guest state, that will be tricky since it needs access to memory and interrupt injection currently happens from atomic context. Finally, there may still be missing instructions. - Do we have other problems supporting big real mode on non-VMX instruction sets? And do we have problems supporting it on the userspace side? No. - Is there anything I am missing? I think that's pretty much it. -- Do not meddle in the internals of kernels, for they are subtle and quick to panic.
[Qemu-devel] build error in current master
0) Building current master (3290c4aac5b97bb1e3b2b28d94669f2c611ce84a,
Introduce a default qmp session) fails here:
$ make > /dev/null
cc1: warnings being treated as errors
curses.c: In function ‘curses_display_init’:
curses.c:341: error: initialization from incompatible pointer type
make: *** [curses.o] Error 1
1) It seems caused by commit d7234f4d (committed half a day ago):
$ git blame curses.c | grep 341
d7234f4d (Anthony Liguori 2010-03-17 17:59:26 -0500 341) static
Notifier notifier = { .notify = curses_atexit };
$ git log -1 d7234f4d --pretty=short
commit d7234f4d7e373a708e1df9ab565a71b71b189025
Author: Anthony Liguori
Convert atexit users to exit_notifier
Regards,
Paul Bolle
[Qemu-devel] Re: [PATCH 4/9] virtio-serial: Handle scatter-gather buffers for control messages
On 03/19/2010 01:58 PM, Amit Shah wrote:
Current control messages are small enough to not be split into multiple
buffers but we could run into such a situation in the future or a
malicious guest could cause such a situation.
So handle the entire iov request for control messages.
Also ensure the size of the control request is>= what we expect
otherwise we risk accessing memory that we don't own.
Signed-off-by: Amit Shah
CC: Avi Kivity
Reported-by: Avi Kivity
---
hw/virtio-serial-bus.c | 43 ---
1 files changed, 40 insertions(+), 3 deletions(-)
diff --git a/hw/virtio-serial-bus.c b/hw/virtio-serial-bus.c
index 830eb75..d5887ab 100644
--- a/hw/virtio-serial-bus.c
+++ b/hw/virtio-serial-bus.c
@@ -200,7 +200,7 @@ size_t virtio_serial_guest_ready(VirtIOSerialPort *port)
}
/* Guest wants to notify us of some event */
-static void handle_control_message(VirtIOSerial *vser, void *buf)
+static void handle_control_message(VirtIOSerial *vser, void *buf, size_t len)
{
struct VirtIOSerialPort *port;
struct virtio_console_control cpkt, *gcpkt;
@@ -208,6 +208,10 @@ static void handle_control_message(VirtIOSerial *vser,
void *buf)
size_t buffer_len;
gcpkt = buf;
+if (len< sizeof(cpkt)) {
+/* The guest sent an invalid control packet */
+return;
+}
port = find_port_by_id(vser, ldl_p(&gcpkt->id));
if (!port)
return;
@@ -281,12 +285,45 @@ static void control_out(VirtIODevice *vdev, VirtQueue *vq)
{
VirtQueueElement elem;
VirtIOSerial *vser;
+uint8_t *buf;
+size_t len;
vser = DO_UPCAST(VirtIOSerial, vdev, vdev);
+len = 0;
+buf = NULL;
while (virtqueue_pop(vq,&elem)) {
-handle_control_message(vser, elem.out_sg[0].iov_base);
-virtqueue_push(vq,&elem, elem.out_sg[0].iov_len);
+unsigned int i;
+size_t cur_len, offset;
+
+cur_len = 0;
+for (i = 0; i< elem.out_num; i++) {
+cur_len += elem.out_sg[i].iov_len;
+}
+/*
+ * Allocate a new buf only if we didn't have one previously or
+ * if the size of the buf differs
+ */
+if (cur_len != len) {
+if (len) {
+qemu_free(buf);
+}
+buf = qemu_malloc(cur_len);
+}
+
+offset = 0;
+for (i = 0; i< elem.out_num; i++) {
+memcpy(buf + offset, elem.out_sg[i].iov_base,
+ elem.out_sg[i].iov_len);
+offset += elem.out_sg[i].iov_len;
+}
+len = cur_len;
+
+handle_control_message(vser, buf, len);
+virtqueue_push(vq,&elem, len);
+}
+if (len) {
+qemu_free(buf);
}
virtio_notify(vdev, vq);
}
Isn't there some virtio function to linearize requests?
--
Do not meddle in the internals of kernels, for they are subtle and quick to
panic.
Re: [Qemu-devel] [PATCH] qemu-io: Fix return value handling of bdrv_open
Ryota Ozaki writes: > bdrv_open may return -errno so we have to check > if the return value is '< 0', not '== -1'. Looks good, thanks!
[Qemu-devel] [PATCH] qemu-io: Fix return value handling of bdrv_open
bdrv_open may return -errno so we have to check
if the return value is '< 0', not '== -1'.
Signed-off-by: Ryota Ozaki
---
qemu-io.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/qemu-io.c b/qemu-io.c
index b2f2f5a..2f195bf 100644
--- a/qemu-io.c
+++ b/qemu-io.c
@@ -1284,7 +1284,7 @@ static int openfile(char *name, int flags, int growable)
flags |= BDRV_O_FILE;
}
- if (bdrv_open(bs, name, flags) == -1) {
+ if (bdrv_open(bs, name, flags) < 0) {
fprintf(stderr, "%s: can't open device %s\n", progname, name);
bs = NULL;
return 1;
--
1.6.5.2
Re: [Qemu-devel] [PATCH 1/3] qemu-nbd: Fix return value handling of bdrv_open
On Sat, Mar 20, 2010 at 4:01 PM, Markus Armbruster wrote: > Ryota Ozaki writes: > >> bdrv_open may return -errno so we have to check >> if the return value is '< 0', not '== -1'. >> >> Signed-off-by: Ryota Ozaki >> --- >> qemu-nbd.c | 2 +- >> 1 files changed, 1 insertions(+), 1 deletions(-) >> >> diff --git a/qemu-nbd.c b/qemu-nbd.c >> index a393583..b89c361 100644 >> --- a/qemu-nbd.c >> +++ b/qemu-nbd.c >> @@ -333,7 +333,7 @@ int main(int argc, char **argv) >> if (bs == NULL) >> return 1; >> >> - if (bdrv_open(bs, argv[optind], flags) == -1) >> + if (bdrv_open(bs, argv[optind], flags) < 0) >> return 1; >> >> fd_size = bs->total_sectors * 512; > > Same bug in qemu-io.c. Could you fix that as well? > OK. I will. Thanks, ozaki-r
Re: [Qemu-devel] [PATCH 1/3] qemu-nbd: Fix return value handling of bdrv_open
Ryota Ozaki writes: > bdrv_open may return -errno so we have to check > if the return value is '< 0', not '== -1'. > > Signed-off-by: Ryota Ozaki > --- > qemu-nbd.c |2 +- > 1 files changed, 1 insertions(+), 1 deletions(-) > > diff --git a/qemu-nbd.c b/qemu-nbd.c > index a393583..b89c361 100644 > --- a/qemu-nbd.c > +++ b/qemu-nbd.c > @@ -333,7 +333,7 @@ int main(int argc, char **argv) > if (bs == NULL) > return 1; > > -if (bdrv_open(bs, argv[optind], flags) == -1) > +if (bdrv_open(bs, argv[optind], flags) < 0) > return 1; > > fd_size = bs->total_sectors * 512; Same bug in qemu-io.c. Could you fix that as well?
