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 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 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?
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 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
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
** 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
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
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
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
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 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 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 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, 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 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:
> 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, 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, 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 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?
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: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,
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
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
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
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
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: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.
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
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
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.
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 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
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, 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
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, 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 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 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
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 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 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
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 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:
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
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
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
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
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
> > >
> > >+/* 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
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
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
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
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
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
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
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
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
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
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
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
101 - 161 of 161 matches
Mail list logo
