[Qemu-devel] Qemu 0.9.1 vmwarevga
I am trying to use vmwarevga with Fedora 9 alpha as a guest. When I load X however with the vmware driver I get an error that no supported vmware SVGA II adapters were found. Is this a known issue? Mark Bidewell
Re: [Qemu-devel] [PATCH] boot a linux kernel from non-ide device
Glauber de Oliveira Costa wrote: Since it's now possible to use the -drive option, the test for something in the index 0 of the IDE bus is too restrictive. A better idea, IMHO, is to check if the user specified any bootable device, and only if not, fallback to the default, compatible behaviour of checking hda regardless of the presence of a boot=on arg. extboot isn't in upstream QEMU yet so this patch won't apply. Regards, Anthony LIguori
Re: [Qemu-devel] Qemu 0.9.1 vmwarevga
Hi, do you start qemu with --vmwarevga ? Laurent Le vendredi 08 février 2008 à 10:15 -0500, Mark Bidewell a écrit : I am trying to use vmwarevga with Fedora 9 alpha as a guest. When I load X however with the vmware driver I get an error that no supported vmware SVGA II adapters were found. Is this a known issue? Mark Bidewell -- - [EMAIL PROTECTED] -- La perfection est atteinte non quand il ne reste rien à ajouter mais quand il ne reste rien à enlever. Saint Exupéry
Re: [Qemu-devel] [PATCH] Better version.rc patch
Hi, On Fri, 8 Feb 2008, C.W. Betts wrote: This is a better patch to make qemu on Windows show info when you go into properties. It is _still_ a hassle to review your patch, since you did not inline it again. So I will comment without quoting any of your patch, which will leave others guessing as to what we're talking about. FILEVERSION and PRODUCTVERSION need to get a #define'd value, which you have to #define in ./configure in config-host.h, as I suggested already. Also, it seems as you have yet another line which is commented out, with a comment currently not working. I'd appreciate it if it was left out, or fixed. Hth, Dscho
[Qemu-devel] [PATCH] Better version.rc patch
This is a better patch to make qemu on Windows show info when you go into properties. versionrc.diff Description: Binary data
Re: [Qemu-devel] Kernel memory allocation debugging with Qemu
On 2/8/08, Paul Brook [EMAIL PROTECTED] wrote: The patch takes a half of the memory and slows down the system. I think Qemu could be used instead. A channel (IO/MMIO) is created between the memory allocator in target kernel and Qemu running in the host. Memory allocator tells the allocated area to Qemu using the channel. Qemu changes the physical memory mapping for the area to special memory that will report any reads before writes back to allocator. Writes change the memory back to standard RAM. The performance would be comparable to Qemu in general and host kernel + Qemu only take a few MB of the memory. The system would be directly usable for other OSes as well. The qemu implementation isn't actually any more space efficient than the in-kernel implementation. You still need the same amount of bookkeeping ram. In both cases it should be possible to reduce the overhead from 1/2 to 1/9 by using a bitmask rather than whole bytes. Qemu would not track all memory, only the regions that kmalloc() have given to other kernel that have not yet been written to. Performance is a less clear. A qemu implementation probably causes less relative slowdown than an in-kernel implementation. However it's still going to be significantly slower than normal qemu. Remember that any checked access is going to have to go through the slow case in the TLB lookup. Any optimizations that are applicable to one implementation can probably also be applied to the other. Again, we are not trapping all accesses. The fast case should be used for most kernel accesses and all of userland. Given qemu is significantly slower to start with, and depending on the overhead of taking the page fault, it might not end up much better overall. A KVM implementation would most likely be slower than the in-kernel. That said it may be an interesting thing to play with. In practice it's probably most useful to generate an interrupt and report back to the guest OS, rather than having qemu reports faults directly. The access could happen when the interrupts are disabled, so a buffer should be needed. The accesses could also be written to a block device seen by both Qemu and the kernel, or appear to arrive from a fake network device.
Re: [Qemu-devel] Kernel memory allocation debugging with Qemu
On Friday 08 February 2008, Blue Swirl wrote: On 2/8/08, Paul Brook [EMAIL PROTECTED] wrote: The patch takes a half of the memory and slows down the system. I think Qemu could be used instead. A channel (IO/MMIO) is created between the memory allocator in target kernel and Qemu running in the host. Memory allocator tells the allocated area to Qemu using the channel. Qemu changes the physical memory mapping for the area to special memory that will report any reads before writes back to allocator. Writes change the memory back to standard RAM. The performance would be comparable to Qemu in general and host kernel + Qemu only take a few MB of the memory. The system would be directly usable for other OSes as well. The qemu implementation isn't actually any more space efficient than the in-kernel implementation. You still need the same amount of bookkeeping ram. In both cases it should be possible to reduce the overhead from 1/2 to 1/9 by using a bitmask rather than whole bytes. Qemu would not track all memory, only the regions that kmalloc() have given to other kernel that have not yet been written to. Memory still has the be tracked after it has been written to. You can only stop tracking after the whole page has been written to, and there's no easy way to determine when that is. The kernel actually has better information about this because it can replace the clear/copy_page routines. If you're only trying to track things with page granularity then that's a much easier problem. Performance is a less clear. A qemu implementation probably causes less relative slowdown than an in-kernel implementation. However it's still going to be significantly slower than normal qemu. Remember that any checked access is going to have to go through the slow case in the TLB lookup. Any optimizations that are applicable to one implementation can probably also be applied to the other. Again, we are not trapping all accesses. The fast case should be used for most kernel accesses and all of userland. Ok. So all the accesses that the in-kernel implementation intercepts. That's obviously a significant number. If it wasn't then performance wouldn't matter. The number of accesses intercepted and amount of bookkeeping required should be the same in both cases. The only difference is the runtime overhead when an access in intercepted. qemu goes through the slow-path softmmu routines, the in kernel implementation takes a pagefault+singlestep. Paul
Re: [Qemu-devel] [PATCH] Better version.rc patch
Another patch. Thank you for your patience.
Index: Makefile.target
===
RCS file: /sources/qemu/qemu/Makefile.target,v
retrieving revision 1.244
diff -u -r1.244 Makefile.target
--- Makefile.target 3 Feb 2008 02:20:17 - 1.244
+++ Makefile.target 8 Feb 2008 22:48:27 -
@@ -638,6 +638,7 @@
ifdef CONFIG_WIN32
SDL_LIBS := $(filter-out -mwindows, $(SDL_LIBS)) -mconsole
+OBJS+=version.o
endif
# profiling code
@@ -654,6 +655,9 @@
%.o: %.c
$(CC) $(CPPFLAGS) $(CFLAGS) -c -o $@ $
+%.o: %.rc
+ windres -I. -c -o $ $@
+
%.o: %.S
$(CC) $(CPPFLAGS) -c -o $@ $
Index: configure
===
RCS file: /sources/qemu/qemu/configure,v
retrieving revision 1.187
diff -u -r1.187 configure
--- configure 3 Feb 2008 19:20:13 - 1.187
+++ configure 8 Feb 2008 22:48:30 -
@@ -1065,6 +1065,10 @@
echo # Automatically generated by configure - do not modify $config_mak
echo /* Automatically generated by configure - do not modify */
$config_h
+if test $mingw32 = yes ; then
+echo #define QEMU_FILEVERSION 0,9,1,0 $config_h
+echo #define QEMU_PRODUCTVERSION 0,9,1,0 $config_h
+fi
echo include ../config-host.mak $config_mak
echo #include \../config-host.h\ $config_h
0a1,22
#include config.h
1 VERSIONINFO
FILEVERSION QEMU_FILEVERSION
PRODUCTVERSION QEMU_PRODUCTVERSION
FILETYPE 0x1 //VFT_APP
{
BLOCK StringFileInfo
{
BLOCK 040904E4
{
VALUE FileDescription, Qemu System emulator, TARGET_ARCH
version
VALUE FileVersion, QEMU_VERSION
VALUE LegalCopyright, GNU General Public License
VALUE ProductName, Qemu
}
}
BLOCK VarFileInfo
{
VALUE Translation, 0x0409, 1252
}
}
- Original Message -
From: Johannes Schindelin [EMAIL PROTECTED]
To: C.W. Betts [EMAIL PROTECTED]
Cc: qemu-devel@nongnu.org
Sent: Friday, February 08, 2008 1:49 PM
Subject: Re: [Qemu-devel] [PATCH] Better version.rc patch
Hi,
On Fri, 8 Feb 2008, C.W. Betts wrote:
It is _still_ a hassle to review your patch, since you did not inline it
again.
Sorry. I'm new.
Also, it seems as you have yet another line which is commented out, with a
comment currently not working. I'd appreciate it if it was left out, or
fixed.
As I said, I'm new.
Hth,
Dscho
versionrc.diff
Description: Binary data
Re: [Qemu-devel] [PATCH] Windows: put version and file info into exe
Hi, On Thu, 7 Feb 2008, C.W. Betts wrote: This patch will make an .rc file that will put the version info as well as a brief discription of the app for Windows. It would have been easier to comment on the patch if you would have inlined it. diff -u -r1.187 configure --- configure 3 Feb 2008 19:20:13 - 1.187 +++ configure 7 Feb 2008 18:11:27 - @@ -677,7 +677,7 @@ if test $mingw32 = yes ; then if test -z $prefix ; then - prefix=/c/Program Files/Qemu + prefix=/c/Program\ Files/Qemu fi mansuffix= datasuffix= Why not go the full nine yards and use $PROGRAMFILES, being nice to non-English users? Besides, how is this change related to your subject? Is it even necessary? +echoVALUE \LegalCopyright\, \GNU Lesser General Public License\ $version_rc This is actively wrong: LICENSE states 1) QEMU as a whole is released under the GNU General Public License +#echoVALUE \ProductVersion\, \@[EMAIL PROTECTED] $version_rc You don't want that to be committed. Overall: would it not be nicer to have the version.rc file tracked, instead of written by configure? You'd only need to add a #define for the WINDOWS_VERSION (a la QEMU_VERSION) in config-host.h. Then use it in version.rc. TARGET_ARCH is already #defined in $target/config.h, and for the OriginalFilename, you could change the Makefile rule from + +%.o: %.rc + windres -c -o $ $@ to + +%.o: %.rc + windres -DORIGINAL_FILENAME=\$(QEMU_PROG)\ -c -o $ $@ Hth, Dscho
Re: [Qemu-devel] Kernel memory allocation debugging with Qemu
The patch takes a half of the memory and slows down the system. I think Qemu could be used instead. A channel (IO/MMIO) is created between the memory allocator in target kernel and Qemu running in the host. Memory allocator tells the allocated area to Qemu using the channel. Qemu changes the physical memory mapping for the area to special memory that will report any reads before writes back to allocator. Writes change the memory back to standard RAM. The performance would be comparable to Qemu in general and host kernel + Qemu only take a few MB of the memory. The system would be directly usable for other OSes as well. The qemu implementation isn't actually any more space efficient than the in-kernel implementation. You still need the same amount of bookkeeping ram. In both cases it should be possible to reduce the overhead from 1/2 to 1/9 by using a bitmask rather than whole bytes. Performance is a less clear. A qemu implementation probably causes less relative slowdown than an in-kernel implementation. However it's still going to be significantly slower than normal qemu. Remember that any checked access is going to have to go through the slow case in the TLB lookup. Any optimizations that are applicable to one implementation can probably also be applied to the other. Given qemu is significantly slower to start with, and depending on the overhead of taking the page fault, it might not end up much better overall. A KVM implementation would most likely be slower than the in-kernel. That said it may be an interesting thing to play with. In practice it's probably most useful to generate an interrupt and report back to the guest OS, rather than having qemu reports faults directly. Paul
Re: [Qemu-devel] [PATCH] Better version.rc patch
Hi,
On Fri, 8 Feb 2008, C.W. Betts wrote:
Index: configure
===
RCS file: /sources/qemu/qemu/configure,v
retrieving revision 1.187
diff -u -r1.187 configure
--- configure 3 Feb 2008 19:20:13 - 1.187
+++ configure 8 Feb 2008 22:48:30 -
@@ -1065,6 +1065,10 @@
echo # Automatically generated by configure - do not modify $config_mak
echo /* Automatically generated by configure - do not modify */ $config_h
+if test $mingw32 = yes ; then
+echo #define QEMU_FILEVERSION 0,9,1,0 $config_h
+echo #define QEMU_PRODUCTVERSION 0,9,1,0 $config_h
+fi
Well, that can go out of sync easily... why not something like
+echo #define QEMU_FILEVERSION $(tr . , VERSION),0 $config_h
Hmm?
0a1,22
#include config.h
1 VERSIONINFO
FILEVERSION QEMU_FILEVERSION
PRODUCTVERSION QEMU_PRODUCTVERSION
FILETYPE 0x1 //VFT_APP
{
BLOCK StringFileInfo
{
BLOCK 040904E4
{
VALUE FileDescription, Qemu System emulator, TARGET_ARCH version
VALUE FileVersion, QEMU_VERSION
VALUE LegalCopyright, GNU General Public License
VALUE ProductName, Qemu
}
}
BLOCK VarFileInfo
{
VALUE Translation, 0x0409, 1252
}
}
I see what you try to do, but I think this hunk lacks a proper diff header
creating the file. Something like
-- snip --
diff a/version.rc b/version.rc
--- /dev/null
+++ b/version.rc
-- snap --
Also, I see that you cut down the version.rc (for example,
OriginalFilename is lacking now)... what are the symptoms of this not
working?
Ciao,
Dscho
[Qemu-devel] Kernel memory allocation debugging with Qemu
On KernelTrap there is a story about Linux kernel memory allocation debugging patch that allows detection of reads from uninitialized memory (http://kerneltrap.org/Linux/Debugging_With_kmemcheck). The patch takes a half of the memory and slows down the system. I think Qemu could be used instead. A channel (IO/MMIO) is created between the memory allocator in target kernel and Qemu running in the host. Memory allocator tells the allocated area to Qemu using the channel. Qemu changes the physical memory mapping for the area to special memory that will report any reads before writes back to allocator. Writes change the memory back to standard RAM. The performance would be comparable to Qemu in general and host kernel + Qemu only take a few MB of the memory. The system would be directly usable for other OSes as well. Similar debugging tool could be used in user space too (instrumenting libc malloc/free), but that's probably reinventing Valgrind or other malloc checkers. The special memory could also report unaligned accesses even on target where this is normally not detected but not so efficient.
Re: [Qemu-devel] Qemu 0.9.1 vmwarevga
Lspci output: 00:00.0 Host bridge: Intel Corporation 440FX - 82441FX PMC [Natoma] (rev 02) 00:01.0 ISA bridge: Intel Corporation 82371SB PIIX3 ISA [Natoma/Triton II] 00:01.1 IDE interface: Intel Corporation 82371SB PIIX3 IDE [Natoma/Triton II] 00:01.3 Bridge: Intel Corporation 82371AB/EB/MB PIIX4 ACPI *00:02.0 VGA compatible controller: VMware Inc Abstract SVGA II Adapter* 00:03.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL-8029(AS) 00:04.0 Multimedia audio controller: Ensoniq ES1370 [AudioPCI] Error from log: (II) Loading /usr/lib64/xorg/modules//libvgahw.so (II) Module vgahw: vendor=X.Org Foundation compiled for 1.4.99.2, module version = 0.1.0 ABI class: X.Org Video Driver, version 4.0 (EE) VMWARE(0): No supported VMware SVGA found (read ID 0x). (II) UnloadModule: vmware (II) UnloadModule: vgahw (II) Unloading /usr/lib64/xorg/modules//libvgahw.so (EE) Screen(s) found, but none have a usable configuration. Mark Bidewell 2008/2/8 Laurent Vivier [EMAIL PROTECTED]: Only one dash, you're right. What do you have with lspci ? # lspci 00:00.0 Host bridge: Intel Corporation 440FX - 82441FX PMC [Natoma] (rev 02) 00:01.0 ISA bridge: Intel Corporation 82371SB PIIX3 ISA [Natoma/Triton II] 00:01.1 IDE interface: Intel Corporation 82371SB PIIX3 IDE [Natoma/Triton II] 00:01.3 Bridge: Intel Corporation 82371AB/EB/MB PIIX4 ACPI (rev 03) 00:02.0 VGA compatible controller: VMware Inc [VMware SVGA II] PCI Display Adapter 00:03.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL-8029(AS) Laurent Le vendredi 08 février 2008 à 11:01 -0500, Mark Bidewell a écrit : are there 2 dashes or just one? I did -vmwarevga not --vmwarevga On 2/8/08, Laurent Vivier [EMAIL PROTECTED] wrote: Hi, do you start qemu with --vmwarevga ? Laurent Le vendredi 08 février 2008 à 10:15 -0500, Mark Bidewell a écrit : I am trying to use vmwarevga with Fedora 9 alpha as a guest. When I load X however with the vmware driver I get an error that no supported vmware SVGA II adapters were found. Is this a known issue? Mark Bidewell -- - [EMAIL PROTECTED] -- La perfection est atteinte non quand il ne reste rien à ajouter mais quand il ne reste rien à enlever. Saint Exupéry -- - [EMAIL PROTECTED] -- La perfection est atteinte non quand il ne reste rien à ajouter mais quand il ne reste rien à enlever. Saint Exupéry
Re: [Qemu-devel] [PATCH] Better version.rc patch
On Friday 08 February 2008 17:20:41 Johannes Schindelin wrote: diff a/version.rc b/version.rc --- /dev/null +++ b/version.rc Is there some way to put easily separable windows-only files in a win32 subdirectory so the rest of us don't have to look at it? Rob -- One of my most productive days was throwing away 1000 lines of code. - Ken Thompson.
[Qemu-devel] Re: 2.6.24 says serial8250: too much work for irq4 a lot.
Here's a patch Peter Anvin wrote so the serial I/O doesn't flood the kernel.
Here's the thread on linux-kernel aboout it:
http://lkml.org/lkml/2008/2/5/401
Rob
On Thursday 07 February 2008 15:19:39 you wrote:
Rob Landley wrote:
Specifically, qemu isn't paravirtualized, it's fully virtualized. The
same kernel can run on real hardware just fine. (Sort of the point of
the project...)
I can yank the warning for the kernels I build (or set PASS_LIMIT to
999), but I'd rather not carry any more patches than I can avoid...
Patch attached, completely untested beyond compilation.
In particular:
- we should probably clear the burst counter when the interrupt
line goes from inactive to active.
- there probably should be a timer which clears the burst
counter.
However, I think I've covered most of the bases...
-hpa
diff --git a/hw/serial.c b/hw/serial.c
index b1bd0ff..c902792 100644
--- a/hw/serial.c
+++ b/hw/serial.c
@@ -73,6 +73,15 @@
#define UART_LSR_OE0x02/* Overrun error indicator */
#define UART_LSR_DR0x01/* Receiver data ready */
+/*
+ * It's common for an IRQ handler to keep reading the RBR until
+ * the LSR indicates that the FIFO is empty, expecting that the
+ * CPU is vastly faster than the serial line. This can cause
+ * overruns or error indications if the FIFO never empties, so
+ * give the target OS a breather every so often.
+ */
+#define MAX_BURST 512
+
struct SerialState {
uint16_t divider;
uint8_t rbr; /* receive register */
@@ -91,8 +100,14 @@ struct SerialState {
int last_break_enable;
target_phys_addr_t base;
int it_shift;
+int burst_len;
};
+static void serial_clear_burst(SerialState *s)
+{
+s-burst_len = 0;
+}
+
static void serial_update_irq(SerialState *s)
{
if ((s-lsr UART_LSR_DR) (s-ier UART_IER_RDI)) {
@@ -114,6 +129,8 @@ static void serial_update_parameters(SerialState *s)
int speed, parity, data_bits, stop_bits;
QEMUSerialSetParams ssp;
+serial_clear_burst(s);
+
if (s-lcr 0x08) {
if (s-lcr 0x10)
parity = 'E';
@@ -221,9 +238,12 @@ static uint32_t serial_ioport_read(void *opaque, uint32_t
addr)
ret = s-divider 0xff;
} else {
ret = s-rbr;
-s-lsr = ~(UART_LSR_DR | UART_LSR_BI);
-serial_update_irq(s);
-qemu_chr_accept_input(s-chr);
+ if (s-burst_len MAX_BURST) {
+ s-burst_len++;
+ s-lsr = ~(UART_LSR_DR | UART_LSR_BI);
+ serial_update_irq(s);
+ qemu_chr_accept_input(s-chr);
+ }
}
break;
case 1:
@@ -235,6 +255,7 @@ static uint32_t serial_ioport_read(void *opaque, uint32_t
addr)
break;
case 2:
ret = s-iir;
+ serial_clear_burst(s);
/* reset THR pending bit */
if ((ret 0x7) == UART_IIR_THRI)
s-thr_ipending = 0;
@@ -248,6 +269,10 @@ static uint32_t serial_ioport_read(void *opaque, uint32_t
addr)
break;
case 5:
ret = s-lsr;
+ if (s-burst_len = MAX_BURST)
+ ret = ~(UART_LSR_DR|UART_LSR_BI);
+ if (!(ret UART_LSR_DR))
+ serial_clear_burst(s);
break;
case 6:
if (s-mcr UART_MCR_LOOP) {
--
One of my most productive days was throwing away 1000 lines of code.
- Ken Thompson.
Git/SVN/CVS? was Re: [Qemu-devel] What does code_copy_enabled do?
On 2/8/08, Rob Landley [EMAIL PROTECTED] wrote: On Thursday 07 February 2008 21:52:33 Paul Brook wrote: On Friday 08 February 2008, Rob Landley wrote: Grepping through the source code, I can find 3 places where this global variable is set (it's initialized to a default value of 1, there's a no-code-copy command line option that sets it to zero, and then it shows up in the test suite once). What I can't find is any code ever actually checking or using the value put into this variable It got ripped out a while back. Any news on the possible cvs-svn migration? I'd submit a cleanup patch to rip out the remaining traces of code_copy_enabled, but the git mirror I follow (git://git.kernel.dk/data/git/qemu.git) hasn't updated in several days so I'm not actually sure it's still there in cvs. Just checked and http://savannah.nongnu.org/svn/?group=qemu isn't there either... How about git? I'd like to use git bisect. Would there be problems if it were possible to commit via more than one interface?
Re: [Qemu-devel] Re: 2.6.24 says serial8250: too much work for irq4 a lot.
On 2/9/08, Rob Landley [EMAIL PROTECTED] wrote: Here's a patch Peter Anvin wrote so the serial I/O doesn't flood the kernel. The patch looks OK, but the throttling should benefit all devices, as discussed here: http://lists.gnu.org/archive/html/qemu-devel/2007-12/msg00283.html
Re: [Qemu-devel] Re: 2.6.24 says serial8250: too much work for irq4 a lot.
Blue Swirl wrote: On 2/9/08, Rob Landley [EMAIL PROTECTED] wrote: Here's a patch Peter Anvin wrote so the serial I/O doesn't flood the kernel. The patch looks OK, but the throttling should benefit all devices, as discussed here: http://lists.gnu.org/archive/html/qemu-devel/2007-12/msg00283.html I strongly disagree with the sentiments in that post. This is not a matter of rate throttling, but simulated FIFO exhaustion -- they are NOT the same thing. Simulated FIFO exhaustion is functionally equivalent to making sure there are interrupt windows opened in an otherwise-too-long critical section; it doesn't constrain any particular flow rate, as it still permits another interrupt to immediately come in. If you look at the patch, there are no timing dependencies; the only parameter is the depth of the virtual queue. The exhaustion is completely controlled by target OS access patterns. -hpa
Re: [Qemu-devel] [PATCH] SCSI support for vmdk images
On Sunday 06 January 2008 16:13:26 Soren Hansen wrote: I just noticed this patch, I've had lying around for a while, but forgot to send here. What does this do that the patch back in september didn't? Rob -- One of my most productive days was throwing away 1000 lines of code. - Ken Thompson.
