Re: [Qemu-devel] [PATCH] Let mouse_button monitor command accept coordinates

2010-02-23 Thread Markus Armbruster
Aurelien Jarno writes: > On Wed, Dec 09, 2009 at 12:07:50PM +0100, Soren Hansen wrote: >> The mouse_button monitor command currently results in a call like this: >> >> kbd_mouse_event(0, 0, 0, mouse_button_status); >> >> For a pointer in relative mode, this means a button gets pressed (or

[Qemu-devel] [PATCH] pcnet APROMWE bit location (retry)

2010-02-23 Thread Chris Kilgour
According to AMD document 21485D pp.141, APROMWE is bit 8 of BCR2. Signed-off-by: Christopher Kilgour --- diff --git a/hw/pcnet.c b/hw/pcnet.c index 44b5b31..f889898 100644 --- a/hw/pcnet.c +++ b/hw/pcnet.c @@ -1601,7 +1601,7 @@ static void pcnet_aprom_writeb(void *opaque, uint32_t addr, uint3

Re: [Qemu-devel] [PATCH] VirtIO Support for Memory Regions

2010-02-23 Thread Cam Macdonell
On Tue, Feb 23, 2010 at 2:05 PM, Anthony Liguori wrote: > Hi Cam, > > On 02/23/2010 02:52 PM, Cam Macdonell wrote: >> >> Support for passing memory regions via VirtIO to remove need for PCI >> support in the guest. >> >> Adds new vectors to VirtIO config space to pass memory regions similar >> to

[Qemu-devel] [PATCH] Guest Kernel Support for Virtio Memory Regions

2010-02-23 Thread Cam Macdonell
These are the kernel changes to support passing memory regions via VirtIO that was emailed earlier. This patch adds new "device_ops" to the VirtIO device which are "map" and "unmap". These operations are based on suggestions from Christian Borntraeger (but don't blame him for this patch) from the

Re: [Qemu-devel] Re: [PATCH-RFC 13/13] virtio-net: connect to vhost net backend

2010-02-23 Thread Michael S. Tsirkin
On Wed, Feb 24, 2010 at 03:14:25AM +, Paul Brook wrote: > > vnet_hdr is IMHO a really bad example to copy from. > > > > vnet_hdr leaks into the migration state via n->has_vnet_hdr. What this > > means is that if you want to migrate from -net tap -net nic,model=virtio > > to -net user -net nic

[Qemu-devel] Question about PCIe and MSI-X status in Qemu

2010-02-23 Thread Adnan Khaleel
Could one of the developers give a brief status of the current state of support for PCIe and MSI-X interrupts in Qemu. I'm trying to build a System-C device that I'd like to co-simulate with Qemu and have the ability to use the same software stack as well. The kernel modules rely on MSI-X interr

Re: [Qemu-devel] Re: [PATCH-RFC 13/13] virtio-net: connect to vhost net backend

2010-02-23 Thread Paul Brook
> vnet_hdr is IMHO a really bad example to copy from. > > vnet_hdr leaks into the migration state via n->has_vnet_hdr. What this > means is that if you want to migrate from -net tap -net nic,model=virtio > to -net user -net nic,model=virtio, it will fail. > > This is a hard problem to solve in q

Re: [Qemu-devel] Re: [RFC][PATCH] performance improvement for windows guests, running on top of virtio block device

2010-02-23 Thread Paul Brook
> Bottom halves are run at the very end of the event loop which means that > they're guaranteed to be the last thing run. idle bottom halves can be > rescheduled without causing an infinite loop and do not affect the > select timeout (which normal bottom halves do). Idle bottom halves (i.e. qemu_

Re: [Qemu-devel] [RFC] Don't send local debug output to stdout (was: pm_smbus: remove #ifdef DEBUG)

2010-02-23 Thread Paul Brook
> I suggest these steps: > > 1. Debug output to stdout is no longer accepted for new / modified code. > > 2. New or modified debug messages should go to stderr. I don't see this as a real improvement. Arguably these aren't errors, so stdout is where they should be going. If we're going to do

[Qemu-devel] Severe data corruption in QEMU under Mac OS X

2010-02-23 Thread Natalia Portillo
10% of saved PPMs are corrupted or empty, hard disk images are randomly corrupted. Tested under Mac OS X 10.6.1 (x86-64) and under Linux 2.6.31-gentoo-r1 (x86-64) using QEMU 0.12.2 (manually compiled both) No other program corrupts files (cp, Finder, Mail, TextEdit), neither they are corr

Re: [Qemu-devel] [PATCH 0/6] target-alpha: fpu qualifiers, round 2

2010-02-23 Thread Aurelien Jarno
On Mon, Jan 04, 2010 at 02:46:05PM -0800, Richard Henderson wrote: > I've split up the FPCR as requested by Aurelien. We no longer > set anything in FP_STATUS after the execution of the operation, > only copy data from FP_STATUS to some env->fpcr field. > > I have totally rewritten the patch to

Re: [Qemu-devel] [PATCH] Fix segfault with ram_size > 4095M without kvm

2010-02-23 Thread Ryan Harper
* Aurelien Jarno [2010-02-23 11:37]: > Ryan Harper a écrit : > > Currently, x86_64-softmmu qemu segfaults when trying to use > 4095M memsize. > > This patch adds a simple check and error message (much like the 2047 limit > > on > > 32-bit hosts) on ram_size in the control path after we determine

Re: [Qemu-devel] What is qemu-system-ppcemb for?

2010-02-23 Thread Nathan Froyd
On Tue, Feb 23, 2010 at 03:37:16PM -0600, Rob Landley wrote: > I've been building a powerpc4xx system image, but booting it under g3beige > because last I checked qemu doesn't emulate a 4xx processor? (It has a > bamboo > board, but only lets you use it under kvm...) This part is easy to answe

[Qemu-devel] What is qemu-system-ppcemb for?

2010-02-23 Thread Rob Landley
The qemu-system-ppcemb binary has the same -M and -cpu options as qemu-system- ppc. The default-configs/*.mak files are identical for ppc-softmmu.mak and ppcemb-softmmu.mak. The ppc-softmmu/config-target.mak matches the one in ppcemb-softmmu. The "config-target.mak" files differ, but just in t

Re: [Qemu-devel] [PATCH] Let mouse_button monitor command accept coordinates

2010-02-23 Thread Aurelien Jarno
On Wed, Dec 09, 2009 at 12:07:50PM +0100, Soren Hansen wrote: > The mouse_button monitor command currently results in a call like this: > > kbd_mouse_event(0, 0, 0, mouse_button_status); > > For a pointer in relative mode, this means a button gets pressed (or > or released) and nothing else.

Re: [Qemu-devel] [FOR 0.12 PATCH] Simplify qemu_realloc()

2010-02-23 Thread Aurelien Jarno
On Mon, Dec 14, 2009 at 10:48:05AM +0100, Markus Armbruster wrote: > No functional change. Bonus: looks just like qemu_malloc() now. > > Signed-off-by: Markus Armbruster > --- > I tagged this "FOR 0.12" because I think you might want to consider it > for 0.12, not because I think it must go into

[Qemu-devel] [PATCH] arm host: Fix linker warning (m68k targets)

2010-02-23 Thread Stefan Weil
Compilation of m68k-softmmu or m68k-linux-user on arm host (or cross compilation for arm) results in a linker warning: LINK m68k-softmmu/qemu-system-m68k m68k-dis.o: warning: definition of `floatformat_ieee_single_little' overriding common arm-dis.o: warning: common is here /usr/lib/gcc/arm-li

Re: [Qemu-devel] [PATCH] Fix segfault with ram_size > 4095M without kvm

2010-02-23 Thread Aurelien Jarno
On Tue, Feb 23, 2010 at 03:07:20PM -0600, Anthony Liguori wrote: > On 02/23/2010 02:30 PM, Alexander Graf wrote: > >On 23.02.2010, at 18:02, Aurelien Jarno wrote: > > > >>Ryan Harper a écrit : > >>>Currently, x86_64-softmmu qemu segfaults when trying to use> 4095M > >>>memsize. > >>>This patch ad

Re: [Qemu-devel] [PATCH] arm host: Fix linker warning (m68k targets)

2010-02-23 Thread Anthony Liguori
On 02/23/2010 12:42 PM, Stefan Weil wrote: I'd commit it myself if I had the rights, but I haven't. So the only think I can do is remind those who have... Please resubmit. I would expect an ARM host patch to be applied by Paul but if he's not available to, I'll keep it my queue to be app

Re: [Qemu-devel] [PATCH] VirtIO Support for Memory Regions

2010-02-23 Thread Anthony Liguori
On 02/23/2010 03:05 PM, Anthony Liguori wrote: Hi Cam, On 02/23/2010 02:52 PM, Cam Macdonell wrote: Support for passing memory regions via VirtIO to remove need for PCI support in the guest. Adds new vectors to VirtIO config space to pass memory regions similar to how virtqueues are passed. K

Re: [Qemu-devel] [PATCH] Fix segfault with ram_size > 4095M without kvm

2010-02-23 Thread Anthony Liguori
On 02/23/2010 02:30 PM, Alexander Graf wrote: On 23.02.2010, at 18:02, Aurelien Jarno wrote: Ryan Harper a écrit : Currently, x86_64-softmmu qemu segfaults when trying to use> 4095M memsize. This patch adds a simple check and error message (much like the 2047 limit on 32-bit hosts)

Re: [Qemu-devel] [PATCH] VirtIO Support for Memory Regions

2010-02-23 Thread Anthony Liguori
Hi Cam, On 02/23/2010 02:52 PM, Cam Macdonell wrote: Support for passing memory regions via VirtIO to remove need for PCI support in the guest. Adds new vectors to VirtIO config space to pass memory regions similar to how virtqueues are passed. Kernel patch is forthcoming that add device_ops t

[Qemu-devel] [PATCH] VirtIO Support for Memory Regions

2010-02-23 Thread Cam Macdonell
Support for passing memory regions via VirtIO to remove need for PCI support in the guest. Adds new vectors to VirtIO config space to pass memory regions similar to how virtqueues are passed. Kernel patch is forthcoming that add device_ops to access the memory regions. I have used this mechanism

Re: [Qemu-devel] [PATCH] Fix segfault with ram_size > 4095M without kvm

2010-02-23 Thread Alexander Graf
On 23.02.2010, at 18:02, Aurelien Jarno wrote: > Ryan Harper a écrit : >> Currently, x86_64-softmmu qemu segfaults when trying to use > 4095M memsize. >> This patch adds a simple check and error message (much like the 2047 limit on >> 32-bit hosts) on ram_size in the control path after we determi

[Qemu-devel] [PATCH] target-ppc: fix SPE evsplat* instructions

2010-02-23 Thread Nathan Froyd
The shifts in the gen_evsplat* functions were expecting rA to be masked, not extracted, and so used the wrong shift amounts to sign-extend or pad with zeroes. Signed-off-by: Nathan Froyd --- target-ppc/translate.c |4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) diff --git a/target

[Qemu-devel] [PATCH] target-ppc: fix SPE evcmp* instructions

2010-02-23 Thread Nathan Froyd
The CRF_{CH,CL,CH_OR_CL,CH_AND_CL} constants were all off by one bit position. Because of this, the SPE evcmp* family of instructions would store values in the result condition register that were also off by one bit position. Fixed by using the CRF_{LT,GT,EQ,SO} constants for the shift amounts.

Re: [Qemu-devel] [PATCH] target-mips: fix ROTR and DROTR by zero

2010-02-23 Thread Aurelien Jarno
On Sat, Feb 20, 2010 at 10:24:07AM -0800, Nathan Froyd wrote: > > Signed-off-by: Nathan Froyd Thanks applied. > --- > target-mips/translate.c |4 > 1 files changed, 4 insertions(+), 0 deletions(-) > > diff --git a/target-mips/translate.c b/target-mips/translate.c > index dfea6f6..de5

Re: [Qemu-devel] [PATCH] target-mips: fix CpU exception for coprocessor 0

2010-02-23 Thread Aurelien Jarno
On Sat, Feb 20, 2010 at 10:19:09AM -0800, Nathan Froyd wrote: > When we signal a CpU exception for coprocessor 0, we should indicate > that it's for coprocessor 0 instead of coprocessor 1. Thanks applied. > Signed-off-by: Nathan Froyd > --- > target-mips/translate.c |2 +- > 1 files changed

Re: [Qemu-devel] [PATCH] arm host: Fix linker warning (m68k targets)

2010-02-23 Thread Stefan Weil
Stefan Weil schrieb: > Stefan Weil schrieb: > >> Compilation of m68k-softmmu or m68k-linux-user on arm host >> (or cross compilation for arm) results in a linker warning: >> >> LINK m68k-softmmu/qemu-system-m68k >> m68k-dis.o: warning: definition of `floatformat_ieee_single_little' >> overriding

[Qemu-devel] Re: [PATCH] qcow2: Fix image creation regression

2010-02-23 Thread Juan Quintela
Kevin Wolf wrote: > When checking for errors, commit db89119d compares with the wrong values, > failing image creation even when there was no error. Additionally, if an > error has occured, we can't preallocate the image (it's likely broken). > > This unbreaks test 023 of qemu-iotests. > > Signed-

[Qemu-devel] [PATCH] declare saved_env_reg as volatile

2010-02-23 Thread Paolo Bonzini
This ensures that the compiler does not move it away from the "env = env1;" assignment. Fixes a miscompilation on gcc 4.4, reported by Jay Foad. Cc: Signed-off-by: Paolo Bonzini --- cpu-exec.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/cpu-exec.c b/cpu-exec.c ind

[Qemu-devel] Re: gcc 4.4 miscompiling cpu_exec() ?

2010-02-23 Thread Paolo Bonzini
On 02/23/2010 07:17 PM, Jay Foad wrote: Can you try this patch: It works! Thanks. and if it works, possibly only each hunk of it? Just the first hunk: works! Just the second hunk: doesn't work Can you explain why the volatile is necessary? Or is it working around a problem with the compile

[Qemu-devel] Re: gcc 4.4 miscompiling cpu_exec() ?

2010-02-23 Thread Jay Foad
> Can you try this patch: It works! Thanks. > and if it works, possibly only each hunk of it? Just the first hunk: works! Just the second hunk: doesn't work Can you explain why the volatile is necessary? Or is it working around a problem with the compiler? Thanks, Jay.

[Qemu-devel] Re: gcc 4.4 miscompiling cpu_exec() ?

2010-02-23 Thread Paolo Bonzini
On 02/23/2010 03:50 PM, Jay Foad wrote: I'm building QEMU mipsel-linux-user with Ubuntu's GCC 4.4 on an x86 host. Whenever I try to run a trivial MIPS executable, QEMU segfaults in cpu_loop() shortly after the call to cpu_mips_exec(). The problem seems to be that cpu_exec() doesn't preserve ebp.

Re: [Qemu-devel] gcc 4.4 miscompiling cpu_exec() ?

2010-02-23 Thread Jay Foad
On 23 February 2010 17:03, Aurelien Jarno wrote: > Jay Foad a écrit : >> I'm building QEMU mipsel-linux-user with Ubuntu's GCC 4.4 on an x86 >> host. Whenever I try to run a trivial MIPS executable, QEMU segfaults >> in cpu_loop() shortly after the call to cpu_mips_exec(). >> >> The problem seems

Re: [Qemu-devel] [PATCH] Fix qemu_eventfd compile when !CONFIG_EVENTFD

2010-02-23 Thread Blue Swirl
Thanks, applied. On 2/23/10, Paolo Bonzini wrote: > From: Avi Kivity > > Signed-off-by: Avi Kivity > Signed-off-by: Paolo Bonzini > --- > osdep.c |2 +- > 1 files changed, 1 insertions(+), 1 deletions(-) > > diff --git a/osdep.c b/osdep.c > index 3bab79a..4d39f2c 100644 > --- a/os

Re: [Qemu-devel] [PATCH] Fix segfault with ram_size > 4095M without kvm

2010-02-23 Thread Aurelien Jarno
Ryan Harper a écrit : > Currently, x86_64-softmmu qemu segfaults when trying to use > 4095M memsize. > This patch adds a simple check and error message (much like the 2047 limit on > 32-bit hosts) on ram_size in the control path after we determine we're > not using kvm > > Upstream qemu-kvm is aff

Re: [Qemu-devel] Address translation - virt->phys->ram

2010-02-23 Thread Anthony Liguori
On 02/22/2010 11:47 AM, Ian Molton wrote: Anthony Liguori wrote: On 02/22/2010 10:46 AM, Ian Molton wrote: Anthony Liguori wrote: cpu_physical_memory_map(). But this function has some subtle characteristics. It may return a bounce buffer if you attempt to map MMIO memory.

[Qemu-devel] Re: [PATCH v2 2/3] qcow2: Rewrite alloc_refcount_block/grow_refcount_table

2010-02-23 Thread Juan Quintela
Kevin Wolf wrote: > The current implementation of alloc_refcount_block and grow_refcount_table has > fundamental problems regarding error handling. There are some places where an > I/O error means that the image is going to be corrupted. I have found that the > only way to fix this is to completel

[Qemu-devel] Re: [PATCH v2 3/3] qcow2: More checks for qemu-img check

2010-02-23 Thread Juan Quintela
Kevin Wolf wrote: > Implement some more refcount block related checks > > Signed-off-by: Kevin Wolf > --- > block/qcow2-refcount.c | 12 > 1 files changed, 12 insertions(+), 0 deletions(-) Acked-by: Juan Quintela

[Qemu-devel] Re: [PATCH v2 1/3] qcow2: Factor next_refcount_table_size out

2010-02-23 Thread Juan Quintela
Kevin Wolf wrote: > When the refcount table grows, it doesn't only grow by one entry but reserves > some space for future refcount blocks. The algorithm to calculate the number > of > entries stays the same with the fixes, so factor it out before replacing the > rest. > > As Juan suggested take t

Re: [Qemu-devel] Address translation - virt->phys->ram

2010-02-23 Thread Alexander Graf
On 23.02.2010, at 16:46, Ian Molton wrote: > Alexander Graf wrote: > >> I guess what you really want is some shm region between host and guess >> that you can use as ring buffer. Then you could run a timer on the host >> side to flush it or have some sort of callback when you urgently need to >>

Re: [Qemu-devel] Address translation - virt->phys->ram

2010-02-23 Thread Ian Molton
Alexander Graf wrote: > I guess what you really want is some shm region between host and guess > that you can use as ring buffer. Then you could run a timer on the host > side to flush it or have some sort of callback when you urgently need to > flush it manually. > > The benefit here is that you

[Qemu-devel] [PATCH v2 3/3] qcow2: More checks for qemu-img check

2010-02-23 Thread Kevin Wolf
Implement some more refcount block related checks Signed-off-by: Kevin Wolf --- block/qcow2-refcount.c | 12 1 files changed, 12 insertions(+), 0 deletions(-) diff --git a/block/qcow2-refcount.c b/block/qcow2-refcount.c index f714ca2..917fc88 100644 --- a/block/qcow2-refcount.c +

[Qemu-devel] [PATCH v2 2/3] qcow2: Rewrite alloc_refcount_block/grow_refcount_table

2010-02-23 Thread Kevin Wolf
The current implementation of alloc_refcount_block and grow_refcount_table has fundamental problems regarding error handling. There are some places where an I/O error means that the image is going to be corrupted. I have found that the only way to fix this is to completely rewrite the thing. In de

[Qemu-devel] [PATCH v2 1/3] qcow2: Factor next_refcount_table_size out

2010-02-23 Thread Kevin Wolf
When the refcount table grows, it doesn't only grow by one entry but reserves some space for future refcount blocks. The algorithm to calculate the number of entries stays the same with the fixes, so factor it out before replacing the rest. As Juan suggested take the opportunity to simplify the co

[Qemu-devel] [PATCH v2 0/3] qcow2: Rewrite alloc_refcount_block

2010-02-23 Thread Kevin Wolf
The current implementation of alloc_refcount_block and grow_refcount_table has fundamental problems regarding error handling. There are some places where an I/O error means that the image is going to be corrupted. I have found that the only way to fix this is to completely rewrite the thing. v2: A

[Qemu-devel] [PATCH] Fix segfault with ram_size > 4095M without kvm

2010-02-23 Thread Ryan Harper
Currently, x86_64-softmmu qemu segfaults when trying to use > 4095M memsize. This patch adds a simple check and error message (much like the 2047 limit on 32-bit hosts) on ram_size in the control path after we determine we're not using kvm Upstream qemu-kvm is affected if using the -no-kvm option;

[Qemu-devel] [PATCH] qcow2: Fix image creation regression

2010-02-23 Thread Kevin Wolf
When checking for errors, commit db89119d compares with the wrong values, failing image creation even when there was no error. Additionally, if an error has occured, we can't preallocate the image (it's likely broken). This unbreaks test 023 of qemu-iotests. Signed-off-by: Kevin Wolf --- block/

[Qemu-devel] [PATCH 0/1] kvm stable updates for qemu 0.12.3

2010-02-23 Thread Avi Kivity
Just one patch, fixing eflags corruption. Also available from git: git://git.kernel.org/pub/scm/virt/kvm/qemu-kvm.git uq/stable-0.12 Please pull. Jan Kiszka (1): kvm: Fix eflags corruption in kvm mode cpu-exec.c | 12 +++- 1 files changed, 7 insertions(+), 5 deletions(-)

[Qemu-devel] [PATCH 1/1] kvm: Fix eflags corruption in kvm mode

2010-02-23 Thread Avi Kivity
From: Jan Kiszka This should explain a lot of the weird breakages of upstream KVM we've seen recently (actually we should have seen it much earlier): Stop translating eflags into TCG format when in kvm mode as we never translate it back and rather sync this broken state into the kernel. Signed-

[Qemu-devel] gcc 4.4 miscompiling cpu_exec() ?

2010-02-23 Thread Jay Foad
I'm building QEMU mipsel-linux-user with Ubuntu's GCC 4.4 on an x86 host. Whenever I try to run a trivial MIPS executable, QEMU segfaults in cpu_loop() shortly after the call to cpu_mips_exec(). The problem seems to be that cpu_exec() doesn't preserve ebp. It tries to: saved_env_reg = (host_r

[Qemu-devel] [PATCH][uq/master] KVM: Rework of guest debug state writing

2010-02-23 Thread Jan Kiszka
So far we synchronized any dirty VCPU state back into the kernel before updating the guest debug state. This was a tribute to a deficit in x86 kernels before KVM_CAP_X86_ROBUST_SINGLESTEP. But as this is an arch-dependent issue, it is better handle in the x86 part of KVM and remove the writeback po

Re: [Qemu-devel] [PATCH] QEMU e820 reservation patch

2010-02-23 Thread Gleb Natapov
On Tue, Feb 23, 2010 at 07:50:16AM -0600, Anthony Liguori wrote: > On 02/23/2010 02:22 AM, Gleb Natapov wrote: > >On Mon, Feb 22, 2010 at 08:31:00PM -0500, Kevin O'Connor wrote: > >>On Mon, Feb 22, 2010 at 10:33:12AM +0200, Gleb Natapov wrote: > >>>On Sun, Feb 21, 2010 at 02:13:51PM -0500, Kevin O'

Re: [Qemu-devel] [PATCH] QEMU e820 reservation patch

2010-02-23 Thread Anthony Liguori
On 02/23/2010 02:22 AM, Gleb Natapov wrote: On Mon, Feb 22, 2010 at 08:31:00PM -0500, Kevin O'Connor wrote: On Mon, Feb 22, 2010 at 10:33:12AM +0200, Gleb Natapov wrote: On Sun, Feb 21, 2010 at 02:13:51PM -0500, Kevin O'Connor wrote: Are you thinking of moving qemu more torwa

Re: [Qemu-devel] Re: [PATCH] Fix to 'gdb detach' stub

2010-02-23 Thread Kevin Wolf
Am 22.02.2010 22:22, schrieb Daniel Gutson: > [Re-done with git.] > With this patch, 'gdb detach' correctly resumes the inferior execution > after detaching the debugger. > The bug was caused by qemu asking gdb to execute a syscall (isatty) > after the detach, and then waiting (forever) for the r

[Qemu-devel] [PATCH] Fix qemu_eventfd compile when !CONFIG_EVENTFD

2010-02-23 Thread Paolo Bonzini
From: Avi Kivity Signed-off-by: Avi Kivity Signed-off-by: Paolo Bonzini --- osdep.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/osdep.c b/osdep.c index 3bab79a..4d39f2c 100644 --- a/osdep.c +++ b/osdep.c @@ -293,9 +293,9 @@ ssize_t qemu_write_full(int fd, const vo

Re: [Qemu-devel] [PATCH] QEMU e820 reservation patch

2010-02-23 Thread Gleb Natapov
On Mon, Feb 22, 2010 at 08:31:00PM -0500, Kevin O'Connor wrote: > On Mon, Feb 22, 2010 at 10:33:12AM +0200, Gleb Natapov wrote: > > On Sun, Feb 21, 2010 at 02:13:51PM -0500, Kevin O'Connor wrote: > > > Are you thinking of moving qemu more torwards what coreboot does, or > > > did you have a differe