Il 03/10/2012 23:35, Luiz Capitulino ha scritto:
> Also allow users to change the default at configure time. Please, check
> individual patches for more details.
>
> o v2
>
> - drop --guest-agent-statedir in favor of --localstatedir
> - change default from /var/run to ${prefix}/var/run
>
> Lui
Il 04/10/2012 05:49, Lucas Meneghel Rodrigues ha scritto:
> Add a test device which supports the kvmctl ioports,
> so one can run the KVM unittest suite [1].
>
> Usage:
>
> qemu -device testdev
>
> 1) Removed port 0xf1, since now kvm-unit-tests use
>serial
>
> 2) Removed exit code port 0xf4
Il 04/10/2012 08:53, Igor Mammedov ha scritto:
> IMHO from general POV it's not correct to set properties before object is
> completely created.
> But Anthony wants to keep qdev_prop_set_globals() qdev only thing, so could
> we move it from device_initfn() to qdev_init() or some other place then?
From: Christian Borntraeger
Newer kernels provide the guest registers in kvm_run. Lets use
those if available (i.e. the capability is set). This avoids
ioctls on cpu_synchronize_state making intercepts faster.
In addition, we have now the prefix register, the access registers
the control registe
On 4 October 2012 04:49, Lucas Meneghel Rodrigues wrote:
> Add a test device which supports the kvmctl ioports,
> so one can run the KVM unittest suite [1].
>
> Usage:
>
> qemu -device testdev
>
> 1) Removed port 0xf1, since now kvm-unit-tests use
>serial
>
> 2) Removed exit code port 0xf4, si
Il 04/10/2012 10:02, Peter Maydell ha scritto:
> On 4 October 2012 04:49, Lucas Meneghel Rodrigues wrote:
>> Add a test device which supports the kvmctl ioports,
>> so one can run the KVM unittest suite [1].
>>
>> Usage:
>>
>> qemu -device testdev
>>
>> 1) Removed port 0xf1, since now kvm-unit-tes
On 03/10/12 18:04, Avi Kivity wrote:
> use cpu_physical_memory_is_io() instead.
>
> Signed-off-by: Avi Kivity
> ---
> target-s390x/misc_helper.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/target-s390x/misc_helper.c b/target-s390x/misc_helper.c
> index e9b3cae..2da4
Il 03/10/2012 18:03, Avi Kivity ha scritto:
> Most of the work on the memory API focused on memory access targets - the
> memory regions
> and how they are composed into an address space. This patchset tackles the
> initator
> side of the question - how to originate accesses.
>
> The AddressSpa
On 4 October 2012 07:38, Avi Kivity wrote:
> On 10/03/2012 10:24 PM, Blue Swirl wrote:
>> >
>> > #else
>> > -void cpu_physical_memory_rw(target_phys_addr_t addr, uint8_t *buf,
>> > -int len, int is_write)
>> > +
>> > +void address_space_rw(AddressSpace *as, target_phys
On 2012-10-03 20:26, Marcelo Tosatti wrote:
> On Wed, Oct 03, 2012 at 07:24:48PM +0200, Jan Kiszka wrote:
>> On 2012-10-03 19:16, Anthony Liguori wrote:
>>> Jan Kiszka writes:
>>>
On 2012-10-03 17:03, Marcelo Tosatti wrote:
> On Wed, Oct 03, 2012 at 09:40:17AM -0500, Anthony Liguori wrote
use cpu_physical_memory_is_io() instead.
Signed-off-by: Avi Kivity
---
v2: drop unnecessary #include
target-s390x/misc_helper.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/target-s390x/misc_helper.c b/target-s390x/misc_helper.c
index e9b3cae..fdccd58 100644
--- a/targ
Il 03/10/2012 19:57, Søren Sandmann ha scritto:
> From: Søren Sandmann Pedersen
>
> When spice-server is newer than 0.12.0, the default revision should be
> QXL_REVISION_STABLE_V12.
>
> Signed-off-by: Soren Sandmann
> ---
> hw/qxl.h |3 +--
> 1 files changed, 1 insertions(+), 2 deletions(-
The hassle and compile time overhead of maintaining both 32-bit and 64-bit
capable source isn't worth the tiny performance advantage which is seen on
a minority of configurations. Switch to compiling libhw only once, with
target_phys_addr_t unconditionally typedefed to uint64_t.
Signed-off-by: Av
On 10/04/2012 10:47 AM, Peter Maydell wrote:
>>> I'd make address_space_* use uint64_t instead of target_phys_addr_t
>>> for the address. It may actually be buggy for 32 bit
>>> target_phys_addr_t and 64 bit DMA addresses, if such architectures
>>> exist. Maybe memory.c could be made target indepe
On 10/03/2012 10:16 PM, Blue Swirl wrote:
>> @@ -141,7 +141,7 @@ static bool memory_listener_match(MemoryListener
>> *listener,
>> #define MEMORY_LISTENER_UPDATE_REGION(fr, as, dir, callback)\
>> MEMORY_LISTENER_CALL(callback, dir, (&(MemoryRegionSection) { \
>> .m
On Wed, Oct 03, 2012 at 06:03:50PM +0200, Avi Kivity wrote:
> Instead of embedding knowledge of the memory and I/O address spaces in the
> memory core, maintain a list of all address spaces. This list will later
> be extended dynamically for other but masters.
^
On 10/03/2012 10:26 PM, Blue Swirl wrote:
> On Wed, Oct 3, 2012 at 4:03 PM, Avi Kivity wrote:
>> Most of the work on the memory API focused on memory access targets - the
>> memory regions
>> and how they are composed into an address space. This patchset tackles the
>> initator
>> side of the q
On 10/04/2012 12:17 PM, Gleb Natapov wrote:
> On Wed, Oct 03, 2012 at 06:03:50PM +0200, Avi Kivity wrote:
>> Instead of embedding knowledge of the memory and I/O address spaces in the
>> memory core, maintain a list of all address spaces. This list will later
>> be extended dynamically for other b
On 04.10.2012 14:07, Avi Kivity wrote:
> The hassle and compile time overhead of maintaining both 32-bit and 64-bit
> capable source isn't worth the tiny performance advantage which is seen on
> a minority of configurations. Switch to compiling libhw only once, with
> target_phys_addr_t unconditio
On 4 October 2012 11:23, Michael Tokarev wrote:
> On 04.10.2012 14:07, Avi Kivity wrote:
>> The hassle and compile time overhead of maintaining both 32-bit and 64-bit
>> capable source isn't worth the tiny performance advantage which is seen on
>> a minority of configurations. Switch to compiling
On 4 October 2012 11:15, Avi Kivity wrote:
> On 10/04/2012 10:47 AM, Peter Maydell wrote:
>> I'd favour just moving everything to 64 bits (the remaining
>> 32 bit targets are: cris, lm32, m68k, microblaze, or32, sh4, unicore32,
>> xtensa). However it does require some review of devices to check th
On 10/04/2012 12:29 PM, Peter Maydell wrote:
> On 4 October 2012 11:15, Avi Kivity wrote:
>> On 10/04/2012 10:47 AM, Peter Maydell wrote:
>>> I'd favour just moving everything to 64 bits (the remaining
>>> 32 bit targets are: cris, lm32, m68k, microblaze, or32, sh4, unicore32,
>>> xtensa). However
The hassle and compile time overhead of maintaining both 32-bit and 64-bit
capable source isn't worth the tiny performance advantage which is seen on
a minority of configurations. Switch to compiling libhw only once, with
target_phys_addr_t unconditionally typedefed to uint64_t.
Signed-off-by: Av
On Thu, Oct 04, 2012 at 12:36:04PM +0200, Avi Kivity wrote:
> The hassle and compile time overhead of maintaining both 32-bit and 64-bit
> capable source isn't worth the tiny performance advantage which is seen on
> a minority of configurations. Switch to compiling libhw only once, with
> target_p
On 2012-10-03 15:19, Paolo Bonzini wrote:
> Il 03/10/2012 12:57, Lucas Meneghel Rodrigues ha scritto:
>> Yep, I did send patches with the testdev device present on qemu-kvm.git
>> to qemu.git a while ago, but there were many comments on the review, I
>> ended up not implementing everything that was
On Thu, Oct 04, 2012 at 04:25:28PM +0530, Avik Sil wrote:
> On 09/27/2012 03:21 PM, Gleb Natapov wrote:
> >On Thu, Sep 27, 2012 at 11:33:31AM +0200, Alexander Graf wrote:
> >>
> >>On 27.09.2012, at 11:29, Benjamin Herrenschmidt wrote:
> >>
> >>>On Thu, 2012-09-27 at 14:51 +0530, Avik Sil wrote:
> >
On 04.10.2012, at 13:29, Avik Sil wrote:
> On 10/04/2012 04:52 PM, Gleb Natapov wrote:
>> On Thu, Oct 04, 2012 at 04:25:28PM +0530, Avik Sil wrote:
>>> On 09/27/2012 03:21 PM, Gleb Natapov wrote:
On Thu, Sep 27, 2012 at 11:33:31AM +0200, Alexander Graf wrote:
>
> On 27.09.2012, at 1
On Thu, Oct 04, 2012 at 04:59:27PM +0530, Avik Sil wrote:
> On 10/04/2012 04:52 PM, Gleb Natapov wrote:
> >On Thu, Oct 04, 2012 at 04:25:28PM +0530, Avik Sil wrote:
> >>On 09/27/2012 03:21 PM, Gleb Natapov wrote:
> >>>On Thu, Sep 27, 2012 at 11:33:31AM +0200, Alexander Graf wrote:
>
> On 2
On Thu, Oct 4, 2012 at 2:36 PM, Avi Kivity wrote:
> The hassle and compile time overhead of maintaining both 32-bit and 64-bit
> capable source isn't worth the tiny performance advantage which is seen on
> a minority of configurations. Switch to compiling libhw only once, with
> target_phys_addr_
On 10/02/2012 07:50 AM, Evgeny Voevodin wrote:
s->cpu_enabled is an array, so s->cpu_enabled ? "En" : "Dis" returns
"En" always. We should use s->cpu_enabled[cpu] here.
Signed-off-by: Evgeny Voevodin
---
hw/arm_gic.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/hw/a
On Wed, 3 Oct 2012 10:28:59 -0300
Eduardo Habkost wrote:
> Add an extra argument to:
> - pc_memory_init()
> - bochs_bios_init()
> - pc_cpus_init()
> - pc_new_cpu()
>
> Signed-off-by: Eduardo Habkost
> ---
> hw/pc.c | 13 +++--
> hw/pc.h | 5 +++--
> hw/pc_piix.c | 4 ++
On 4 October 2012 12:50, Evgeny Voevodin wrote:
> On 10/02/2012 07:50 AM, Evgeny Voevodin wrote:
>>
>> s->cpu_enabled is an array, so s->cpu_enabled ? "En" : "Dis" returns
>> "En" always. We should use s->cpu_enabled[cpu] here.
>
> Did anybody pick this up?
Yeah, I've put it in arm-devs.next.
--
On Wed, 3 Oct 2012 10:29:01 -0300
Eduardo Habkost wrote:
> Needed for the definition of fprint_function.
>
> This is not necessary right now, but it will be necessary if code that
> doesn't include cpu-common.h includes cpus.h.
Could be it cut to a separate standard hearders, and include only t
On 10/04/2012 07:48 AM, Jan Kiszka wrote:
On 2012-10-03 15:19, Paolo Bonzini wrote:
Il 03/10/2012 12:57, Lucas Meneghel Rodrigues ha scritto:
Yep, I did send patches with the testdev device present on qemu-kvm.git
to qemu.git a while ago, but there were many comments on the review, I
ended up n
On 04.10.2012, at 14:18, Avik Sil wrote:
> I looked at the bootindex stuff and found that when the bootindex is
> specified for the disk and cdrom it generates a string like:
>
> "/spapr-vio-bridge/spapr-vscsi/channel@0/disk@0,1
> /spapr-vio-bridge/spapr-vscsi/channel@0/disk@
On 2012-10-04 14:10, Lucas Meneghel Rodrigues wrote:
> On 10/04/2012 07:48 AM, Jan Kiszka wrote:
>> On 2012-10-03 15:19, Paolo Bonzini wrote:
>>> Il 03/10/2012 12:57, Lucas Meneghel Rodrigues ha scritto:
Yep, I did send patches with the testdev device present on qemu-kvm.git
to qemu.git a
On 10/03/2012 01:50 PM, Bharat Bhushan wrote:
> sysbus_connect_irq(s, 0, mpic[pci_irq_nrs[0]]);
> diff --git a/hw/ppce500_pci.c b/hw/ppce500_pci.c
> index 92b1dc0..16e4af2 100644
> --- a/hw/ppce500_pci.c
> +++ b/hw/ppce500_pci.c
> @@ -87,6 +87,7 @@ struct PPCE500PCIState {
> /* mmio maps
On 04.10.2012, at 14:35, Avik Sil wrote:
>> So you want to hack around the problem. If -boot is specified what
>> device are you going to boot from?
>
> It is going to boot from the device specified in -boot as
> default_boot_order is set to 0 in that case.
Imagin
On Thu, Oct 04, 2012 at 02:37:22PM +0200, Alexander Graf wrote:
>
> On 04.10.2012, at 14:35, Avik Sil wrote:
>
> >> So you want to hack around the problem. If -boot is specified what
> >> device are you going to boot from?
> >
> > It is going to boot from the device specified in
On Thu, Oct 04, 2012 at 08:53:22AM +0200, Igor Mammedov wrote:
> On Wed, 3 Oct 2012 13:54:34 -0300
> Eduardo Habkost wrote:
>
> > On Wed, Oct 03, 2012 at 06:24:11PM +0200, Igor Mammedov wrote:
> > > On Wed, 03 Oct 2012 17:20:46 +0200
> > > Paolo Bonzini wrote:
> > >
> > > > Il 03/10/2012 17:03,
On Wed, 3 Oct 2012 10:29:07 -0300
Eduardo Habkost wrote:
> This allows callers of cpu_x86_init() to override the APIC ID, in case
> it needs to build a specific cores/threads topology.
>
> Because *-user doesn't have any concept of CPU topology, we do not
> require every caller to specify an AP
Am 04.10.2012 14:43, schrieb Eduardo Habkost:
> On Thu, Oct 04, 2012 at 08:53:22AM +0200, Igor Mammedov wrote:
>> For x86 CPU classes we were going dynamically generate CPU classes and store
>> pointer to appropriate cpudef from builtin_x86_defs in class field for each
>> CPU class and then init de
On Thu, 4 Oct 2012 09:43:41 -0300
Eduardo Habkost wrote:
> On Thu, Oct 04, 2012 at 08:53:22AM +0200, Igor Mammedov wrote:
> > On Wed, 3 Oct 2012 13:54:34 -0300
> > Eduardo Habkost wrote:
> >
> > > On Wed, Oct 03, 2012 at 06:24:11PM +0200, Igor Mammedov wrote:
> > > > On Wed, 03 Oct 2012 17:20:4
On Thu, Oct 04, 2012 at 02:57:29PM +0200, Andreas Färber wrote:
> Am 04.10.2012 14:43, schrieb Eduardo Habkost:
> > On Thu, Oct 04, 2012 at 08:53:22AM +0200, Igor Mammedov wrote:
> >> For x86 CPU classes we were going dynamically generate CPU classes and
> >> store
> >> pointer to appropriate cpud
On Thu, Oct 04, 2012 at 03:01:19PM +0200, Igor Mammedov wrote:
> On Thu, 4 Oct 2012 09:43:41 -0300
> Eduardo Habkost wrote:
>
> > On Thu, Oct 04, 2012 at 08:53:22AM +0200, Igor Mammedov wrote:
> > > On Wed, 3 Oct 2012 13:54:34 -0300
> > > Eduardo Habkost wrote:
> > >
> > > > On Wed, Oct 03, 201
On Thu, 04 Oct 2012 14:57:29 +0200
Andreas Färber wrote:
> Am 04.10.2012 14:43, schrieb Eduardo Habkost:
> > On Thu, Oct 04, 2012 at 08:53:22AM +0200, Igor Mammedov wrote:
> >> For x86 CPU classes we were going dynamically generate CPU classes and
> >> store pointer to appropriate cpudef from bui
On Thu, Oct 04, 2012 at 02:00:57PM +0200, Igor Mammedov wrote:
> On Wed, 3 Oct 2012 10:29:01 -0300
> Eduardo Habkost wrote:
>
> > Needed for the definition of fprint_function.
> >
> > This is not necessary right now, but it will be necessary if code that
> > doesn't include cpu-common.h include
On Thu, Oct 04, 2012 at 03:10:53PM +0200, Igor Mammedov wrote:
> On Thu, 04 Oct 2012 14:57:29 +0200
> Andreas Färber wrote:
>
> > Am 04.10.2012 14:43, schrieb Eduardo Habkost:
> > > On Thu, Oct 04, 2012 at 08:53:22AM +0200, Igor Mammedov wrote:
> > >> For x86 CPU classes we were going dynamically
On Thu, 4 Oct 2012 10:10:27 -0300
Eduardo Habkost wrote:
> On Thu, Oct 04, 2012 at 03:01:19PM +0200, Igor Mammedov wrote:
> > On Thu, 4 Oct 2012 09:43:41 -0300
> > Eduardo Habkost wrote:
> >
> > > On Thu, Oct 04, 2012 at 08:53:22AM +0200, Igor Mammedov wrote:
> > > > On Wed, 3 Oct 2012 13:54:34
On Thu, Oct 04, 2012 at 03:25:59PM +0200, Igor Mammedov wrote:
> On Thu, 4 Oct 2012 10:10:27 -0300
> Eduardo Habkost wrote:
>
> > On Thu, Oct 04, 2012 at 03:01:19PM +0200, Igor Mammedov wrote:
> > > On Thu, 4 Oct 2012 09:43:41 -0300
> > > Eduardo Habkost wrote:
> > >
> > > > On Thu, Oct 04, 201
On 09/13/2012 08:24 AM, Paolo Bonzini wrote:
Il 12/09/2012 15:58, Anthony Liguori ha scritto:
Why would someone use this verses megasas vs. LSI vs virtio-scsi?
LSI is dead. Compare it to IDE.
virtio-scsi has the highest performance, but it is not supported on all
guests. Compare it to virti
Eduardo Habkost writes:
> We can make it a child of a generic "machine" class later, but right now
> a "PC" class is needed to allow global-properties to control some
> details of CPU creation on the PC code.
>
> Signed-off-by: Eduardo Habkost
> ---
> hw/pc.c | 18 ++
> hw/pc.h
If you have a guest with a media in the cdrom and you change it,
the windows and the linux guests cannot properly recognize this
media change.
For this purpose we have to pretend for some time (2s), that we
don't have any media inserted.
Signed-off-by: Pavel Hrdina
---
hw/ide/atapi.c| 25 +++
On Thu, 4 Oct 2012 10:33:30 -0300
Eduardo Habkost wrote:
> On Thu, Oct 04, 2012 at 03:25:59PM +0200, Igor Mammedov wrote:
> > On Thu, 4 Oct 2012 10:10:27 -0300
> > Eduardo Habkost wrote:
> >
> > > On Thu, Oct 04, 2012 at 03:01:19PM +0200, Igor Mammedov wrote:
> > > > On Thu, 4 Oct 2012 09:43:41
Il 04/10/2012 15:46, Anthony Liguori ha scritto:
>> > +typedef struct PC {
>> > +DeviceState parent_obj;
>> > +} PC;
> So the general problem with this approach is that it strays from
> modeling hardware.
It doesn't really; it's a motherboard object, there's no reason why
/machine shouldn't be
On Thu, Oct 04, 2012 at 08:46:46AM -0500, Anthony Liguori wrote:
> Eduardo Habkost writes:
>
> > We can make it a child of a generic "machine" class later, but right now
> > a "PC" class is needed to allow global-properties to control some
> > details of CPU creation on the PC code.
> >
> > Signe
From: Andreas Färber
Place it in alphabetical order, there is a separate section for sharing
ppc4xx devices now.
Signed-off-by: Andreas Färber
Acked-by: Edgar E. Iglesias
Signed-off-by: Alexander Graf
---
MAINTAINERS |6 ++
1 files changed, 6 insertions(+), 0 deletions(-)
diff --git
From: Andreas Färber
As requested by Alex.
Signed-off-by: Andreas Färber
Signed-off-by: Alexander Graf
---
MAINTAINERS |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/MAINTAINERS b/MAINTAINERS
index cfb7394..9d4ccfc 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -349,
From: David Gibson
Currently the XICS interrupt controller emulation uses a custom enum to
specify whether a given interrupt is level-sensitive or message-triggered.
This enum makes life awkward for saving the state, and isn't particularly
useful since there are only two possibilities. This patc
From: Stefan Weil
Report from smatch:
ppc405_uc.c:209 dcr_read_pob(12) error: buffer overflow 'pob->besr' 2 <= 2
ppc405_uc.c:232 dcr_write_pob(12) error: buffer overflow 'pob->besr' 2 <= 2
The old code reads and writes besr[POB0_BESR1 - POB0_BESR0] or besr[2]
which is one too much.
Signed-off-
From: David Gibson
Currently the pseries machine code always attempts to set the size of the
guests's hash page table to 16MB. However, because of the way the POWER
MMU works, a suitable hash page table size should really depend on memory
size. 16MB will be excessive for guests with <1GB and RA
From: David Gibson
The kvmppc_reset_htab() function invokes the KVM_PPC_ALLOCATE_HTAB vm ioctl
to request KVM to allocate and reset a hash page table for the guest - it
returns the size of hash table allocated, or 0 to indicate that qemu needs
to allocate the hash table itself. In practice qemu
> -Original Message-
> From: Avi Kivity [mailto:a...@redhat.com]
> Sent: Thursday, October 04, 2012 6:02 PM
> To: Bhushan Bharat-R65777
> Cc: qemu-devel@nongnu.org; qemu-...@nongnu.org; ag...@suse.de; Bhushan Bharat-
> R65777
> Subject: Re: [Qemu-devel] [PATCH 2/2] Adding BAR0 for e500 PC
Avi Kivity writes:
> AddressSpace contains a member, current_map, of type FlatView. Since we
> want to limit the leakage of internal types to public headers, switch to
> a pointer to a FlatView. There is no performance impact as this isn't used
> during lookups, only address space reconfigurati
Avi Kivity writes:
> The DMA API will use an AddressSpace to differentiate among different
> initiators.
>
> Signed-off-by: Avi Kivity
Reviewed-by: Anthony Liguori
Regards,
Anthony Liguori
> ---
> memory.c | 11 +--
> memory.h | 21 +
> 2 files changed, 22 inser
Avi Kivity writes:
> Instead of embedding knowledge of the memory and I/O address spaces in the
> memory core, maintain a list of all address spaces. This list will later
> be extended dynamically for other but masters.
>
> Signed-off-by: Avi Kivity
Reviewed-by: Anthony Liguori
Regards,
Ant
On Thu, 4 Oct 2012 10:14:48 -0300
Eduardo Habkost wrote:
> On Thu, Oct 04, 2012 at 02:00:57PM +0200, Igor Mammedov wrote:
> > On Wed, 3 Oct 2012 10:29:01 -0300
> > Eduardo Habkost wrote:
> >
> > > Needed for the definition of fprint_function.
> > >
> > > This is not necessary right now, but i
Avi Kivity writes:
> Many listeners don't need to respond to all MemoryListener callbacks;
> provide suitable defaults instead.
>
> Signed-off-by: Avi Kivity
> ---
> memory.c | 15 +++
> memory.h | 21 +
> 2 files changed, 36 insertions(+)
>
> diff --git a/memory
Avi Kivity writes:
> With this change, memory.c no longer knows anything about special address
> spaces, so it is prepared for AddressSpace based DMA.
>
> Signed-off-by: Avi Kivity
Reviewed-by: Anthony Liguori
Regards,
Anthony Liguori
> ---
> exec-memory.h | 6 --
> exec.c| 9
Avi Kivity writes:
> Using the AddressSpace type reduces confusion, as you can't accidentally
> supply the MemoryRegion you're interested in.
>
> Signed-off-by: Avi Kivity
Reviewed-by: Anthony Liguori
Regards,
Anthony Liguori
> ---
> exec-memory.h | 3 +++
> exec.c| 10 +-
If you have a guest with a media in the cdrom and you change it,
the windows and the linux guests cannot properly recognize this
media change.
For this purpose we have to pretend for some time (2s), that we
don't have any media inserted.
v2: disable debug messages
Signed-off-by: Pavel Hrdina
---
Paolo Bonzini writes:
> Il 03/10/2012 18:03, Avi Kivity ha scritto:
>> Most of the work on the memory API focused on memory access targets - the
>> memory regions
>> and how they are composed into an address space. This patchset tackles the
>> initator
>> side of the question - how to originat
Jan Kiszka writes:
> On 2012-10-03 20:26, Marcelo Tosatti wrote:
>> On Wed, Oct 03, 2012 at 07:24:48PM +0200, Jan Kiszka wrote:
>>> On 2012-10-03 19:16, Anthony Liguori wrote:
Jan Kiszka writes:
> On 2012-10-03 17:03, Marcelo Tosatti wrote:
>> On Wed, Oct 03, 2012 at 09:40:17AM
From: David Gibson
This patch adds some extra FPU state to CPUPPCState. Specifically, fpscr
is extended to 64 bits, since some recent CPUs now have more status bits
than fit inside 64 bits, and we add the 32 VSR registers present on CPUs
with VSX (these extend the standard FP regs, which togethe
From: David Gibson
When we reset the system, the reset method for VIO bus devices resets
the state of their request queue (if present) as it should. However
it was not resetting the state of their TCE table (DMA translation) if
present. It was also not resetting the state of the per-device sign
From: Andreas Färber
Signed-off-by: Andreas Färber
Acked-by: David Gibson
Signed-off-by: Alexander Graf
---
MAINTAINERS |7 +++
1 files changed, 7 insertions(+), 0 deletions(-)
diff --git a/MAINTAINERS b/MAINTAINERS
index 29aac4f..af7c7db 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@
From: David Gibson
The XICS interrupt controller used on the pseries machine currently has no
reset handler. We can get away with this under some circumstances, but
it's not correct, and can cause failures if the XICS happens to be in the
wrong state at the time of reset.
This patch adds a hook
From: David Gibson
The emulated PCI host bridge on the pseries machine incorporates an IOMMU
(PAPR TCE table). Currently the mappings in this IOMMU are not cleared
when we reset the system. This patch fixes this bug. To do this it adds
a new reset function to the IOMMU emulation code. The VIO
From: David Gibson
Currently the ibm,int-on and ibm,int-off RTAS functions are implemented as
no-ops. This is because when implemented as specified in PAPR they caused
Linux (which calls both int-on/off and set-xive) to end up with interrupts
masked when they should not be. Since Linux's set-xi
On 10/04/2012 04:08 PM, Anthony Liguori wrote:
> Avi Kivity writes:
>
>> Instead of calling a global function on coalesced mmio changes, which
>> routes the call to kvm if enabled, add coalesced mmio hooks to
>> MemoryListener and make kvm use that instead.
>>
>> The motivation is support for mul
From: David Gibson
At least when invoked with high enough 'level' arguments,
kvm_arch_put_registers() is supposed to copy essentially all the cpu state
as encoded in qemu's internal structures into the kvm state. Currently
the ppc version does not do this - it never calls KVM_SET_SREGS, for
exam
This macro snuck through code review despite being unused; drop it.
Signed-off-by: Peter Maydell
---
target-arm/cpu.h |2 --
1 file changed, 2 deletions(-)
diff --git a/target-arm/cpu.h b/target-arm/cpu.h
index 7fac94f..ff4de10 100644
--- a/target-arm/cpu.h
+++ b/target-arm/cpu.h
@@ -423,8
On 10/04/2012 04:16 PM, Anthony Liguori wrote:
> Paolo Bonzini writes:
>
>> Il 03/10/2012 18:03, Avi Kivity ha scritto:
>>> Most of the work on the memory API focused on memory access targets - the
>>> memory regions
>>> and how they are composed into an address space. This patchset tackles the
From: David Gibson
The general device state structure for PAPR VIO emulated devices includes a
'flags' field which was never used. This patch removes it.
Signed-off-by: David Gibson
Signed-off-by: Alexander Graf
---
hw/spapr_vio.h |1 -
1 files changed, 0 insertions(+), 1 deletions(-)
d
On 2012-10-04 16:21, Anthony Liguori wrote:
> -no-kvm should be included too.
Reminds me that we still need to agree on the final default accel strategy.
>
> I just ran across a user that was injecting '-no-kvm-irqchip' in their
> libvirt XML via a custom attribute. It turned out it was to work
From: Scott Wood
While investigating dtb pad issues, I noticed that initrd_base wasn't taking
loadaddr into account the way dt_base was. This seems wrong.
Signed-off-by: Scott Wood
Signed-off-by: Alexander Graf
---
hw/ppc/e500.c |3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
d
From: Aurelien Jarno
Commit e024e881bb1a8b5085026589360d26ed97acdd64 provided a pickNaN()
function for PowerPC, implementing the correct NaN propagation rules.
Therefore there is no need to test the operands manually, we can rely
on the softfloat code to do that.
Signed-off-by: Aurelien Jarno
S
On 12/14/2011 06:20 AM, M. Mohan Kumar wrote:
> From: "M. Mohan Kumar"
>
> Add interfaces to open and create files for proxy file system driver.
>
> Signed-off-by: M. Mohan Kumar
> ---
> fsdev/virtfs-proxy-helper.c | 178 -
> hw/9pfs/virtio-9p-proxy.c
From: David Gibson
The ppc specific CPU state contains several variables which track the
VPA, SLB shadow and dispatch trace log. These are structures shared
between OS and hypervisor that are used on the pseries machine to track
various per-CPU quantities.
The address of these structures needs
From: Scott Wood
An allowance of 5 MiB for BSS is not enough for Linux kernels with certain
debug options enabled (not sure exactly which one caused it, but I'd guess
lockdep). The kernel I ran into this with had a BSS of around 6.4 MB.
Unfortunately, uImage does not give us enough information
On 10/04/2012 03:46 PM, Bhushan Bharat-R65777 wrote:
>
>
>> -Original Message-
>> From: Avi Kivity [mailto:a...@redhat.com]
>> Sent: Thursday, October 04, 2012 6:02 PM
>> To: Bhushan Bharat-R65777
>> Cc: qemu-devel@nongnu.org; qemu-...@nongnu.org; ag...@suse.de; Bhushan
>> Bharat-
>> R65
From: Andreas Färber
Signed-off-by: Andreas Färber
Cc: Alexander Graf
Cc: Scott Wood
Signed-off-by: Alexander Graf
---
MAINTAINERS | 23 +++
1 files changed, 23 insertions(+), 0 deletions(-)
diff --git a/MAINTAINERS b/MAINTAINERS
index af7c7db..cfb7394 100644
--- a/MAI
From: David Gibson
The current pseries machine init function iterates over the CPUs at several
points, doing various bits of initialization. This is messy; these can
and should be merged into a single iteration doing all the necessary per
cpu initialization. Worse, some of these initializations
From: David Gibson
The H_CEDE hypercall implementation for the pseries machine doesn't trigger
quite the right path in the main cpu exec loop. We should set exit_request
to pop up one extra level and recheck state, and we should set the
exception_index to EXCP_HLT (H_CEDE is roughly equivalent t
From: David Gibson
The XICS interrupt controller emulation uses some C bitfield variables in
its internal state structure. This makes like awkward for saving the state
because we don't have easy VMSTATE helpers for bitfields.
This patch removes the bitfields, instead using explicit bit masking
From: Aurelien Jarno
We can finally get rid of the ugly HANDLE_NAN{1,2,3} macros.
Signed-off-by: Aurelien Jarno
Signed-off-by: Alexander Graf
---
target-ppc/int_helper.c | 21 -
1 files changed, 0 insertions(+), 21 deletions(-)
diff --git a/target-ppc/int_helper.c b/tar
On 10/04/2012 04:05 PM, Anthony Liguori wrote:
> Avi Kivity writes:
>
>> Many listeners don't need to respond to all MemoryListener callbacks;
>> provide suitable defaults instead.
>>
>> +#define MEMORY_LISTENER_DEFAULT_OPS \
>> +.begin = memory_listener_default_globa
Eduardo Habkost writes:
> On Thu, Oct 04, 2012 at 09:28:13AM -0500, Anthony Liguori wrote:
>> Paolo Bonzini writes:
>>
>> > Il 04/10/2012 15:46, Anthony Liguori ha scritto:
>> >>> > +typedef struct PC {
>> >>> > +DeviceState parent_obj;
>> >>> > +} PC;
>> >> So the general problem with this
From: David Gibson
CPUPPCState includes a variable 'power_mode' which is used nowhere. This
patch removes it. This includes saving a dummy zero in its place during
vmsave, to avoid breaking the save format.
Signed-off-by: David Gibson
Signed-off-by: Alexander Graf
---
target-ppc/cpu.h |
From: David Gibson
PAPR hypercalls should only be invoked from the guest kernel, not guest
user programs, that is, with MSR[PR]=0. Currently we check this in
spapr_hypercall, returning H_PRIVILEGE if MSR[PR]=1.
However, under KVM the state of MSR[PR] is already checked by the host
kernel before
1 - 100 of 341 matches
Mail list logo
