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):
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:
Signed-off-by: Amit Shah
---
balloon.c | 18
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 entir
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 t
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:
Signed-off-by: Amit Shah
---
hw/virtio-pci.c| 10 +-
hw/virtio-serial-bus.c | 17 +
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 more
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
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
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.
On Wed, Aug 18, 2010 at 08:02:10AM -0600, Alex Williamson wrote:
> 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: Mig
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 caveat
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 peopl
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
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
t
> > 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
> > 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 f
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.
>
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 do
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 c
> 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
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
Signed-off-by: Alex Williamson
---
arch_init.c |
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 t
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 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
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 scree
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
> i
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
>
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 versio
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 obso
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.
>
>
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.
Sta
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 p
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 la
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
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 let
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
---
exec.c | 84 +++-
Signed-off-by: Yoshiaki Tamura
---
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 @@ static QLIST_HEAD(memory_client
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
Signed-off-by: Yoshiaki Tamura
---
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 = QEMU_ARCH;
/**
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 deletion
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
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 i
42 matches
Mail list logo
