Am 16.05.2012 07:53, schrieb Stefan Weil:
> Only the first 4 or 8 bytes were set to 0.
> This bug was found by cppcheck.
>
> Signed-off-by: Stefan Weil
This was already posted by Jim.
/-F
> ---
> hw/kvm/apic.c |2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/hw/kvm
Only the first 4 or 8 bytes were set to 0.
This bug was found by cppcheck.
Signed-off-by: Stefan Weil
---
hw/kvm/apic.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/hw/kvm/apic.c b/hw/kvm/apic.c
index ffe7a52..a0ab503 100644
--- a/hw/kvm/apic.c
+++ b/hw/kvm/apic.c
@@ -2
On Wed, May 16, 2012 at 02:35:38PM +1000, Benjamin Herrenschmidt wrote:
>
> > > >
> > > >+/* HACK: full memory barrier here */
> > > >+__sync_synchronize();
> > >
> > > I thought you were going to limit this to the TCE iommu?
> >
> > So, it wasn't my intention to send this one with the r
From: David Gibson
A while back, we introduced the dma_addr_t type, which is supposed to
be used for bus visible memory addresses. At present, this is an
alias for target_phys_addr_t, but this will change when we eventually
add support for guest visible IOMMUs.
There are some instances of targe
From: David Gibson
dma-helpers.c contains a number of helper functions for doing
scatter/gather DMA, and various block device related DMA. Currently,
these directly access guest memory using cpu_physical_memory_*(),
assuming no IOMMU translation.
This patch updates this code to use the new univ
From: David Gibson
The USB UHCI and EHCI drivers were converted some time ago to use the
pci_dma_*() helper functions. However, this conversion was not complete
because in some places both these drivers do DMA via the usb_packet_map()
function in usb-libhw.c. That function directly used
cpu_phy
From: David Gibson
Not that long ago, every device implementation using DMA directly
accessed guest memory using cpu_physical_memory_*(). This meant that
adding support for a guest visible IOMMU would require changing every
one of these devices to go through IOMMU translation.
Shortly before qe
From: David Gibson
This patch adds some hooks to let PCI devices and busses use the new IOMMU
infrastructure. When IOMMU support is enabled, each PCI device now
contains a DMAContext * which is used by the pci_dma_*() wrapper functions.
By default, the contexts are initialized to NULL, assuming
From: David Gibson
The AHCI device can provide both PCI and SysBus AHCI device
emulations. For this reason, it wasn't previously converted to use
the pci_dma_*() helper functions. Now that we have universal DMA
helper functions, this converts AHCI to use them.
The DMAContext is obtained from p
From: David Gibson
The pseries platform already contains an IOMMU implementation, since it is
essential for the platform's paravirtualized VIO devices. This IOMMU
support is currently built into the implementation of the VIO "bus" and
the various VIO devices.
This patch converts this code to ma
From: David Gibson
Currently the pseries machine emulation does not support DMA for emulated
PCI devices, because the PAPR spec always requires a (guest visible,
paravirtualized) IOMMU which was not implemented. Now that we have
infrastructure for IOMMU emulation, we can correct this and allow P
> > >
> > >+/* HACK: full memory barrier here */
> > >+__sync_synchronize();
> >
> > I thought you were going to limit this to the TCE iommu?
>
> So, it wasn't my intention to send this one with the rest, but I
> forgot to explain that to Ben when he resent. As the comment
> suggests, t
From: David Gibson
This patch adds the basic infrastructure necessary to emulate an IOMMU
visible to the guest. The DMAContext structure is extended with
information and a callback describing the translation, and the various
DMA functions used by devices will now perform IOMMU translation using
From: David Gibson
One new complication raised by IOMMU support over only handling DMA
directly to physical addresses is handling dma_memory_map() case
(replacing cpu_physical_memory_map()) when the IOMMU translation the
IOVAs covered by such a map are invalidated or changed while the map
is acti
From: David Gibson
The OHCI device emulation can provide both PCI and SysBus OHCI
implementations. Because of this, it was not previously converted to
use the PCI DMA helper functions.
This patch converts it to use the new universal DMA helper functions.
In the PCI case, it obtains its DMAConte
From: David Gibson
This patch adds cpu_physical_memory_set() function. This is equivalent to
calling cpu_physical_memory_write() with a buffer filled with a character,
ie, a memset of target memory.
It uses a small temporary buffer on the stack.
Signed-off-by: David Gibson
Signed-off-by: Benj
This is a resend of the iommu series, mostly from Eduard
and David with the following changes:
- Replaced the _zero functions with _set functions to
provide memset-like semantics and re-implemented in term
of cpu_physical_memory_rw() with a small local buffer
- Removed the tracking of maps, ins
Am 15.05.2012 18:19, schrieb Stefan Weil:
> Commit 93e9eb6808c886f5f1c903b7ced1eed65de2ba39 added fdc-test,
> but accidentally removed rtc-test because check-qtest-i386-y was
> not enhanced but set twice.
>
> This patch adds rtc-test again (and sorts both tests alphabetically).
>
> Signed-off-by:
Am 15.05.2012 18:08, schrieb Fabien Chouteau:
> On 05/15/2012 03:31 PM, Andreas Färber wrote:
>> Am 15.05.2012 11:39, schrieb Fabien Chouteau:
>>> Do not call cpu_dump_state if logfile is NULL.
>>
>> And where is log_cpu_state() being called from? Its caller is passing
>> NULL already then.
>>
>
>
Am 15.05.2012 19:22, schrieb Blue Swirl:
> On Mon, May 14, 2012 at 10:02 PM, Andreas Färber wrote:
>> Am 13.05.2012 23:04, schrieb Blue Swirl:
>>> A preview of x86 AREG0 patches can be found at the usual place:
>>> URL git://repo.or.cz/qemu/blueswirl.git
>>> http://repo.or.cz/r/qemu/bluesw
On Thu, May 10, 2012 at 06:02:52PM -0300, Jan Kiszka wrote:
> This patch basically adds kvm_irqchip_send_msi, a service for sending
> arbitrary MSI messages to KVM's in-kernel irqchip models.
>
> As the current KVI API requires us to establish a static route from a
> pseudo GSI to the target MSI m
Am 15.05.2012 22:33, schrieb Peter Maydell:
> On 15 May 2012 21:20, Anthony Liguori wrote:
>> [If it's] not tagged '1.1' than I am not considering it for 1.1.
>>
>> If it's tagged with 1.1 *and* in a subsystem with an active submaintainer, I
>> would expect the submaintainer to handle it. I do ke
On Tue, 2012-05-15 at 19:54 -0500, Anthony Liguori wrote:
>
> You certainly could do that but it may get a little weird dealing with the
> return path. You'd have to return something like -EWOULDBLOCK and make sure
> you
> handle that in the dispatch code appropriately.
Hrm, our implementatio
On 05/15/2012 07:41 PM, Benjamin Herrenschmidt wrote:
On Tue, 2012-05-15 at 18:58 -0500, Anthony Liguori wrote:
Even ancient PIO devices really don't block indefinitely.
In our case (TCEs) it's a hypervisor call, not an MMIO op, so to some
extent it's even more likely to do "blocking" things.
On Tue, 2012-05-15 at 18:58 -0500, Anthony Liguori wrote:
> Even ancient PIO devices really don't block indefinitely.
>
> > In our case (TCEs) it's a hypervisor call, not an MMIO op, so to some
> > extent it's even more likely to do "blocking" things.
>
> Yes, so I think the right thing to do is
On 05/15/2012 06:08 PM, Benjamin Herrenschmidt wrote:
On Tue, 2012-05-15 at 17:02 -0500, Anthony Liguori wrote:
"6.2.1 Register Based Invalidation Interface
The register based invalidations provides a synchronous hardware interface for
invalidations. Software is expected to write to the IOTLB
On Tue, May 15, 2012 at 11:06:05AM +0300, Gleb Natapov wrote:
> On Mon, May 14, 2012 at 09:43:19PM -0400, Kevin O'Connor wrote:
> > On Mon, May 14, 2012 at 03:35:23PM +0300, Gleb Natapov wrote:
> > > QEMU may want to disable guest's S3/S4 support and it wants to distinguish
> > > between regular po
There is no point in pushing this burden to the devices, they tend to
forget to call them (like intel-hda, ahci, xhci did). Instead, reset
functions are now called from pci_device_reset. They do nothing if
MSI/MSI-X is not in use.
CC: Alexander Graf
CC: Gerd Hoffmann
CC: Isaku Yamahata
Signed-o
On Tue, 2012-05-15 at 17:02 -0500, Anthony Liguori wrote:
>
> "6.2.1 Register Based Invalidation Interface
> The register based invalidations provides a synchronous hardware interface
> for
> invalidations. Software is expected to write to the IOTLB registers to
> submit
> invalidation comman
On 05/15/2012 04:55 PM, Benjamin Herrenschmidt wrote:
On Tue, 2012-05-15 at 09:02 -0500, Anthony Liguori wrote:
I think the crux of your argument is that upon a change to the translation
table, the operation acts as a barrier such that the exact moment it returns,
you're guaranteed that no DMAs
On Tue, 2012-05-15 at 09:02 -0500, Anthony Liguori wrote:
> I think the crux of your argument is that upon a change to the translation
> table, the operation acts as a barrier such that the exact moment it returns,
> you're guaranteed that no DMAs are in flight with the old translation mapping.
Sorry, I forgot to CC the maintainer.
Erik Rull wrote:
Keys for MS-Windows Keyboards (left / right Win Key, Context Key) were not
working in SDL / VNC environments, this patch fixes it.
Signed-off-by: Erik Rull
---
ui/x_keymap.c | 6 +++---
1 files changed, 3 insertions(+), 3 deletions(-)
diff
Riku,
Can you review/ack this patch?
Regards,
Anthony Liguori
On 05/15/2012 03:35 PM, Peter Maydell wrote:
Ping? This is 1.1 material in my opinion...
(patchwork url: http://patchwork.ozlabs.org/patch/158556/)
-- PMM
On 11 May 2012 17:25, Peter Maydell wrote:
On 11 May 2012 09:40, Alexa
On Tue, May 15, 2012 at 04:26:35PM +0100, Anthony PERARD wrote:
> In the context of PV-on-HVM under Xen, the emulated nics are supposed to be
> unplug before the guest drivers are initialized.
Guest drivers for which device?
> This mean that there must be unplug without the consent of the guest.
On Tue, May 15, 2012 at 04:26:39PM +0100, Anthony PERARD wrote:
> In the context of PV-on-HVM under Xen, the emulated nics are supposed to be
> unplug before the guest drivers are initialized. This mean that there must be
> unplug without the consent of the guest.
>
> Without this patch, the guest
On Tue, May 15, 2012 at 04:26:36PM +0100, Anthony PERARD wrote:
> This hotplug state will be used to remove a device without the guest
> cooperation.
>
> Signed-off-by: Anthony PERARD
This can crash guest, can't it? If you are fine with crashing guest,
we already let you do this:
- delete device
Hi,
Paolo Bonzini a écrit :
Il 15/05/2012 11:17, Li Zhi Hui ha scritto:
Signed-off-by: Paolo Bonzini
Signed-off-by: Li Zhi Hui
---
hw/fdc.c | 313 +
1 files changed, 210 insertions(+), 103 deletions(-)
To reviewers, this is obvio
Ping? This is 1.1 material in my opinion...
(patchwork url: http://patchwork.ozlabs.org/patch/158556/)
-- PMM
On 11 May 2012 17:25, Peter Maydell wrote:
> On 11 May 2012 09:40, Alexander Graf wrote:
>> If we execute linux-user code that does the following:
>>
>> * A = mmap()
>> * execute cod
On 15 May 2012 21:20, Anthony Liguori wrote:
> On 05/15/2012 11:42 AM, Peter Maydell wrote:
>> In this case it is a regression...
> At what point did it regress? I don't recall win64 ever working uner TCG...
Sorry, I had in mind the mmap thing, and got confused with what
I was quoting.
>> Anyw
On 05/15/2012 11:42 AM, Peter Maydell wrote:
On 15 May 2012 17:38, Anthony Liguori wrote:
Known issues == release blockers. I'm not willing to block a release for
uninitialized memory access unless it's be validated by a human (and if it
has, there probably will be a patch already).
Likewise,
Serge,
> I suspect this was meant to only affect the ubuntu qemu-kvm-spice (and
> related) packages,
> not upstream qemu, right?
I believe it's not a problem to verify.
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.
On 05/15/2012 11:50 AM, Fabien Chouteau wrote:
> On 05/15/2012 05:28 PM, Scott Wood wrote:
>> On 05/09/2012 05:54 AM, Fabien Chouteau wrote:
>>> On 05/07/2012 06:28 PM, Alexander Graf wrote:
Hi Fabien,
Could you please elaborate a bit on the case that broke for you with
these?
On Tue, May 15, 2012 at 7:19 PM, Stefano Stabellini
wrote:
>
> Given that it is supposed to be a state rather than an action, it should
> be called PCI_FORCE_DISABLED or something like that.
Ok, I will change to that.
Thanks,
--
Anthony PERARD
On Tue, May 15, 2012 at 7:15 PM, Stefano Stabellini
wrote:
> On Tue, 15 May 2012, Anthony PERARD wrote:
>> This function will be use to force a device to be ejected without the guest
>> cooperation.
>>
>> Signed-off-by: Anthony PERARD
>> ---
>> hw/qdev.c | 23 ---
>> hw/qde
On Tue, 15 May 2012, Anthony PERARD wrote:
> In the context of PV-on-HVM under Xen, the emulated nics are supposed to be
> unplug before the guest drivers are initialized. This mean that there must be
> unplug without the consent of the guest.
>
> Without this patch series, the guest end up with t
On Tue, 15 May 2012, Anthony PERARD wrote:
> This hotplug state will be used to remove a device without the guest
> cooperation.
>
> Signed-off-by: Anthony PERARD
> ---
> hw/acpi_piix4.c |5 +
> hw/pci.h|1 +
> 2 files changed, 6 insertions(+), 0 deletions(-)
>
> diff --git
On Tue, 15 May 2012, Anthony PERARD wrote:
> This function will be use to force a device to be ejected without the guest
> cooperation.
>
> Signed-off-by: Anthony PERARD
> ---
> hw/qdev.c | 23 ---
> hw/qdev.h |3 +++
> 2 files changed, 23 insertions(+), 3 deletions(-)
On 15 May 2012 17:45, Fabien Chouteau wrote:
> On 05/15/2012 06:20 PM, Peter Maydell wrote:
>> The question is which of the following two options we want:
>> (1) callers should be guarding the calls to log_cpu_state() with
>> checks for qemu_log_enabled() or qemu_loglevel_mask()
>> (2) log_cpu_sta
On Tue, May 15, 2012 at 5:27 PM, Peter Maydell wrote:
> On 14 May 2012 22:05, Blue Swirl wrote:
>> While working on the AREG0 patches, I noticed strange code in
>> target-i386/translate.c.
>
>> It's accessed like this (line 3537):
>> sse_op2 = sse_op_table3[(s->dflag == 2) * 2 + ((b >>
On 14 May 2012 22:05, Blue Swirl wrote:
> While working on the AREG0 patches, I noticed strange code in
> target-i386/translate.c.
> It's accessed like this (line 3537):
> sse_op2 = sse_op_table3[(s->dflag == 2) * 2 + ((b >> 8) - 2)];
>
> b >> 8 can be only either 1 or 0.
I don't thin
On Mon, May 14, 2012 at 10:02 PM, Andreas Färber wrote:
> Am 13.05.2012 23:04, schrieb Blue Swirl:
>> A preview of x86 AREG0 patches can be found at the usual place:
>> URL git://repo.or.cz/qemu/blueswirl.git
>> http://repo.or.cz/r/qemu/blueswirl.git
>
> It looks like that push has complet
On Mon, May 14, 2012 at 9:05 PM, Blue Swirl wrote:
> Hi,
>
> While working on the AREG0 patches, I noticed strange code in
> target-i386/translate.c.
>
> We have this table of function pointers:
> static void *sse_op_table3[4 * 3] = {
> gen_helper_cvtsi2ss,
> gen_helper_cvtsi2sd,
> X86_64
Thanks, Boris. I suspect this was meant to only affect the ubuntu qemu-
kvm-spice (and related) packages, not upstream qemu, right? If so I'll
mark as invalid for QEMU project.
I'll take a look at the debdiffs, and will talk to the debian
maintainers to see if they're willing to take these, and
Hi Anthony,
please pull:
git://xenbits.xen.org/people/sstabellini/qemu-dm.git for_1.1
it contains 3 fixes to xen_disk and 2 patches to disable rtc_clock,
the PIT and PCSPK on Xen:
Jan Beulich (1):
xen_disk: properly update stats in ioreq_release()
Stefano Stabellini (4):
xen: do n
** Also affects: qemu-kvm-spice (Ubuntu)
Importance: Undecided
Status: New
** Changed in: qemu-kvm-spice (Ubuntu)
Status: New => Confirmed
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bu
Am 15.05.2012 18:38, schrieb Anthony Liguori:
On 05/15/2012 11:33 AM, Stefan Weil wrote:
Am 15.05.2012 18:04, schrieb Anthony Liguori:
Hi,
On behalf of the QEMU Team, I'd like to announce the availability of
the
second release candidate for the QEMU 1.1 release. This release is
meant for
te
On 05/15/2012 05:28 PM, Scott Wood wrote:
> On 05/09/2012 05:54 AM, Fabien Chouteau wrote:
>> On 05/07/2012 06:28 PM, Alexander Graf wrote:
>>> Hi Fabien,
>>>
>>> Could you please elaborate a bit on the case that broke for you with these?
>>> The patches shouldn't change any guest facing behavior
Remove the MEM_VERBOSE tracing option from omap.h. This worked by
intercepting cpu_register_io_memory() calls; it has been broken
since cpu_register_io_memory() was removed in favour of the
MemoryRegion API.
Signed-off-by: Peter Maydell
---
The right place to implement this kind of intercepting t
On 05/15/2012 06:20 PM, Peter Maydell wrote:
> On 15 May 2012 17:08, Fabien Chouteau wrote:
>> On 05/15/2012 03:31 PM, Andreas Färber wrote:
>>> Am 15.05.2012 11:39, schrieb Fabien Chouteau:
Do not call cpu_dump_state if logfile is NULL.
>>>
>>> And where is log_cpu_state() being called from?
On Tue, 15 May 2012, Anthony Liguori wrote:
> On 05/15/2012 10:26 AM, Anthony PERARD wrote:
> > In the context of PV-on-HVM under Xen, the emulated nics are supposed to be
> > unplug before the guest drivers are initialized. This mean that there must
> > be
> > unplug without the consent of the gu
On 05/15/2012 11:37 AM, Andreas Färber wrote:
Am 15.05.2012 18:04, schrieb Anthony Liguori:
On behalf of the QEMU Team, I'd like to announce the availability of the
second release candidate for the QEMU 1.1 release. This release is
meant for testing purposes and should not be used in a producti
On 15 May 2012 17:38, Anthony Liguori wrote:
> Known issues == release blockers. I'm not willing to block a release for
> uninitialized memory access unless it's be validated by a human (and if it
> has, there probably will be a patch already).
>
> Likewise, memory leaks are not going to block th
On 05/15/2012 11:38 AM, Peter Maydell wrote:
On 15 May 2012 17:33, Stefan Weil wrote:
Am 15.05.2012 18:04, schrieb Anthony Liguori:
Known Issues:
- There appears to be a failure in make check on some platforms. This
will be resolved in -rc3.
Just for the record: there are a lot more kno
On 05/15/2012 11:33 AM, Stefan Weil wrote:
Am 15.05.2012 18:04, schrieb Anthony Liguori:
Hi,
On behalf of the QEMU Team, I'd like to announce the availability of the
second release candidate for the QEMU 1.1 release. This release is meant for
testing purposes and should not be used in a product
On 15 May 2012 17:33, Stefan Weil wrote:
> Am 15.05.2012 18:04, schrieb Anthony Liguori:
>> Known Issues:
>>
>> - There appears to be a failure in make check on some platforms. This
>> will be resolved in -rc3.
>>
>
> Just for the record: there are a lot more known issues.
> Here is a small extr
Am 15.05.2012 18:04, schrieb Anthony Liguori:
> On behalf of the QEMU Team, I'd like to announce the availability of the
> second release candidate for the QEMU 1.1 release. This release is
> meant for testing purposes and should not be used in a production
> environment.
>
> http://wiki.qemu.org
Am 15.05.2012 17:31, schrieb nicolas.sauzede:
> Sorry,
> What I meant was the IO handlers we can register, when initializing an
> io memory area :
>
> iomemtype = cpu_register_io_memory(tlm_qemu_readfn,
>tlm_qemu_writefn, s,
>
On 05/15/2012 10:31 AM, nicolas.sauzede wrote:
Sorry,
What I meant was the IO handlers we can register, when initializing an io
memory area :
iomemtype = cpu_register_io_memory(tlm_qemu_readfn,
tlm_qemu_writefn, s,
Am 15.05.2012 18:04, schrieb Anthony Liguori:
Hi,
On behalf of the QEMU Team, I'd like to announce the availability of
the second release candidate for the QEMU 1.1 release. This release
is meant for testing purposes and should not be used in a production
environment.
http://wiki.qemu.org/
On 15 May 2012 16:31, nicolas.sauzede wrote:
> What I meant was the IO handlers we can register, when initializing an io
> memory area :
>
> iomemtype = cpu_register_io_memory(tlm_qemu_readfn,
> tlm_qemu_writefn, s,
>
On Tue, 15 May 2012 09:14:13 -0500
Michael Roth wrote:
> On Tue, May 15, 2012 at 10:04:32AM -0300, Luiz Capitulino wrote:
> > On Mon, 14 May 2012 17:04:17 -0500
> > Michael Roth wrote:
> >
> > > Currently, if we fail to open the specified log file (generally due to a
> > > permissions issue), w
On 05/15/2012 10:26 AM, Anthony PERARD wrote:
In the context of PV-on-HVM under Xen, the emulated nics are supposed to be
unplug before the guest drivers are initialized. This mean that there must be
unplug without the consent of the guest.
Stefano,
Can you do a PULL for the various 1.1 fixes
Hi list,
I've implemented a way to link a qemu instance (arm) to a running TLM
simulation.
That allows me to use qemu-system-arm as a minimal ARM ISS without any hardware
device implemented within qemu,
all the peripherals are implemented in the TLM simulation.
This works by entering the TLM wor
On 15 May 2012 17:08, Fabien Chouteau wrote:
> On 05/15/2012 03:31 PM, Andreas Färber wrote:
>> Am 15.05.2012 11:39, schrieb Fabien Chouteau:
>>> Do not call cpu_dump_state if logfile is NULL.
>>
>> And where is log_cpu_state() being called from? Its caller is passing
>> NULL already then.
> No,
Commit 93e9eb6808c886f5f1c903b7ced1eed65de2ba39 added fdc-test,
but accidentally removed rtc-test because check-qtest-i386-y was
not enhanced but set twice.
This patch adds rtc-test again (and sorts both tests alphabetically).
Signed-off-by: Stefan Weil
---
tests/Makefile |2 +-
1 file chan
From: Luiz Capitulino
POSIX mandates[1] that a child process of a multi-thread program uses
only async-signal-safe functions before exec(). We consider qemu-ga
to be multi-thread, because it uses glib.
However, qmp_guest_shutdown() uses functions that are not
async-signal-safe. Fix it the follow
From: Luiz Capitulino
Today, qemu-ga may not be able to emit a success response when
guest-suspend-disk completes. This happens because the VM may
vanish before qemu-ga is able to emit a response.
This semantic is a bit confusing, as it's not clear for clients if
they should wait for a response
From: Luiz Capitulino
Today, qemu-ga may not be able to emit a success response when
guest-suspend-hybrid completes. This happens because the VM may
suspend before qemu-ga is able to emit a response.
This semantic is a bit confusing, as it's not clear for clients if
they should wait for a respon
Hi,
On behalf of the QEMU Team, I'd like to announce the availability of the second
release candidate for the QEMU 1.1 release. This release is meant for testing
purposes and should not be used in a production environment.
http://wiki.qemu.org/download/qemu-1.1.0-rc2.tar.bz2
You can help im
On 05/15/2012 03:31 PM, Andreas Färber wrote:
> Am 15.05.2012 11:39, schrieb Fabien Chouteau:
>> Do not call cpu_dump_state if logfile is NULL.
>
> And where is log_cpu_state() being called from? Its caller is passing
> NULL already then.
>
No, logfile is a global variable. log_cpu_state() takes
From: Luiz Capitulino
Options allow for changes in commands behavior. This commit introduces
the QCO_NO_SUCCESS_RESP option, which causes a command to not emit a
success response.
This is needed by commands such as qemu-ga's guest-shutdown, which
may not be able to complete before the VM vanishe
From: Luiz Capitulino
Currently, qemu-ga has a SIGCHLD handler that automatically reaps terminated
children processes. The idea is to avoid having qemu-ga commands blocked
waiting for children to terminate.
That approach has two problems:
1. qemu-ga is unable to detect errors in the child, mea
From: Luiz Capitulino
Today, qemu-ga may not be able to emit a success response when
guest-suspend-ram completes. This happens because the VM may
suspend before qemu-ga is able to emit a response.
This semantic is a bit confusing, as it's not clear for clients if
they should wait for a response
Sorry,
What I meant was the IO handlers we can register, when initializing an io
memory area :
iomemtype = cpu_register_io_memory(tlm_qemu_readfn,
tlm_qemu_writefn, s,
DEVICE_NATIVE_ENDIAN);
=> tlm_qemu_readfn is d
The following changes since commit 76ee152a86d5f2533443ce4d2be6fe253cfb3c45:
Update version to 1.1.0-rc2 (2012-05-14 17:56:50 -0500)
are available in the git repository at:
git://github.com/mdroth/qemu.git qga-pull-5-15-12
The bulk of these patches finish out the transition to making
guest-s
** Changed in: qemu
Status: New => Confirmed
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/998435
Title:
qemu-kvm-spice doesn't support spice/qxl installs
Status in QEMU:
Confirmed
Bug
It was fixed in latest qemu-kvm tree.
verified it against kvm + qemu-kvm: 331b646d..+ e54f008e..
** Changed in: qemu
Status: New => Fix Released
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/
Am 15.05.2012 13:24, schrieb Edgar E. Iglesias:
> On Tue, May 15, 2012 at 12:25:11AM +0400, Max Filippov wrote:
>> On Thu, May 10, 2012 at 4:10 AM, Andreas Färber wrote:
>>> Hello,
>>>
>>> Based on my CPUState patches for 1.1 (qom-cpu-1.1) this series kills off the
>>> cpu_state_reset() function,
On Thu, May 10, 2012 at 02:13:38AM +0200, Andreas Färber wrote:
> target-i386: Pass X86CPU to do_cpu_{init,sipi}()
> target-i386: Let cpu_x86_init() return X86CPU
> pc: Use cpu_x86_init() to obtain X86CPU
> pc: Pass X86CPU to pc_cpu_reset()
Reviewed-by: Igor Mammedov
Am 15.05.2012 15:19, schrieb Edgar E. Iglesias:
> On Tue, May 15, 2012 at 12:25:11AM +0400, Max Filippov wrote:
>> On Thu, May 10, 2012 at 4:10 AM, Andreas Färber wrote:
>>> Hello,
>>>
>>> Based on my CPUState patches for 1.1 (qom-cpu-1.1) this series kills off the
>>> cpu_state_reset() function,
Currently, if we fail to open the specified log file (generally due to a
permissions issue), we'll assign NULL to the logfile handle (stderr,
initially) used by the logging routines, which can cause a segfault to
occur when we attempt to report the error before exiting.
Instead, only re-assign if
On 05/09/2012 05:54 AM, Fabien Chouteau wrote:
> On 05/07/2012 06:28 PM, Alexander Graf wrote:
>> Hi Fabien,
>>
>> Could you please elaborate a bit on the case that broke for you with these?
>> The patches shouldn't change any guest facing behavior :o.
>>
>>
>
> My bad,
>
> The problem comes fro
From: Luiz Capitulino
Today, qemu-ga may not be able to emit a success response when
guest-shutdown completes. This happens because the VM may vanish
before qemu-ga is able to emit a response.
This semantic is a bit confusing, as it's not clear for clients if
they should wait for a response or h
Signed-off-by: Anthony PERARD
---
hw/pci.c | 15 +--
1 files changed, 13 insertions(+), 2 deletions(-)
diff --git a/hw/pci.c b/hw/pci.c
index b706e69..c58bbc1 100644
--- a/hw/pci.c
+++ b/hw/pci.c
@@ -1518,7 +1518,7 @@ static int pci_qdev_init(DeviceState *qdev)
return 0;
}
In the context of PV-on-HVM under Xen, the emulated nics are supposed to be
unplug before the guest drivers are initialized. This mean that there must be
unplug without the consent of the guest.
Without this patch, the guest end up with two nics with the same MAC, the
emulated nic and the PV nic.
This hotplug state will be used to remove a device without the guest
cooperation.
Signed-off-by: Anthony PERARD
---
hw/acpi_piix4.c |5 +
hw/pci.h|1 +
2 files changed, 6 insertions(+), 0 deletions(-)
diff --git a/hw/acpi_piix4.c b/hw/acpi_piix4.c
index 585da4e..dfd5a9d 1006
This function will be use to force a device to be ejected without the guest
cooperation.
Signed-off-by: Anthony PERARD
---
hw/qdev.c | 23 ---
hw/qdev.h |3 +++
2 files changed, 23 insertions(+), 3 deletions(-)
diff --git a/hw/qdev.c b/hw/qdev.c
index 6a8f6bd..c95d4c2
Am 15.05.2012 17:12, schrieb nicolas.sauzede:
> [...] when trying smp mode, I can't manage to retrieve the current env
> (ie: current smp processor number, registers, etc..),
> because it seems like the "cpu_single_env" variable is set to NULL
> explicitly in cpu-exec.c :
> /* fail safe : neve
In the context of PV-on-HVM under Xen, the emulated nics are supposed to be
unplug before the guest drivers are initialized. This mean that there must be
unplug without the consent of the guest.
Without this patch series, the guest end up with two nics with the same MAC,
the emulated nic and the P
From: Luiz Capitulino
This fixes a bug where qemu-ga doesn't suspend the guest because it
fails to detect suspend support even when the guest does support
suspend. This happens because of the way qemu-ga fds are managed in
daemon mode.
When starting qemu-ga with --daemon, become_daemon() will cl
1 - 100 of 161 matches
Mail list logo
