Radim Krčmář writes:
> 2015-03-26 21:24+0300, Andrey Korolyov:
>> On Thu, Mar 26, 2015 at 8:40 PM, Radim Krčmář wrote:
>> > 2015-03-26 20:08+0300, Andrey Korolyov:
>> >> KVM internal error. Suberror: 2
>> >> extra data[0]: 80ef
>> >> extra data[1]: 8b0d
>> >
>> > Btw. does this part ever
On 03/26/2015 09:19 AM, Kevin Wolf wrote:
Am 25.03.2015 um 16:45 hat John Snow geschrieben:
On 03/25/2015 10:48 AM, Markus Armbruster wrote:
I just had another cc: to an address gotten from MAINTAINERS bounce with
"user unknown".
How do we weed out dead MAINTAINERS entries?
Automated sp
We're (Yocto Project) hit this often. We're building a root file system
and then using userspace qemu to run binaries inside it (such as fc-
cache). If a cyclic symlink appears in the rootfs, it blows up.
--
You received this bug notification because you are a member of qemu-
devel-ml, which is
On 26 March 2015 at 21:37, Ross Burton wrote:
> We're (Yocto Project) hit this often. We're building a root file system
> and then using userspace qemu to run binaries inside it (such as fc-
> cache). If a cyclic symlink appears in the rootfs, it blows up.
If you're actually building a rootfs t
The 'qemu coroutine ' GDB command prints the
backtrace for a CoroutineUContext. This is useful for peeking inside
yielded coroutines that are waiting for file descriptor events, timers,
etc.
For example:
$ gdb tests/test-coroutine
(gdb) b test_yield
(gdb) r
(gdb) b qemu_coroutine_enter
On Thu, 03/26 15:32, Wen Congyang wrote:
> On 03/26/2015 03:21 PM, Fam Zheng wrote:
> > On Wed, 03/25 17:36, Wen Congyang wrote:
> >> Signed-off-by: Wen Congyang
> >> Signed-off-by: zhanghailiang
> >> Signed-off-by: Gonglei
> >> ---
> >> block/nbd.c | 49
On Thu, 03/26 19:52, Alberto Garcia wrote:
> On Thu, Mar 26, 2015 at 07:24:54PM +0200, Alberto Garcia wrote:
>
> > - The creation/destruction of ThrottleTimers is now handled internally
> > when a BlockDriverState is added/removed from a group, since
> > there's not much point on keeping them
On 03/27/2015 09:06 AM, Fam Zheng wrote:
> On Thu, 03/26 15:32, Wen Congyang wrote:
>> On 03/26/2015 03:21 PM, Fam Zheng wrote:
>>> On Wed, 03/25 17:36, Wen Congyang wrote:
Signed-off-by: Wen Congyang
Signed-off-by: zhanghailiang
Signed-off-by: Gonglei
---
block/nbd.c |
On 2015/3/26 18:06, Ian Campbell wrote:
On Thu, 2015-03-26 at 08:53 +0800, Chen, Tiejun wrote:
Hrm, OK. I suppose we can live with autodetect and igd both meaning igd
and whoever adds a new type will have to remember to add a check for
qemu-trad then.
When we really have to introduce a new ty
> >> > --- a/arch_init.c
> >> > +++ b/arch_init.c
> >> > @@ -355,12 +355,33 @@ static DecompressParam *decomp_param;
> static
> >> > QemuThread *decompress_threads; static uint8_t
> >> *compressed_data_buf;
> >> >
> >> > +static int do_compress_ram_page(CompressParam *param);
> >> > +
> >> > stat
On 03/26/2015 05:42 PM, Nikunj A Dadhania wrote:
From PCIDevice there is no way to know if the device has a backing
vfio device.
sPAPR guests inherits the "ibm,loc-code" from the pci pass through
device in hypervisor. This helps in identifying the device if there is
any failures using this "ibm
On 03/26/2015 05:42 PM, Nikunj A Dadhania wrote:
Each hardware instance has a platform unique location code. The OF
device tree that describes a part of a hardware entity must include
the “ibm,loc-code” property with a value that represents the location
code for that hardware entity.
Introduce
On Thu, Mar 26, 2015 at 12:12:12PM +0530, Nikunj A Dadhania wrote:
> Each hardware instance has a platform unique location code. The OF
> device tree that describes a part of a hardware entity must include
> the “ibm,loc-code” property with a value that represents the location
> code for that hard
Has anyone tested whether this is still broken in 15.04?
** Also affects: libvirt (Ubuntu)
Importance: Undecided
Status: New
** No longer affects: libvirt (Ubuntu)
** Also affects: libvirt (Ubuntu)
Importance: Undecided
Status: New
** Changed in: libvirt (Ubuntu)
Importan
On 03/27/2015 02:28 PM, David Gibson wrote:
On Thu, Mar 26, 2015 at 12:12:12PM +0530, Nikunj A Dadhania wrote:
Each hardware instance has a platform unique location code. The OF
device tree that describes a part of a hardware entity must include
the “ibm,loc-code” property with a value that rep
On Thu, Mar 26, 2015 at 11:44:36AM +, Dr. David Alan Gilbert wrote:
> * David Gibson (da...@gibson.dropbear.id.au) wrote:
> > On Wed, Mar 25, 2015 at 04:40:11PM +, Dr. David Alan Gilbert wrote:
> > > * Dr. David Alan Gilbert (dgilb...@redhat.com) wrote:
> > > > * David Gibson (da...@gibson.
On Thu, Mar 26, 2015 at 04:33:28PM +, Dr. David Alan Gilbert wrote:
> (Only replying to some of the items in this mail - the others I'll get
> to another time).
>
> * David Gibson (da...@gibson.dropbear.id.au) wrote:
> > On Wed, Feb 25, 2015 at 04:51:40PM +, Dr. David Alan Gilbert (git)
>
Alexey Kardashevskiy writes:
> On 03/26/2015 05:42 PM, Nikunj A Dadhania wrote:
>> Each hardware instance has a platform unique location code. The OF
>> device tree that describes a part of a hardware entity must include
>> the “ibm,loc-code” property with a value that represents the location
>>
David Gibson writes:
> On Thu, Mar 26, 2015 at 12:12:12PM +0530, Nikunj A Dadhania wrote:
>> Each hardware instance has a platform unique location code. The OF
>> device tree that describes a part of a hardware entity must include
>> the “ibm,loc-code” property with a value that represents the l
The patchset adds a generic can_be_deleted callback to UserCreatableClass.
It prevents removing a usercreatable object if the callback returns false.
Backends could implement the callback if it shoudn't be removed while it's
in use.
Thank Peter Crosthwaite, Paolo Bonzini, Andreas Färber and Igor
showing a memory device whose memdev is removed leads an assert:
(qemu) object_add memory-backend-ram,id=ram0,size=128M
(qemu) device_add pc-dimm,id=d0,memdev=ram0
(qemu) object_del ram0
(qemu) info memory-devices
**
ERROR:qom/object.c:1274:object_get_canonical_path_component:\
If backends implement the can_be_deleted and it returns false,
Then the qmp_object_del won't delete the given backends.
Signed-off-by: Lin Ma
---
include/qom/object_interfaces.h | 14 ++
qmp.c | 5 +
qom/object_interfaces.c | 15 +++
On Thu, 03/26 18:38, Paolo Bonzini wrote:
> For now it only returns (1 << DIRTY_MEMORY_VGA) or 0, but this
> will change soon so adjust the callers.
>
> Listeners check for "any bit except migration", which is handled
> via the global start/stop listener callbacks. This in practice
> means VGA be
On Fri, Mar 27, 2015 at 10:04:27AM +0530, Nikunj A Dadhania wrote:
> David Gibson writes:
>
> > On Thu, Mar 26, 2015 at 12:12:12PM +0530, Nikunj A Dadhania wrote:
> >> Each hardware instance has a platform unique location code. The OF
> >> device tree that describes a part of a hardware entity m
On 27/03/2015 06:44, Fam Zheng wrote:
> Based on the commit log that said memory_region_is_logging() only returns 0 or
> (1 << DIRTY_MEMORY_VGA), the new code keeps the truth table. But I don't
> understand why is DIRTY_MEMORY_MIGRATION excluded here and below?
Because DIRTY_MEMORY_MIGRATION is
On Thu, Mar 26, 2015 at 04:35:01PM +1100, Gavin Shan wrote:
> The PCI device MSIx table is cleaned out in hardware after EEH PE
> reset. However, we still hold the stale MSIx entries in QEMU, which
> should be cleared accordingly. Otherwise, we will run into another
> (recursive) EEH error and the
On Thu, Mar 26, 2015 at 04:35:02PM +1100, Gavin Shan wrote:
> When rebooting the guest, some PEs might be in frozen state. The
> contained PCI devices won't work properly if their frozen states
> aren't cleared in time. One case running into this situation would
> be maximal EEH error times encount
On Thu, 03/26 18:38, Paolo Bonzini wrote:
> Most of the time, not all bitmaps have to be marked as dirty;
> do not do anything if the interesting ones are already dirty.
> Previously, any clean bitmap would have cause all the bitmaps to be
> marked dirty.
>
> In fact, unless running TCG most of th
Alexey Kardashevskiy writes:
>> diff --git a/hw/vfio/pci.c b/hw/vfio/pci.c
>> index 95d666e..dd97258 100644
>> --- a/hw/vfio/pci.c
>> +++ b/hw/vfio/pci.c
>> @@ -3319,6 +3319,24 @@ static void
>> vfio_unregister_req_notifier(VFIOPCIDevice *vdev)
>> vdev->req_enabled = false;
>> }
>>
>> +b
David Gibson writes:
> On Fri, Mar 27, 2015 at 10:04:27AM +0530, Nikunj A Dadhania wrote:
>> David Gibson writes:
>>
>> > On Thu, Mar 26, 2015 at 12:12:12PM +0530, Nikunj A Dadhania wrote:
>> >> Each hardware instance has a platform unique location code. The OF
>> >> device tree that describes
On Thu, 03/26 18:38, Paolo Bonzini wrote:
> From: Stefan Hajnoczi
>
> The new bitmap_test_and_clear_atomic() function clears a range and
> returns whether or not the bits were set.
>
> Signed-off-by: Stefan Hajnoczi
> Message-Id: <1417519399-3166-3-git-send-email-stefa...@redhat.com>
> [Test be
On 03/27/2015 05:21 PM, Nikunj A Dadhania wrote:
Alexey Kardashevskiy writes:
diff --git a/hw/vfio/pci.c b/hw/vfio/pci.c
index 95d666e..dd97258 100644
--- a/hw/vfio/pci.c
+++ b/hw/vfio/pci.c
@@ -3319,6 +3319,24 @@ static void vfio_unregister_req_notifier(VFIOPCIDevice
*vdev)
vdev->req_
201 - 232 of 232 matches
Mail list logo
