On 21.05.14 16:21, Alexey Kardashevskiy wrote:
Currently only single TCE entry per request is supported (H_PUT_TCE).
However PAPR+ specification allows multiple entry requests such as
H_PUT_TCE_INDIRECT and H_STUFF_TCE. Having less transitions to the host
kernel via ioctls, support of these call
Stefan Hajnoczi writes:
> On Tue, May 20, 2014 at 02:04:31PM +0800, Fam Zheng wrote:
>> This makes use of op_blocker and blocks all the operations except for
>> commit target, on each BlockDriverState->backing_hd.
>>
>> The asserts for op_blocker in bdrv_swap are removed because with this
>> cha
On 13 May 2014 17:15, Fabian Aggeler wrote:
> From: Svetlana Fedoseeva
>
> Define Security Extensions CPU feature. Set that feature for relevant CPUs.
This is potentially tricky because it means that CPUs which we were
previously implementing without TZ now boot up with TZ and in
Secure mode; I
On 13 May 2014 17:15, Fabian Aggeler wrote:
> --- a/target-arm/cpu.h
> +++ b/target-arm/cpu.h
> @@ -631,6 +631,7 @@ enum arm_features {
> ARM_FEATURE_CBAR, /* has cp15 CBAR */
> ARM_FEATURE_CRC, /* ARMv8 CRC instructions */
> ARM_FEATURE_CBAR_RO, /* has cp15 CBAR and it is read-only
On Tue, May 20, 2014 at 10:43:19PM +0200, Max Reitz wrote:
> Currently, test 089 uses $QEMU_IMG info manually in order to obtain the
> according output. However, the iotests should generally use _img_info as
> this filters out more irrelevant information such as the host image size
> or format spec
On 13 May 2014 17:15, Fabian Aggeler wrote:
> From: Sergey Fedorov
>
> Define a new ARM CP register info list for the Security Extension feature.
> Register that list only for ARM cores with Security Extension support.
> Moving SCR into Security Extension register group.
>
> Signed-off-by: Sergey
On Wed, May 21, 2014 at 03:56:55PM +0200, Igor Mammedov wrote:
> On Wed, 21 May 2014 15:44:07 +0300
> "Michael S. Tsirkin" wrote:
>
> > On Wed, May 21, 2014 at 01:22:23PM +0200, Igor Mammedov wrote:
> > > On Wed, 21 May 2014 11:05:58 +0300
> > > "Michael S. Tsirkin" wrote:
> > >
> > > > On Tue,
On Wed, 21 May 2014 18:01:45 +0300
"Michael S. Tsirkin" wrote:
> On Wed, May 21, 2014 at 03:56:55PM +0200, Igor Mammedov wrote:
> > On Wed, 21 May 2014 15:44:07 +0300
> > "Michael S. Tsirkin" wrote:
> >
> > > On Wed, May 21, 2014 at 01:22:23PM +0200, Igor Mammedov wrote:
> > > > On Wed, 21 May
At the moment the "ibm,hypertas-functions" list is fixed. However some
calls should be listed there if they are supported by QEMU or the host
kernel.
This enables hyperrtas_prop to grow on stack by adding
a SPAPR_HYPERRTAS_ADD macro. "qemu,hypertas-functions" is converted as well.
The first user
Currently only single TCE entry per request is supported (H_PUT_TCE).
However PAPR+ specification allows multiple entry requests such as
H_PUT_TCE_INDIRECT and H_STUFF_TCE. Having less transitions to the host
kernel via ioctls, support of these calls can accelerate IOMMU operations.
This implement
Am 21.05.2014 14:11, schrieb Michael S. Tsirkin:
> On Wed, May 21, 2014 at 12:42:13PM +0200, Andreas Färber wrote:
>> Am 21.05.2014 12:22, schrieb Michael S. Tsirkin:
>>> On Wed, May 21, 2014 at 11:48:48AM +0200, Andreas Färber wrote:
Am 21.05.2014 11:25, schrieb Michael S. Tsirkin:
> On W
On 05/22/2014 01:23 AM, Alexey Kardashevskiy wrote:
> Currently only single TCE entry per request is supported (H_PUT_TCE).
> However PAPR+ specification allows multiple entry requests such as
> H_PUT_TCE_INDIRECT and H_STUFF_TCE. Having less transitions to the host
> kernel via ioctls, support of
On 13 May 2014 17:15, Fabian Aggeler wrote:
> From: Sergey Fedorov
>
> TTBCR has additional fields PD0 and PD1 when using Short-descriptor
> translation table format on a CPU with Security Extension support.
>
> Signed-off-by: Sergey Fedorov
> Signed-off-by: Fabian Aggeler
> ---
> target-arm/h
On 14 May 2014 06:43, Sergey Fedorov wrote:
>
> On 13.05.2014 20:15, Fabian Aggeler wrote:
>> From: Svetlana Fedoseeva
>>
>> Signed-off-by: Svetlana Fedoseeva
>> Signed-off-by: Sergey Fedorov
>> Signed-off-by: Fabian Aggeler
>> ---
>> target-arm/helper.c | 5 +
>> 1 file changed, 5 insert
Add remove_boot_device_path() function to remove bootindex when hot-unplug
a device.
Signed-off-by: Jun Li
---
hw/block/virtio-blk.c| 1 +
hw/i386/kvm/pci-assign.c | 1 +
hw/misc/vfio.c | 1 +
hw/net/e1000.c | 1 +
hw/net/eepro100.c| 1 +
hw/net/ne2000.c
Hi Peter,
On 05/21/2014 10:46 AM, Peter Maydell wrote:
> On 13 May 2014 17:15, Fabian Aggeler wrote:
>> From: Svetlana Fedoseeva
>>
>> Define Security Extensions CPU feature. Set that feature for relevant CPUs.
>
> This is potentially tricky because it means that CPUs which we were
> previously
Some code in the block layer makes potentially huge allocations. Failure
is not completely unexpected there, so avoid aborting qemu and handle
out-of-memory situations gracefully.
This patch addresses the allocations in the cloop block driver.
Signed-off-by: Kevin Wolf
---
block/cloop.c | 23 ++
A not too small part of the recent CVEs were DoS scenarios by letting
qemu abort with too large memory allocations. We generally "fixed" these
cases by setting some limits on values read from image files that
influence the size of allocations.
Because we still need to allow reading large images, t
Some code in the block layer makes potentially huge allocations. Failure
is not completely unexpected there, so avoid aborting qemu and handle
out-of-memory situations gracefully.
This patch addresses the allocations in the vmdk block driver.
Signed-off-by: Kevin Wolf
---
block/vmdk.c | 12
Some code in the block layer makes potentially huge allocations. Failure
is not completely unexpected there, so avoid aborting qemu and handle
out-of-memory situations gracefully.
This patch addresses bounce buffer allocations in block.c. While at it,
convert bdrv_commit() from plain g_malloc() to
Some code in the block layer makes potentially huge allocations. Failure
is not completely unexpected there, so avoid aborting qemu and handle
out-of-memory situations gracefully.
This patch addresses the allocations in the mirror block job.
Signed-off-by: Kevin Wolf
---
block/mirror.c | 7
Some code in the block layer makes potentially huge allocations. Failure
is not completely unexpected there, so avoid aborting qemu and handle
out-of-memory situations gracefully.
This patch addresses the allocations in the iscsi block driver.
Signed-off-by: Kevin Wolf
---
block/iscsi.c | 16 ++
Some code in the block layer makes potentially huge allocations. Failure
is not completely unexpected there, so avoid aborting qemu and handle
out-of-memory situations gracefully.
This patch addresses the allocations in the parallels block driver.
Signed-off-by: Kevin Wolf
---
block/parallels.c
On 21.05.2014 20:14, Christopher Covington wrote:
> Hi Peter,
>
> On 05/21/2014 10:46 AM, Peter Maydell wrote:
>> On 13 May 2014 17:15, Fabian Aggeler wrote:
>>> From: Svetlana Fedoseeva
>>>
>>> Define Security Extensions CPU feature. Set that feature for relevant CPUs.
>> This is potentially tri
Some code in the block layer makes potentially huge allocations. Failure
is not completely unexpected there, so avoid aborting qemu and handle
out-of-memory situations gracefully.
This patch addresses the allocations in the dmg block driver.
Signed-off-by: Kevin Wolf
---
block/dmg.c | 11 ++
Some code in the block layer makes potentially huge allocations. Failure
is not completely unexpected there, so avoid aborting qemu and handle
out-of-memory situations gracefully.
This patch addresses the allocations in the qcow1 block driver.
Signed-off-by: Kevin Wolf
---
block/qcow.c | 29 +++
Some code in the block layer makes potentially huge allocations. Failure
is not completely unexpected there, so avoid aborting qemu and handle
out-of-memory situations gracefully.
This patch addresses the allocations in the raw-win32 block driver.
Signed-off-by: Kevin Wolf
---
block/win32-aio.c
Some code in the block layer makes potentially huge allocations. Failure
is not completely unexpected there, so avoid aborting qemu and handle
out-of-memory situations gracefully.
This patch addresses the allocations in the rbd block driver.
Signed-off-by: Kevin Wolf
---
block/rbd.c | 5 -
Some code in the block layer makes potentially huge allocations. Failure
is not completely unexpected there, so avoid aborting qemu and handle
out-of-memory situations gracefully.
This patch addresses the allocations in the qcow2 block driver.
Signed-off-by: Kevin Wolf
---
block/qcow2-cache.c
Some code in the block layer makes potentially huge allocations. Failure
is not completely unexpected there, so avoid aborting qemu and handle
out-of-memory situations gracefully.
This patch addresses the allocations in the vhdx block driver.
Signed-off-by: Kevin Wolf
---
block/vhdx-log.c | 6
Some code in the block layer makes potentially huge allocations. Failure
is not completely unexpected there, so avoid aborting qemu and handle
out-of-memory situations gracefully.
This patch addresses the allocations in the qed block driver.
Signed-off-by: Kevin Wolf
---
block/qed-check.c | 7 +
Some code in the block layer makes potentially huge allocations. Failure
is not completely unexpected there, so avoid aborting qemu and handle
out-of-memory situations gracefully.
This patch addresses the allocations in the vpc block driver.
Signed-off-by: Kevin Wolf
---
block/vpc.c | 6 +-
On 21.05.2014 20:41, Peter Maydell wrote:
> If we want to have -kernel boot in NS then yes, the bootloader
> stub is the place that code should go.
>
> The difficulty with -kernel being NS is that some guest kernels
> for some boards may be assuming that they will run in secure state
> and can dire
On 21 May 2014 17:33, Sergey Fedorov wrote:
> On 21.05.2014 20:14, Christopher Covington wrote:
>> On 05/21/2014 10:46 AM, Peter Maydell wrote:
>>> (Also I'm not sure what the semantics of -kernel should be for
>>> TZ-supporting CPUs -- boot the kernel in S or NS ?)
>> While Linux works in secure
Some code in the block layer makes potentially huge allocations. Failure
is not completely unexpected there, so avoid aborting qemu and handle
out-of-memory situations gracefully.
This patch addresses the allocations in the vdi block driver.
Signed-off-by: Kevin Wolf
---
block/vdi.c | 20 ++
Some code in the block layer makes potentially huge allocations. Failure
is not completely unexpected there, so avoid aborting qemu and handle
out-of-memory situations gracefully.
This patch addresses the allocations in the curl block driver.
Signed-off-by: Kevin Wolf
---
block/curl.c | 8 +
Can you explain what "ssgyboot=break" tells the kernel to do?
Could you upload the guest's /var/log/syslog after reboot?
Please show
echo $?
immediately after the qemu-system-ppc command has exited?
** Also affects: qemu
Importance: Undecided
Status: New
** Changed in: qemu (Ubuntu)
On 5/21/2014 1:20 AM, Alexey Kardashevskiy wrote:
> MMCR0 and MMCR1 have different numbers for 32 and 64 bit POWERPC.
> We are going to support 64bit versions too so let's rename 32bit ones
> to avoid confusion.
>
> 604 uses same SPR number for MMCR0 so it is included in this patch too.
I'm not s
On 5/21/2014 1:20 AM, Alexey Kardashevskiy wrote:
> This adds TIR/SIAR/SDAR/MMCRA/MMCR0/MMCR1.
>
> This redefines UMMCRA (was MCCRA) and defines hypv version of if.
>
> Signed-off-by: Alexey Kardashevskiy
> ---
> target-ppc/cpu.h| 10 +-
> target-ppc/translate_init.c | 41 ++
On 5/21/2014 1:20 AM, Alexey Kardashevskiy wrote:
> This duplicates code of init_proc_POWER7() in init_proc_POWER8() as
> there will be registers implemented in POWER7 and missing in POWER8
> so we need separate init functions for POWER7 and POWER8.
>
> Signed-off-by: Alexey Kardashevskiy
> ---
>
Some code in the block layer makes potentially huge allocations. Failure
is not completely unexpected there, so avoid aborting qemu and handle
out-of-memory situations gracefully.
This patch addresses the allocations in the raw-posix block driver.
Signed-off-by: Kevin Wolf
---
block/raw-posix.c
Some code in the block layer makes potentially huge allocations. Failure
is not completely unexpected there, so avoid aborting qemu and handle
out-of-memory situations gracefully.
This patch addresses the allocations in the bochs block driver.
Signed-off-by: Kevin Wolf
---
block/bochs.c | 6 +++
Some code in the block layer makes potentially huge allocations. Failure
is not completely unexpected there, so avoid aborting qemu and handle
out-of-memory situations gracefully.
This patch addresses the allocations in the nfs block driver.
Signed-off-by: Kevin Wolf
---
block/nfs.c | 6 +-
This function returns NULL instead of aborting when an allocation fails.
Signed-off-by: Kevin Wolf
---
block.c | 5 +
include/block/block.h | 1 +
include/qemu/osdep.h | 1 +
util/oslib-posix.c| 16 ++--
util/oslib-win32.c| 9 +++--
5 files changed,
1. ssgyboot-break has no effect in the VM kernel; It is only used by
jade-initrd-2.0.bin ;
kernel cmdline:
[0.00] pcpu-alloc: s28800 r8192 d16256 u53248 alloc=13*4096
[0.00] pcpu-alloc: [0] 0
[0.00] Built 1 zonelists in Zone order, mobility grouping on. Total pag
es:
/var/log/syslog attached as syslog.onboot when file system is dirty ;
Since the VM terminated ; the device should have been umounted ;
** Attachment added: "syslog.onboot"
https://bugs.launchpad.net/ubuntu/+source/qemu/+bug/1321028/+attachment/4116987/+files/syslog.onboot
--
You received
I am thinking since the VM hasn't terminated due to defect 1317603 ,
qemu-system-ppc has to be terminated with killwhich is not kill
-9 ; I could see some inconsistencies with virtio device file not being
sync'ed ; but the VM did unmount it;
--
You received this bug notification because you
I note that this also occurs with virt-manager running the non-spice
console. (The spice console is another issue . . . but not one with
qemu . . . ) so the scope of this appears to now be inter-thread
communication and *NOT* neccessarily GTK, but is far larger in scope
than initially thought.
**
On 5/21/2014 1:20 AM, Alexey Kardashevskiy wrote:
> This adds helper which adds TAR/BESCRS/BESCRSU/BESCRR/BESCRRU/
> EBBHR/EBBRR/BESCR/TFHAR/TFIAR/TEXASR/TEXASRU SPRs.
>
> This adds MMCR2/FSCR/MMCRS SPRs.
>
> Signed-off-by: Alexey Kardashevskiy
> ---
> target-ppc/cpu.h| 15 ++
>
Note: virt-manager fails if qemu compiled with -disable-gtk as well.
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1320030
Title:
Qemu 2.0.0 display hangs with display=gtk or virt-manager
Status i
On 5/21/2014 1:20 AM, Alexey Kardashevskiy wrote:
> This adds migration support for registers saved before transaction started.
>
> Signed-off-by: Alexey Kardashevskiy
> ---
> target-ppc/cpu.h | 19 +++
> target-ppc/kvm.c | 38 ++
> tar
Allow selection of different card models from the qemu
command line, to better accomodate a wider range of guests.
Signed-off-by: Romain Dolbeau
Signed-off-by: Gabriel Somlo
---
hw/net/e1000.c | 95 --
1 file changed, 79 insertions(+), 16
This started out as a single patch (now patch 2/3):
Allow selection of different card models from the qemu
command line, to better accomodate a wider range of guests.
New in v2:
- moved check for 8257x out of the way of QOM, as suggested by
Michael (patch 1/3)
- resolved "Signed
Introduce "is_8257x" boolean flag to E1000State, and set it during
pci_e1000_init(), to avoid having to dynamically figure out device_id
during set_interrupt_cause(). This will come in handy once we have
a wider range of possible device IDs, and begin using QOM.
Suggested-by: Michael S. Tsirkin
S
Update e1000-test.c to check all currently supported devices.
Suggested-by: Andreas Färber
Signed-off-by: Gabriel Somlo
---
tests/e1000-test.c | 33 ++---
1 file changed, 26 insertions(+), 7 deletions(-)
diff --git a/tests/e1000-test.c b/tests/e1000-test.c
index a8b
* Hani Benhabiles (kroo...@gmail.com) wrote:
> Signed-off-by: Hani Benhabiles
> ---
> hmp-commands.hx | 1 +
> hmp.h | 2 ++
> monitor.c | 21 +
> 3 files changed, 24 insertions(+)
>
> diff --git a/hmp-commands.hx b/hmp-commands.hx
> index 45e1763..919af6e 1
On 19 May 2014 10:22, Edgar E. Iglesias wrote:
> From: "Edgar E. Iglesias"
>
> Add aarch64_banked_spsr_index(), used to map an Exception Level
> to an index in the banked_spsr array.
>
> diff --git a/target-arm/op_helper.c b/target-arm/op_helper.c
> index f120b02..c05a839 100644
> --- a/target-ar
On 19 May 2014 10:22, Edgar E. Iglesias wrote:
> From: "Edgar E. Iglesias"
>
> Check for EL2 support before returning to it.
>
> Reviewed-by: Peter Crosthwaite
> Signed-off-by: Edgar E. Iglesias
> ---
> target-arm/op_helper.c | 11 +--
> 1 file changed, 5 insertions(+), 6 deletions(-)
On 19 May 2014 10:22, Edgar E. Iglesias wrote:
> From: "Edgar E. Iglesias"
>
> Adds support for ERET to Aarch64 EL2 and 3.
>
> Signed-off-by: Edgar E. Iglesias
> ---
> target-arm/op_helper.c | 10 +-
> 1 file changed, 5 insertions(+), 5 deletions(-)
>
> diff --git a/target-arm/op_helper
On 19 May 2014 10:22, Edgar E. Iglesias wrote:
> From: "Edgar E. Iglesias"
>
> Adds support for ERET to Aarch64 EL2 and 3.
"AArch64". Also "to" here is ambiguous. The ARM ARM tries to
keep the terminology straight to avoid confusion: exceptions
are "taken from ELx" and "taken to ELx"; we "return
On 19 May 2014 10:23, Edgar E. Iglesias wrote:
> From: "Edgar E. Iglesias"
>
> Signed-off-by: Edgar E. Iglesias
> @@ -2356,6 +2370,12 @@ void register_cp_regs_for_features(ARMCPU *cpu)
> }
> if (arm_feature(env, ARM_FEATURE_EL2)) {
> define_arm_cp_regs(cpu, v8_el2_cp_reginfo)
On 19 May 2014 10:23, Edgar E. Iglesias wrote:
> From: "Edgar E. Iglesias"
>
> Avoid using IS_USER directly as the MMU-idx to simplify future
> changes to the MMU layout.
>
> Signed-off-by: Edgar E. Iglesias
Reviewed-by: Peter Maydell
I think this makes sense; the bits involving the ldrt/strt
Hi Eric, thank you for the comments.
On 5/20/14 18:46 , "Eric Blake" wrote:
>On 05/20/2014 04:01 PM, Tomoki Sekiyama wrote:
>> The patch below is for the command to get filesystems list.
>>
>> ===
>> From: Tomoki Sekiyama
>
>You'll want to resend it as a series of patches as a top-level thread
On 19 May 2014 10:22, Edgar E. Iglesias wrote:
> From: "Edgar E. Iglesias"
>
> Hi,
>
> I've been doing some work on modeling parts of EL2 and 3 + some of
> the system-wide virtualization features for ARMv8. A lot is missing
> but I've got a series with enough to for example run KVM A64 guests
> o
Thanks for the feedback on the RFC. This time around the alias property is
implemented at the QOM property level instead of at the qdev property level.
The virtio transport/device split is broken as follows:
1. The virtio-blk device is never finalized because the transport devices
(virtio-blk
Sometimes an object needs to present a property which is actually on
another object, or it needs to provide an alias name for an existing
property.
Examples:
a.foo -> b.foo
a.old_name -> a.new_name
The new object_property_add_alias() API allows objects to alias a
property on another object.
virtio-blk-pci, virtio-blk-s390, and virtio-blk-ccw all duplicate the
qdev properties of their VirtIOBlock child. This approach does not work
well with string or pointer properties since we must be careful about
leaking or double-freeing them.
Use the QOM alias property to forward property access
Il 21/05/2014 18:28, Kevin Wolf ha scritto:
Some code in the block layer makes potentially huge allocations. Failure
is not completely unexpected there, so avoid aborting qemu and handle
out-of-memory situations gracefully.
This patch addresses the allocations in the iscsi block driver.
Signed-
This function is no longer used since parent objects now use child
aliases to set the VirtIOBlkConf directly.
Signed-off-by: Stefan Hajnoczi
---
hw/block/virtio-blk.c | 6 --
include/hw/virtio/virtio-blk.h | 2 --
2 files changed, 8 deletions(-)
diff --git a/hw/block/virtio-blk.c b
object_initialize() leaves the object with a refcount of 1.
object_property_add_child() adds its own reference which is dropped
again when the property is deleted.
The upshot of this is that we always have a refcount >= 1. Upon hot
unplug the virtio-blk child is not finalized!
Drop our reference
It becomes unwiedly to duplicate all virtio-blk qdev property
definitions due to an #ifdef. The C preprocessor syntax makes it a
little hard to resolve this cleanly but we can extract the #ifdef and
call a macro it defines later.
Avoiding duplication is important since it will only get worse when
There is no need to make DEFINE_VIRTIO_BLK_PROPERTIES() public. Inline
it into virtio-blk.c so it cannot be used by mistake from other source
files.
Signed-off-by: Stefan Hajnoczi
---
hw/block/virtio-blk.c | 12 +++-
include/hw/virtio/virtio-blk.h | 23 ---
Am 21.05.2014 10:43, schrieb Gerd Hoffmann:
> Hi,
>
> I'm trying to put the qemu gtk ui into shape. Fixing a bunch of
> issues we have, and also make it ready for multihead support.
>
> Git tree is here:
> git://git.kraxel.org/qemu rebase/ui-gtk-next
>
> please review,
> Gerd
>
Hi Ger
Move the x-data-plane property. Originally it was outside since not
every transport may wish to support dataplane. But that makes little
sense when we have a dedicated CONFIG_VIRTIO_BLK_DATA_PLANE ifdef
already.
This move makes it easier to switch to property aliases in the next
patch.
Signed-o
Hi
Please, send any topic that you are interested in covering.
Thanks, Juan.
Call details:
15:00 CEST
13:00 UTC
09:00 EDT
Every two weeks
If you need phone number details, contact me privately.
On 21.05.14 18:03, Alexey Kardashevskiy wrote:
On 05/22/2014 01:23 AM, Alexey Kardashevskiy wrote:
Currently only single TCE entry per request is supported (H_PUT_TCE).
However PAPR+ specification allows multiple entry requests such as
H_PUT_TCE_INDIRECT and H_STUFF_TCE. Having less transitions
Il 21/05/2014 22:22, Stefan Hajnoczi ha scritto:
virtio-blk-pci, virtio-blk-s390, and virtio-blk-ccw all duplicate the
qdev properties of their VirtIOBlock child. This approach does not work
well with string or pointer properties since we must be careful about
leaking or double-freeing them.
Us
On 21.05.14 16:21, Alexey Kardashevskiy wrote:
This removes window_size as it is basically a copy of nb_table
shifted by SPAPR_TCE_PAGE_SHIFT. As new dynamic DMA windows are
going to support windows as big as the entire RAM and this number
will be bigger that 32 capacity, we will have to do some
Il 21/05/2014 22:22, Stefan Hajnoczi ha scritto:
Sometimes an object needs to present a property which is actually on
another object, or it needs to provide an alias name for an existing
property.
Examples:
a.foo -> b.foo
a.old_name -> a.new_name
The new object_property_add_alias() API allo
On 21.05.14 16:21, Alexey Kardashevskiy wrote:
At the moment only 4K pages are supported by sPAPRTCETable. Since sPAPR
spec allows other page sizes and we are going to implement them, we need
page size to be configrable.
This adds @page_shift into sPAPRTCETable and replaces SPAPR_TCE_PAGE_SHIFT
On 05/22/2014 08:11 AM, Alexander Graf wrote:
>
> On 21.05.14 16:21, Alexey Kardashevskiy wrote:
>> At the moment only 4K pages are supported by sPAPRTCETable. Since sPAPR
>> spec allows other page sizes and we are going to implement them, we need
>> page size to be configrable.
>>
>> This adds @p
On Wed, May 21, 2014 at 08:01:54PM +0100, Peter Maydell wrote:
> On 19 May 2014 10:22, Edgar E. Iglesias wrote:
> > From: "Edgar E. Iglesias"
> >
> > Add aarch64_banked_spsr_index(), used to map an Exception Level
> > to an index in the banked_spsr array.
> >
> > diff --git a/target-arm/op_helper
On Wed, May 21, 2014 at 08:06:32PM +0100, Peter Maydell wrote:
> On 19 May 2014 10:22, Edgar E. Iglesias wrote:
> > From: "Edgar E. Iglesias"
> >
> > Check for EL2 support before returning to it.
> >
> > Reviewed-by: Peter Crosthwaite
> > Signed-off-by: Edgar E. Iglesias
> > ---
> > target-arm
Hi Petar,
On Friday 16 May 2014 20:13:34 Petar Jovanovic wrote:
> From: Petar Jovanovic
>
> From MIPS documentation (Volume III):
>
> UserLocal Register (CP0 Register 4, Select 2)
> Compliance Level: Recommended.
>
> The UserLocal register is a read-write register that is not interpreted by
>
Folks -
I have been having a problem getting a usable qemu-2.0.0 (or 1.7.1, or
current GIT for that matter) build under slackware 14.1. For some
reason, the inter-thread communication hangs when built on this OS
distro, and display hangs in virt-manager as well as the gtk display in
qemu, ma
On Friday 16 May 2014 20:13:34 Petar Jovanovic wrote:
> diff --git a/target-mips/cpu.h b/target-mips/cpu.h
> index 6c2014e..bb18fb8 100644
> --- a/target-mips/cpu.h
> +++ b/target-mips/cpu.h
> @@ -227,6 +227,7 @@ struct CPUMIPSState {
> target_ulong CP0_EntryLo0;
> target_ulong CP0_EntryL
Just ping, any concern about this?
Thanks
Tiejun
> -Original Message-
> From: qemu-devel-bounces+tiejun.chen=intel@nongnu.org
> [mailto:qemu-devel-bounces+tiejun.chen=intel@nongnu.org] On Behalf Of
> Chen, Tiejun
> Sent: Wednesday, May 21, 2014 3:08 PM
> To: Gerd Hoffmann; Anthony
On Wed, May 21, 2014 at 08:20:20PM +0100, Peter Maydell wrote:
> On 19 May 2014 10:22, Edgar E. Iglesias wrote:
> > From: "Edgar E. Iglesias"
> >
> > Adds support for ERET to Aarch64 EL2 and 3.
>
> "AArch64". Also "to" here is ambiguous. The ARM ARM tries to
Changed to AArch64.
> keep the term
On Wed, May 21, 2014 at 08:10:53PM +0100, Peter Maydell wrote:
> On 19 May 2014 10:22, Edgar E. Iglesias wrote:
> > From: "Edgar E. Iglesias"
> >
> > Adds support for ERET to Aarch64 EL2 and 3.
> >
> > Signed-off-by: Edgar E. Iglesias
> > ---
> > target-arm/op_helper.c | 10 +-
> > 1 fi
On Wed, May 21, 2014 at 08:22:27PM +0100, Peter Maydell wrote:
> On 19 May 2014 10:23, Edgar E. Iglesias wrote:
> > From: "Edgar E. Iglesias"
> >
> > Signed-off-by: Edgar E. Iglesias
>
> > @@ -2356,6 +2370,12 @@ void register_cp_regs_for_features(ARMCPU *cpu)
> > }
> > if (arm_feature
On Wed, May 21, 2014 at 08:27:52PM +0100, Peter Maydell wrote:
> On 19 May 2014 10:23, Edgar E. Iglesias wrote:
> > From: "Edgar E. Iglesias"
> >
> > Avoid using IS_USER directly as the MMU-idx to simplify future
> > changes to the MMU layout.
> >
> > Signed-off-by: Edgar E. Iglesias
>
> Review
On Wed, May 21, 2014 at 08:30:30PM +0100, Peter Maydell wrote:
> On 19 May 2014 10:22, Edgar E. Iglesias wrote:
> > From: "Edgar E. Iglesias"
> >
> > Hi,
> >
> > I've been doing some work on modeling parts of EL2 and 3 + some of
> > the system-wide virtualization features for ARMv8. A lot is miss
Hi,
I think if we want to use 'device/device_add' to implement CPU,
we must do some check before qemu_init_vcpu(). how can we to do that?
Thanks,
Chen
On Tue, 2014-05-13 at 18:08 +0800, Chen Fan wrote:
> this patches tried to make cpu hotplug with device_add,
> and made -device foo-x86_64-cp
> -Original Message-
> From: Gerd Hoffmann [mailto:kra...@redhat.com]
> Sent: Wednesday, May 21, 2014 8:25 PM
> To: Gonglei (Arei)
> Cc: qemu-devel@nongnu.org
> Subject: Re: [RFC] How to deal with the conflict between DE keymap and qemu
> console ?
>
> On Mi, 2014-05-21 at 07:33 +, Gon
On 05/22/2014 04:11 AM, Tom Musta wrote:
> On 5/21/2014 1:20 AM, Alexey Kardashevskiy wrote:
>> This adds migration support for registers saved before transaction started.
>>
>> Signed-off-by: Alexey Kardashevskiy
>> ---
>> target-ppc/cpu.h | 19 +++
>> target-ppc/kvm.c |
On 05/22/2014 02:55 AM, Tom Musta wrote:
> On 5/21/2014 1:20 AM, Alexey Kardashevskiy wrote:
>> MMCR0 and MMCR1 have different numbers for 32 and 64 bit POWERPC.
>> We are going to support 64bit versions too so let's rename 32bit ones
>> to avoid confusion.
>>
>> 604 uses same SPR number for MMCR0
> -Original Message-
> From: qemu-devel-bounces+arei.gonglei=huawei@nongnu.org
> [mailto:qemu-devel-bounces+arei.gonglei=huawei@nongnu.org] On
> Behalf Of Gerd Hoffmann
> Sent: Wednesday, May 21, 2014 6:53 PM
> To: qemu-devel@nongnu.org
> Cc: Gerd Hoffmann
> Subject: [Qemu-devel] [P
On 05/21/2014 11:23 PM, Alexander Graf wrote:
>
> On 21.05.14 14:30, Alexey Kardashevskiy wrote:
>> On 05/21/2014 08:44 PM, Alexander Graf wrote:
>>> On 21.05.14 08:20, Alexey Kardashevskiy wrote:
This moves SPR initialization to helper functions.
Signed-off-by: Alexey Kardashevskiy
> -Original Message-
> From: qemu-devel-bounces+arei.gonglei=huawei@nongnu.org
> [mailto:qemu-devel-bounces+arei.gonglei=huawei@nongnu.org] On
> Behalf Of Gerd Hoffmann
> Sent: Wednesday, May 21, 2014 6:54 PM
> To: qemu-devel@nongnu.org
> Cc: Gerd Hoffmann; Anthony Liguori
> Subject
On 05/22/2014 08:11 AM, Alexander Graf wrote:
>
> On 21.05.14 16:21, Alexey Kardashevskiy wrote:
>> At the moment only 4K pages are supported by sPAPRTCETable. Since sPAPR
>> spec allows other page sizes and we are going to implement them, we need
>> page size to be configrable.
>>
>> This adds @p
201 - 300 of 317 matches
Mail list logo
