Is there any benefit gained by porting 10Gb Ethernet adapters to
Qemu/KVM ? The question may be naive. Please forgive me if this doesn't
make any sense.
Regards,
Onkar
--
Your work is going to fill a large part of your
life, and the only way to be
Avi Kivity wrote:
On 08/06/2010 06:36 AM, Liu, Jinsong wrote:
Recently seabios implement vcpu hotplug infrastructure.
During test, we found qemu-kvm has a bug result in guestos shutdown
when vcpu hotadd. This patch is to fix the bug, mark
bus-allow_hotplug as 1 after qdev_hotplug init done.
On 08/18/2010 10:17 AM, Liu, Jinsong wrote:
During test, we found qemu-kvm has a bug result in guestos shutdown when vcpu
hotadd.
This patch is to fix the bug, allow hotplug for sysbus qdev.
--- a/hw/qdev.c
+++ b/hw/qdev.c
@@ -108,6 +108,7 @@ DeviceState *qdev_create(BusState *bus, const char
Replace tabs in arch_init.c and exec.c by spaces.
Yoshiaki Tamura (2):
arch_init: replace tabs by spaces.
exec: replace tabs by spaces.
arch_init.c | 12 ++--
exec.c | 56
2 files changed, 34 insertions(+), 34
Signed-off-by: Yoshiaki Tamura tamura.yoshi...@lab.ntt.co.jp
---
arch_init.c | 12 ++--
1 files changed, 6 insertions(+), 6 deletions(-)
diff --git a/arch_init.c b/arch_init.c
index 47bb4b2..1865ae5 100644
--- a/arch_init.c
+++ b/arch_init.c
@@ -82,12 +82,12 @@ const uint32_t arch_type
On Wed, Aug 18, 2010 at 12:25:26AM +0800, Haishan Bai wrote:
There is code indentation errors in my previous post, I am sorry for
that, please review this post.
The qemu-kvm could boot from SCSI disk image by utilizing seabios,
this patch ported codes
from qemu-kvm to let upstream qemu to
Signed-off-by: Yoshiaki Tamura tamura.yoshi...@lab.ntt.co.jp
---
exec.c | 56
1 files changed, 28 insertions(+), 28 deletions(-)
diff --git a/exec.c b/exec.c
index 8636316..4fc96cb 100644
--- a/exec.c
+++ b/exec.c
@@ -1706,8 +1706,8 @@
Since most of the code in qemu_ram_alloc() and
qemu_ram_alloc_from_ptr() are duplicated, let
qemu_ram_alloc_from_ptr() to switch by checking void *host, and change
qemu_ram_alloc() to a wrapper.
Signed-off-by: Yoshiaki Tamura tamura.yoshi...@lab.ntt.co.jp
---
exec.c | 84
Gleb Natapov wrote:
On Wed, Aug 18, 2010 at 12:25:26AM +0800, Haishan Bai wrote:
There is code indentation errors in my previous post, I am sorry for
that, please review this post.
The qemu-kvm could boot from SCSI disk image by utilizing seabios,
this patch ported codes
from qemu-kvm to
On Wed, Aug 18, 2010 at 04:01:41PM +0800, haishan wrote:
Gleb Natapov wrote:
On Wed, Aug 18, 2010 at 12:25:26AM +0800, Haishan Bai wrote:
There is code indentation errors in my previous post, I am sorry for
that, please review this post.
The qemu-kvm could boot from SCSI disk image by
On 08/17/2010 09:56 PM, Anthony Liguori wrote:
If Paolo's Win32 threads get merged, would there be other reasons
against continuing Win32 support?
I think a better question would be, should we even bother with thread
wrappers? If we drop win32 support, we can just assume pthreads and
avoid a
On 08/17/2010 08:39 PM, Richard Henderson wrote:
On 08/12/10 19:50, Blue Swirl wrote:
+While using bool is good for readability, it comes with minor caveats:
+ - Don't use bool in places where the type size must be constant across
+ all systems, like public interfaces and on-the-wire
Michael, I still think it's invalid; this particular bug in SDL fullscreen mode
is an SDL
bug, not a front-end bug.
--
implement true fullscreen
https://bugs.launchpad.net/bugs/613681
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
On 08/18/10 10:35, Paolo Bonzini wrote:
On 08/17/2010 08:39 PM, Richard Henderson wrote:
I'd strongly discourage the use of bool in any code.
I strongly disagree. The use of bool, even if you ignore stdbool.h
and do typedef int bool, is valuable documentation in the code.
I think bool is
On 17.08.2010, at 21:56, Anthony Liguori wrote:
On 08/17/2010 01:38 PM, Blue Swirl wrote:
But if the features aren't being used by anyone and they consistently don't
work, does it matter?
No, but semi-actively breaking things that work now is different from
removing obsolete or never
Hi,
I mean we can add them to libxc so that there is no need for this patch
anymore.
That would be great. When adding the xen bits initially I've tried to
avoid hard dependencies on specific xen versions. There are some ifdefs
in the qemu code to support compiling with various xen
Am 18.08.2010 10:35, schrieb Paolo Bonzini:
On 08/17/2010 08:39 PM, Richard Henderson wrote:
On 08/12/10 19:50, Blue Swirl wrote:
+While using bool is good for readability, it comes with minor caveats:
+ - Don't use bool in places where the type size must be constant across
+ all
On Wed, 18 Aug 2010, Gerd Hoffmann wrote:
Hi,
I mean we can add them to libxc so that there is no need for this patch
anymore.
That would be great. When adding the xen bits initially I've tried to
avoid hard dependencies on specific xen versions. There are some ifdefs
in the
I didn't read the whole thread; still, I see the issue this way:
1) it's good that QEMU developers decided to implement full screen mode;
2) it's good that QEMU developers decided not reinvent the wheel and to
use a library which is supposedly able to accomplish the task (SDL);
3) alas, full
On Wed, 2010-08-18 at 15:41 +0900, Yoshiaki Tamura wrote:
Since most of the code in qemu_ram_alloc() and
qemu_ram_alloc_from_ptr() are duplicated, let
qemu_ram_alloc_from_ptr() to switch by checking void *host, and change
qemu_ram_alloc() to a wrapper.
Signed-off-by: Yoshiaki Tamura
Tribal Speed New Click Here
Tribal Speed New Click Here
Tribal Speed New Click Here
Tribal Speed New Click Here
Tribal Speed New Click Here
Tribal Speed New Click Here
Tribal Speed New Click Here
Tribal Speed New Click Here
Tribal Speed New Click Here
Tribal Speed New Click Here
On 08/18/2010 12:30 PM, Kevin Wolf wrote:
Am 18.08.2010 10:35, schrieb Paolo Bonzini:
On 08/17/2010 08:39 PM, Richard Henderson wrote:
On 08/12/10 19:50, Blue Swirl wrote:
+While using bool is good for readability, it comes with minor caveats:
+ - Don't use bool in places where the type
If we save more than once we need to reset the last block info or else
only the first save has the actual block info and each subsequent save
will only use continue flags, making them unloadable independently.
Found-by: Miguel Di Ciurcio Filho miguel.fi...@gmail.com
Signed-off-by: Alex Williamson
The qemu-kvm could boot from SCSI disk image by utilizing seabios, this
patch ported codes
from qemu-kvm to let upstream qemu to support booting from SCSI disk image.
No. This has nothing to do with SCSI.
What it does is add a really cheap and nasty block storage device that aliases
one of
On 18.08.2010, at 17:08, Paul Brook wrote:
The qemu-kvm could boot from SCSI disk image by utilizing seabios, this
patch ported codes
from qemu-kvm to let upstream qemu to support booting from SCSI disk image.
No. This has nothing to do with SCSI.
What it does is add a really cheap and
On 08/18/2010 11:16 PM, Alexander Graf wrote:
On 18.08.2010, at 17:08, Paul Brook wrote:
The qemu-kvm could boot from SCSI disk image by utilizing seabios, this
patch ported codes
from qemu-kvm to let upstream qemu to support booting from SCSI disk image.
No. This has nothing to
On Wed, Aug 18, 2010 at 05:16:56PM +0200, Alexander Graf wrote:
On 18.08.2010, at 17:08, Paul Brook wrote:
The qemu-kvm could boot from SCSI disk image by utilizing seabios, this
patch ported codes
from qemu-kvm to let upstream qemu to support booting from SCSI disk image.
No. This
This has been discussed several times before. The proper solution is to
teach the bios how to boot off SCSI devices. IIRC support for virtio
devices already exists, implementing support for the SCSI controller
shouldn't be that much harder.
Couldn't we just have an option rom for the
Couldn't we just have an option rom for the SCSI controller? The same way
the VGABIOS is a rewrite of a VGA BIOS for the Cirrus Logic...
Of course we could, but it should not be extboot, but proper scsi driver.
gpxe has src/drivers/block/scsi.c so may be it already supports qemu scsi
Anthony, upstream virt-manager doesn't change the cache default, though
we do in RHEL.
Wasn't the idea of having an adaptive cache default for qemu given the
okay on qemu-devel, particularly for cache=none for block devs? or am I
imagining things (could be the case since I can't seem to find the
On 08/17/2010 11:09 AM, Jes Sorensen wrote:
On 08/12/10 19:50, Blue Swirl wrote:
+While using bool is good for readability, it comes with minor caveats:
+ - Don't use bool in places where the type size must be constant across
+ all systems, like public interfaces and on-the-wire protocols.
+
On 08/17/2010 10:15 PM, Jes Sorensen wrote:
I strongly disagree. The use of bool, even if you ignore stdbool.h
and do typedef int bool, is valuable documentation in the code.
I guess we have to agree to disagree then. IMHO it just masks the real
type and you end up with cases where people
On 08/18/2010 04:57 PM, Paolo Bonzini wrote:
On 08/18/2010 12:30 PM, Kevin Wolf wrote:
Am 18.08.2010 10:35, schrieb Paolo Bonzini:
On 08/17/2010 08:39 PM, Richard Henderson wrote:
On 08/12/10 19:50, Blue Swirl wrote:
+While using bool is good for readability, it comes with
minor
Hello Qemu developers,
I'm interested in developing a device model that plugs into Qemu that is based
on a PCIe interface and uses MSI-X. My goal is to ultimately attach a GPU
simulator to this PCIe interface and use the entire platfom (Qemu + GPU
simulator) for studying cpu, gpu interactions.
It is my job to make qemu-arm implement the SWPcc instruction
atomically. Currently, qemu implements this instruction as a load
followed by a store, in a way vulnerable to race conditions.
We are extending qemu to handle a high number of processors, and our
simple testcase using pthreads seems to
On Wed, Aug 18, 2010 at 12:15:09PM -0700, Peter W Schultz wrote:
How would I go about modifying the qemu source to implement SWP
atomically? I have been studying the source for a few days now, and I
am at a loss as to what all needs to be done.
You should look at how the load/store-exclusive
Hi,
Has anyone tried to use many Qemu devices/NICs at one time with the same
guest? Ie let the guest think it has say 3 or 4 virtual NICs? I see that
after about 2, it seems to be a little unstable - I got a em0 watchdog
timeout once.
So, I wanted to know is there any known issue with having
Free malloc'ed memory, unregister from savevm and clean up virtio-common
bits on device hot-unplug.
This was found performing a migration after device hot-unplug.
Reported-by: lihu...@redhat.com
Signed-off-by: Amit Shah amit.s...@redhat.com
---
hw/virtio-pci.c| 10 +-
On Tue, Aug 17, 2010 at 08:08:23PM -0400, Kevin O'Connor wrote:
On Fri, Jul 30, 2010 at 11:51:58AM +0900, Isaku Yamahata wrote:
add mcfg table.
mcfg isn't populated at the moment. dev-q35 will use it later.
This patch slipped through the cracks - sorry.
This patch doesn't seem to do
On Wed, Aug 18, 2010 at 02:10:10PM -0500, Adnan Khaleel wrote:
Hello Qemu developers,
I'm interested in developing a device model that plugs into Qemu that is based
on a PCIe interface and uses MSI-X. My goal is to ultimately attach a GPU
simulator to this PCIe interface and use the entire
If the machine is stopped and 'info balloon' is invoked, the monitor
process just hangs waiting for info from the guest. Return the most
recent balloon data in that case.
See https://bugzilla.redhat.com/show_bug.cgi?id=623903
Reported-by: lihu...@redhat.com
Signed-off-by: Amit Shah
Alexander Graf kindly shared with the wolrd the link[1] to an
informative article which among other things the article highlights
the fact that QEMU's emulation of exception handling on x86[_64] is
incorrect when the faulting instruction is RMW.
Here's small test case (__i386__ case is untested):
42 matches
Mail list logo
