Thanks PMM,
I'm interested in hanging around and I don't mind going through the review
process - I expected having to some extra work.
How should I start? Break the work down into a set of patches and just
submit them to the list? If so how should I break them down? By
If anyone is interested the
On 07/03/2014 01:10 PM, Alexey Kardashevskiy wrote:
> c4177479 "spapr: make sure RMA is in first mode of first memory node"
> introduced regression which prevents from running guests with memoryless
> NUMA node#0 which may happen on real POWER8 boxes and which would make
> sense to debug in QEMU.
>
** Summary changed:
- Ctrl + Alt + 1/2 do not work when the GTK+ interface is used
+ Empty input is unacceptable!
** Project changed: qemu => ubuntu
** Summary changed:
- Empty input is unacceptable!
+ delete
--
You received this bug notification because you are a member of qemu-
devel-ml, wh
From: Benjamin Herrenschmidt
A subsequent patch to ppc/spapr needs to load the RTAS blob into
qemu memory rather than target memory (so it can later be copied
into the right spot at machine reset time).
I would use load_image() but it is marked deprecated because it
doesn't take a buffer size as
At the moment RTAS and device tree are located at 256MB max
which leaves too little space for huge initramdisk images and kernels.
This relaxes the limitation.
This is checkpatch.pl'ed version of:
[PATCH 1/2] loader: Add load_image_size() to replace load_image()
[PATCH 2/2] ppc/spapr: Locate RTAS
From: Benjamin Herrenschmidt
We currently calculate the final RTAS and FDT location based on
the early estimate of the RMA size, cropped to 256M on KVM since
we only know the real RMA size at reset time which happens much
later in the boot process.
This means the FDT and RTAS end up right below
On Fri, Jul 18, 2014 at 03:35:57PM +0200, Paolo Bonzini wrote:
> Il 17/07/2014 13:50, Liu Yuan ha scritto:
> > - allow drive-mirror to create sprase mirror on images like qcow2
> > - allow qemu-img map to work as expected on quorum driver
> >
> > Cc: Benoit Canet
> > Cc: Kevin Wolf
> > Cc: Stefa
On 2014-07-20 23:03, Michael S. Tsirkin wrote:
> On Sun, Jul 20, 2014 at 11:45:10PM +0200, Jan Kiszka wrote:
>> On 2014-07-20 21:48, Michael S. Tsirkin wrote:
>>> On Sat, Jul 19, 2014 at 06:55:48PM +0200, Jan Kiszka wrote:
From: Jan Kiszka
The spec says (and real HW confirms this) t
On Sun, Jul 20, 2014 at 11:45:10PM +0200, Jan Kiszka wrote:
> On 2014-07-20 21:48, Michael S. Tsirkin wrote:
> > On Sat, Jul 19, 2014 at 06:55:48PM +0200, Jan Kiszka wrote:
> >> From: Jan Kiszka
> >>
> >> The spec says (and real HW confirms this) that, if the bus master bit
> >> is 0, the device w
On 2014-07-20 21:48, Michael S. Tsirkin wrote:
> On Sat, Jul 19, 2014 at 06:55:48PM +0200, Jan Kiszka wrote:
>> From: Jan Kiszka
>>
>> The spec says (and real HW confirms this) that, if the bus master bit
>> is 0, the device will not generate any PCI accesses. MSI and MSI-X
>> messages fall among
On Sat, Jul 19, 2014 at 06:55:48PM +0200, Jan Kiszka wrote:
> From: Jan Kiszka
>
> The spec says (and real HW confirms this) that, if the bus master bit
> is 0, the device will not generate any PCI accesses. MSI and MSI-X
> messages fall among these.
>
> Signed-off-by: Jan Kiszka
I guess an al
When using ivshmem devices, notifications between guests can be sent as
interrupts using a ivshmem-server (typical use described in documentation).
The client is provided as a debug tool.
Signed-off-by: Olivier Matz
Signed-off-by: David Marchand
---
contrib/ivshmem-client/Makefile | 2
Add some notes on the parts needed to use ivshmem devices: more specifically,
explain the purpose of an ivshmem server and the basic concept to use the
ivshmem devices in guests.
Move some parts of the documentation and re-organise it.
Signed-off-by: David Marchand
---
docs/specs/ivshmem_device_
Here is a patchset containing an update on ivshmem specs documentation and
importing ivshmem server and client tools.
These tools have been written from scratch and are not related to what is
available in nahanni repository.
I put them in contrib/ directory as the qemu-doc.texi was already telling
On 07/20/2014 03:29 PM, Jan Kiszka wrote:
> On 2014-07-19 03:21, Chen Gang wrote:
>> If kvm_arch_remove_sw_breakpoint() in CPU_FOREACH() always be fail, it
>> will let 'cpu' NULL. And the next kvm_arch_remove_sw_breakpoint() in
>> QTAILQ_FOREACH_SAFE() will get NULL parameter for 'cpu'.
>>
>> And k
On 2014-07-19 03:21, Chen Gang wrote:
> If kvm_arch_remove_sw_breakpoint() in CPU_FOREACH() always be fail, it
> will let 'cpu' NULL. And the next kvm_arch_remove_sw_breakpoint() in
> QTAILQ_FOREACH_SAFE() will get NULL parameter for 'cpu'.
>
> And kvm_arch_remove_sw_breakpoint() can assumes 'cpu'
16 matches
Mail list logo
