Re: [Qemu-devel] [Qemu-arm] [PATCH] cadence_gem: fix buffer overflow

+-- On Thu, 14 Jan 2016, Peter Crosthwaite wrote --+ | I guess QEMU needs the whole packet before handing off to the net layer and | the assumption is that the packet is always within 2048. The easiest | solution is to realloc the buffer as it goes with the increasing sizes. Yes, I was conside

Re: [Qemu-devel] [vfio-users] [PATCH v2 1/3] input: add qemu_input_qcode_to_linux + qemu_input_linux_to_qcode

On Fr, 2016-01-15 at 00:19 +0100, sL1pKn07 SpinFlo wrote: > ok, now works tnx Gerd! > > > but i found 2 problems, one with keyboard and other with the mouse > > Keyboard: > > the repetition (hold the key) don't work. Support used to be there, but the constant flow of key repeat events in case

Re: [Qemu-devel] [PATCH v4] qemu-char: add logfile facility to all chardev backends

On Thu, Jan 14, 2016 at 09:05:03PM -0700, Eric Blake wrote: > On 01/11/2016 05:44 AM, Daniel P. Berrange wrote: > > Typically a UNIX guest OS will log boot messages to a serial > > port in addition to any graphical console. An admin user > > may also wish to use the serial port for an interactive >

Re: [Qemu-devel] [PATCH 2/2] migration/virtio: Remove simple .get/.put use

* Sascha Silbe (si...@linux.vnet.ibm.com) wrote: > Dear David, Hi Sascha, Thanks for the mail. > "Dr. David Alan Gilbert (git)" writes: > > > The 'virtqueue_state' and 'ringsize' can be saved using VMSTATE > > macros rather than hand coded .get/.put > [...] > > @@ -1161,44 +1143,20 @@ static

Re: [Qemu-devel] [PATCH] docs/qapi-code-gen.txt: Fix simple union introspection example

Eric Blake writes: > On 01/14/2016 08:13 AM, Markus Armbruster wrote: >> The implicit tag member is named "type", not "kind". Screwed up in >> commit 39a1815. >> >> Signed-off-by: Markus Armbruster >> --- >> docs/qapi-code-gen.txt | 2 +- >> 1 file changed, 1 insertion(+), 1 deletion(-) > > R

Re: [Qemu-devel] [PATCH 2/2] xen-hvm: Clean up xen_ram_alloc() error handling

Stefano Stabellini writes: > On Thu, 14 Jan 2016, Markus Armbruster wrote: >> xen_ram_alloc() dies with hw_error() on error, even though its caller >> ram_block_add() handles errors just fine. Add an Error **errp >> parameter and use it. >> >> Leave case RUN_STATE_INMIGRATE alone, because that

[Qemu-devel] [PATCH] migration: not send zero page header in ram bulk stage

Now that VM's RAM pages are initialized to zero, (VM's RAM is allcated with the mmap() and MAP_ANONYMOUS option, or mmap() without MAP_SHARED if hugetlbfs is used.) so there is no need to send the zero page header to destination. For guest just uses a small portions of RAM, this change can avoid a

[Qemu-devel] [PATCH] target-arm: fix MMU index in arm_cpu_do_unaligned_access

arm_regime_using_lpae_format checks whether the LPAE extension is used for stage 1 translation regimes. MMU indexes not exclusively of a stage 1 regime won't work with this method. In case of ARMMMUIdx_S12NSE0 or ARMMMUIdx_S12NSE1, offset these values by ARMMMUIdx_S1NSE0 to get the right index ind

Re: [Qemu-devel] [PATCH] target-arm: fix MMU index in arm_cpu_do_unaligned_access

On 15 January 2016 at 09:59, Alvise Rigo wrote: > arm_regime_using_lpae_format checks whether the LPAE extension is used > for stage 1 translation regimes. MMU indexes not exclusively of a stage 1 > regime won't work with this method. > > In case of ARMMMUIdx_S12NSE0 or ARMMMUIdx_S12NSE1, offset t

Re: [Qemu-devel] [RFC 3/5] scripts/dump-guest-memory.py: Improve python 3 compatibility

On 01/14/2016 05:03 PM, Laszlo Ersek wrote: > On 01/14/16 09:48, Janosch Frank wrote: >> This commit does not make the script python 3 compatible, it is a >> preparation that fixes the easy and common incompatibilities. >> >> Print is a function in python 3 and therefore needs braces around its >>

[Qemu-devel] [PATCH RESEND v2 1/2] qemu-file: Fix qemu_put_compression_data flaw

Current qemu_put_compression_data can only work with no writable QEMUFile, and can't work with the writable QEMUFile. But it does not provide any measure to prevent users from using it with a writable QEMUFile. We should fix this flaw to make it works with writable QEMUFile. Signed-off-by: Liang

[Qemu-devel] [PATCH RESEND v2 2/2] migration: refine ram_save_compressed_page

Use qemu_put_compression_data to do the compression directly instead of using do_compress_ram_page, avoid some data copy. very small improvement, but the code looks better. Signed-off-by: Liang Li --- migration/ram.c | 20 1 file changed, 8 insertions(+), 12 deletions(-) di

[Qemu-devel] (no subject)

Subject: [PATCH RESEND v2 0/2] Fix flaw of qemu_put_compression_data The implementation of qemu_put_compression_data only consider the case QEMUFile is writable, it can't work with a writable QEMUFile and does not provide any measure to prevent users from using it with a writable QEMUFile. For saf

[Qemu-devel] [PATCH RESEND v2 0/2] Fix flaw of qemu_put_compression_data

The implementation of qemu_put_compression_data only consider the case QEMUFile is writable, it can't work with a writable QEMUFile and does not provide any measure to prevent users from using it with a writable QEMUFile. For safety, it should be improved to avoid some issues. ram_save_compressed_

Re: [Qemu-devel] [PATCH] migration: not send zero page header in ram bulk stage

On 2016/1/15 17:48, Liang Li wrote: Now that VM's RAM pages are initialized to zero, (VM's RAM is allcated with the mmap() and MAP_ANONYMOUS option, or mmap() without MAP_SHARED if hugetlbfs is used.) so there is no need to send the zero page header to destination. It seems that this patch is

Re: [Qemu-devel] [PATCH] migration: not send zero page header in ram bulk stage

> It seems that this patch is incorrect, if the no-zero pages are zeroed again > during !ram_bulk_stage, we didn't send the new zeroed page, there will be > an error. > If not in ram_bulk_stage, still send the header, could you explain why it's wrong? Liang > > For guest just uses a small port

Re: [Qemu-devel] [PATCH] target-arm: fix MMU index in arm_cpu_do_unaligned_access

On Fri, Jan 15, 2016 at 11:04 AM, Peter Maydell wrote: > On 15 January 2016 at 09:59, Alvise Rigo > wrote: >> arm_regime_using_lpae_format checks whether the LPAE extension is used >> for stage 1 translation regimes. MMU indexes not exclusively of a stage 1 >> regime won't work with this method.

[Qemu-devel] [PATCH v2] target-arm: Use the right MMU index in arm_regime_using_lpae_format

arm_regime_using_lpae_format checks whether the LPAE extension is used for stage 1 translation regimes. MMU indexes not exclusively of a stage 1 regime won't work with this method. In case of ARMMMUIdx_S12NSE0 or ARMMMUIdx_S12NSE1, offset these values by ARMMMUIdx_S1NSE0 to get the right index ind

[Qemu-devel] [PATCH] .travis.yml: migrate to container builds

This moves the Travis tests from their old legacy VM infrastructure (which only seems to run 5-6 jobs at once) to their new container based approach. The principle difference is there is no sudo in the containers so all packages are installed using the apt add-on. This means one of the build combi

Re: [Qemu-devel] [PATCH] migration: not send zero page header in ram bulk stage

On 15/01/2016 10:48, Liang Li wrote: > Now that VM's RAM pages are initialized to zero, (VM's RAM is allcated > with the mmap() and MAP_ANONYMOUS option, or mmap() without MAP_SHARED > if hugetlbfs is used.) so there is no need to send the zero page header > to destination. > > For guest just us

[Qemu-devel] [PATCH 00/10] Cleanups to error reporting on ppc and spapr (v2)

Here's a new spin of my patches to clean up a bunch of error reporting in the pseries machine type and target-ppc code, to better use the error API. Once reviewed, I hope to merge this into ppc-for-2.6 shortly. Changes in v2: * Assorted minor tweaks based on review David Gibson (10): ppc: Cle

[Qemu-devel] [PATCH 06/10] pseries: Improve error handling in find_unknown_sysbus_device()

Use error_setg() to return an error instead of using an explicit exit(). Signed-off-by: David Gibson --- hw/ppc/spapr.c | 10 ++ 1 file changed, 6 insertions(+), 4 deletions(-) diff --git a/hw/ppc/spapr.c b/hw/ppc/spapr.c index bb5eaa5..ddca6e6 100644 --- a/hw/ppc/spapr.c +++ b/hw/ppc/s

[Qemu-devel] [PATCH 01/10] ppc: Cleanup error handling in ppc_set_compat()

Current ppc_set_compat() returns -1 for errors, and also (unconditionally) reports an error message. The caller in h_client_architecture_support() may then report it again using an outdated fprintf(). Clean this up by using the modern error reporting mechanisms. Signed-off-by: David Gibson Revi

[Qemu-devel] [PATCH 03/10] pseries: Clean up hash page table allocation error handling

The spapr_alloc_htab() and spapr_reset_htab() functions currently handle all errors with error_setg(&error_abort, ...). But really, the callers are really better placed to decide on the error handling. So, instead make the functions use the error propagation infrastructure. In the callers we cha

[Qemu-devel] [PATCH 05/10] pseries: Cleanup error handling in spapr_vga_init()

Use error_setg() to return an error rather than an explicit exit(). Previously it was an exit(0) instead of a non-zero exit code, which was simply a bug. Also improve the error message. While we're at it change the type of spapr_vga_init() to bool since that's how we're using it anyway. Signed-o

[Qemu-devel] [PATCH 08/10] pseries: Clean up error handling in xics_system_init()

Use the error handling infrastructure to pass an error out from try_create_xics() instead of assuming &error_abort - the caller is in a better position to decide on error handling policy. Also change the error handling from an &error_abort to &error_fatal, since this occurs during the initial mach

[Qemu-devel] [PATCH 10/10] pseries: Clean up error reporting in htab migration functions

The functions for migrating the hash page table on pseries machine type (htab_save_setup() and htab_load()) can report some errors with an explicit fprintf() before returning an appropriate error code. Change these to use error_report() instead. Signed-off-by: David Gibson Reviewed-by: Thomas Hu

[Qemu-devel] [PATCH 04/10] pseries: Clean up error handling in spapr_validate_node_memory()

Use error_setg() and return an error, rather than using an explicit exit(). Also improve messages, and be more explicit about which constraint failed. Signed-off-by: David Gibson Reviewed-by: Bharata B Rao --- hw/ppc/spapr.c | 37 ++--- 1 file changed, 22 insert

[Qemu-devel] [PATCH 07/10] pseries: Clean up error handling in spapr_rtas_register()

The errors detected in this function necessarily indicate bugs in the rest of the qemu code, rather than an external or configuration problem. So, a simple assert() is more appropriate than any more complex error reporting. Signed-off-by: David Gibson --- hw/ppc/spapr_rtas.c | 12 +++-

[Qemu-devel] [PATCH 09/10] pseries: Clean up error reporting in ppc_spapr_init()

This function includes a number of explicit fprintf()s for errors. Change these to use error_report() instead. Also replace the single exit(EXIT_FAILURE) with an explicit exit(1), since the latter is the more usual idiom in qemu by a large margin. Signed-off-by: David Gibson --- hw/ppc/spapr.c

Re: [Qemu-devel] [PATCH 2/2] migration/virtio: Remove simple .get/.put use

Hi Sascha, Can you try this and let me know if it fixes it for you; I've still not managed to persuade x86-64 to fail. Dave From f300fa0dd902b28417744d364986c71dd8357a88 Mon Sep 17 00:00:00 2001 From: "Dr. David Alan Gilbert" Date: Fri, 15 Jan 2016 11:02:02 + Subject: [PATCH] Fix virito m

[Qemu-devel] [PATCH 02/10] pseries: Cleanup error handling of spapr_cpu_init()

Currently spapr_cpu_init() is hardcoded to handle any errors as fatal. That works for now, since it's only called from initial setup where an error here means we really can't proceed. However, we'll want to handle this more flexibly for cpu hotplug in future so generalize this using the error repo

[Qemu-devel] [PATCHv3 3/4] Allow ISA bus to be configured out

Currently, the code to handle the legacy ISA bus is always included in qemu. However there are lots of platforms that don't include ISA legacy devies, and quite a few that have never used ISA legacy devices at all. This patch allows the ISA bus code to be disabled in the configuration for platfor

[Qemu-devel] [PATCHv3 4/4] Split ISA and sysbus versions of m48t59 device

The m48t59 device supports both ISA and direct sysbus attached versions of the device in the one .c file. This can be awkward for some embedded machine types which need the sysbus M48T59, but don't want to pull in the ISA bus code and its other dependencies. Therefore, this patch splits out the c

[Qemu-devel] [PATCHv3 0/4] Start allowing ISA to be configured out

Finally got around to respinning this series I last sent out ~6 months ago. At the moment isa-bus.c is compiled unconditionally for all targets. However, some targets have never used legacy ISA devices. Many more targets have at least some machine types without ISA. These patches allow ISA bus t

[Qemu-devel] [PATCHv3 1/4] Cleanup leftover CONFIG_ISA_MMIO

Commit 61fcb62 "isa_mmio: delete" removed the CONFIG_ISA_MMIO switch and the isa_mmio code controlled by it. However, a few of the default-configs still set the variable, pointlessly. This cleans these up. Signed-off-by: David Gibson Reviewed-by: Peter Maydell --- default-configs/arm-softmmu

[Qemu-devel] [PATCHv3 2/4] Split serial-isa into its own config option

At present, the core device model code for 8250-like serial ports (serial.c) and the code for serial ports attached to ISA-style legacy IO (serial-isa.c) are both controlled by the CONFIG_SERIAL variable. There are lots and lots of embedded platforms that have 8250-like serial ports but have never

[Qemu-devel] [PATCH 00/10] virtio/vring: optimization patches

This includes two optimization of virtio: - "slimming down" VirtQueueElements by not including room for 1024 buffers. This makes malloc much faster. - optimizations to limit the number of address_space_translate calls in virtio.c from Vincenzo and myself. Thanks, Paolo Paolo Bonzini (7):

[Qemu-devel] [PATCH 01/10] virtio: move VirtQueueElement at the beginning of the structs

The next patch will make virtqueue_pop/vring_pop allocate memory for a "subclass" of VirtQueueElement. For this to work, VirtQueueElement must be the first field in the containing struct. Signed-off-by: Paolo Bonzini --- hw/scsi/virtio-scsi.c | 3 +-- include/hw/virtio/virtio-blk.h

[Qemu-devel] [PATCH 05/10] virtio: slim down allocation of VirtQueueElements

Build the addresses and s/g lists on the stack, and then copy them to a VirtQueueElement that is just as big as required to contain this particular s/g list. The cost of the copy is minimal compared to that of a large malloc. When virtqueue_map is used on the destination side of migration or on l

[Qemu-devel] [PATCH 03/10] virtio: introduce qemu_get/put_virtqueue_element

Move allocation to virtio functions also when loading/saving a VirtQueueElement. This will also let the load/save functions keep backwards compatibility when the VirtQueueElement layout is changed. Signed-off-by: Paolo Bonzini --- hw/block/virtio-blk.c | 10 +++--- hw/char/virtio-seri

[Qemu-devel] [PATCH 10/10] virtio: combine write of an entry into used ring

From: Vincenzo Maffione Fill in an element of the used ring with a single combined access to the guest physical memory, rather than using two separated accesses. This reduces the overhead due to expensive address translation. Signed-off-by: Vincenzo Maffione Message-Id: Signed-off-by: Paolo B

[Qemu-devel] [PATCH 04/10] virtio: introduce virtqueue_alloc_element

Allocate the arrays for in_addr/out_addr/in_sg/out_sg outside the VirtQueueElement. For now, virtqueue_pop and vring_pop keep allocating a very large VirtQueueElement. Signed-off-by: Paolo Bonzini --- hw/virtio/dataplane/vring.c | 2 +- hw/virtio/virtio.c | 109 ++

[Qemu-devel] [PATCH 02/10] virtio: move allocation to virtqueue_pop/vring_pop

The return code of virtqueue_pop/vring_pop is unused except to check for errors or 0. We can thus easily move allocation inside the functions and just return a pointer to the VirtQueueElement. The advantage is that we will be able to allocate only the space that is needed for the actual size of t

[Qemu-devel] [PATCH 08/10] virtio: cache used_idx in a VirtQueue field

From: Vincenzo Maffione Accessing used_idx in the VQ requires an expensive access to guest physical memory. Before this patch, 3 accesses are normally done for each pop/push/notify call. However, since the used_idx is only written by us, we can track it in our internal data structure. Signed-off

[Qemu-devel] [PATCH 06/10] vring: slim down allocation of VirtQueueElements

Build the addresses and s/g lists on the stack, and then copy them to a VirtQueueElement that is just as big as required to contain this particular s/g list. The cost of the copy is minimal compared to that of a large malloc. Signed-off-by: Paolo Bonzini --- hw/virtio/dataplane/vring.c | 53 +++

[Qemu-devel] [PATCH 09/10] virtio: read avail_idx from VQ only when necessary

From: Vincenzo Maffione The virtqueue_pop() implementation needs to check if the avail ring contains some pending buffers. To perform this check, it is not always necessary to fetch the avail_idx in the VQ memory, which is expensive. This patch introduces a shadow variable tracking avail_idx and

[Qemu-devel] [PATCH 07/10] virtio: combine the read of a descriptor

Compared to vring, virtio has a performance penalty of 10%. Fix it by combining all the reads for a descriptor in a single address_space_read call. This also simplifies the code nicely. Signed-off-by: Paolo Bonzini --- hw/virtio/virtio.c | 86 ++-

Re: [Qemu-devel] [PATCH 12/25] target-sparc: Add MMU_REAL_IDX

Hi Richard, please ignore my 2 previous mails: I've misread the commit message. The actual problem and a possible solution below. On Thu, Dec 17, 2015 at 9:57 PM, Richard Henderson wrote: > This gives us a trivial way to access physical addresses > (aka "real addresses", in sun4v terminology) I

[Qemu-devel] [Minios-devel] [PATCH v8 0/] Begin to disentangle libxenctrl and provide some stable libraries

In <1431963008.4944.80.ca...@citrix.com> I proposed stabilising some parts of the libxenctrl API/ABI by disaggregating into separate libraries. This is v8 of that set of series against: xen qemu-xen qemu-xen-traditional mini-os NB: Samuel+minios-devel will only get the mini-os sid

[Qemu-devel] [PATCH QEMU-XEN v8 0/8] Begin to disentangle libxenctrl and provide some stable libraries

We intend to stabilise some parts of the libxenctrl interface by splitting out some functionality into separate stable libraries. This is the qemu-xen part of the first phase of that change. This mail is (or is intended to be) a reply to a "0/" super-intro mail covering all of the related patch s

[Qemu-devel] [PATCH QEMU-XEN v8 2/8] xen: Switch to libxenevtchn interface for compat shims.

In Xen 4.7 we are refactoring parts libxenctrl into a number of separate libraries which will provide backward and forward API and ABI compatiblity. One such library will be libxenevtchn which provides access to event channels. In preparation for this switch the compatibility layer in xen_common.

[Qemu-devel] [PATCH QEMU-XEN v8 5/8] xen: Switch uses of xc_map_foreign_{pages, bulk} to use libxenforeignmemory API.

In Xen 4.7 we are refactoring parts libxenctrl into a number of separate libraries which will provide backward and forward API and ABI compatiblity. One such library will be libxenforeignmemory which provides access to privileged foreign mappings and which will provide an interface equivalent to x

[Qemu-devel] [PATCH QEMU-XEN v8 1/8] xen_console: correctly cleanup primary console on teardown.

All of the work in con_disconnect applies to the primary console case (when xendev->dev is NULL). Therefore remove the early check and bail and allow it to fall through. All of the existing code is correctly conditional already. The ->dev and ->gnttabdev handles are either both set or neither. For

[Qemu-devel] [PATCH QEMU-XEN v8 6/8] xen: Use stable library interfaces when they are available.

In Xen 4.7 we are refactoring parts libxenctrl into a number of separate libraries which will provide backward and forward API and ABI compatiblity. Specifically libxenevtchn, libxengnttab and libxenforeignmemory. Previous patches have already laid the groundwork for using these by switching the

[Qemu-devel] [PATCH QEMU-XEN v8 4/8] xen: Switch uses of xc_map_foreign_range into xc_map_foreign_pages

In Xen 4.7 we are refactoring parts libxenctrl into a number of separate libraries which will provide backward and forward API and ABI compatiblity. One such library will be libxenforeignmemory which provides access to privileged foreign mappings and which will provide an interface equivalent to x

[Qemu-devel] [PATCH QEMU-XEN v8 8/8] xen: make it possible to build without the Xen PV domain builder

Until the previous patch this relied on xc_fd(), which was only implemented for Xen 4.0 and earlier. Given this wasn't working since Xen 4.0 I have marked this as disabled by default. Removing this support drops the use of a bunch of symbols from libxenctrl, specifically: - xc_domain_create

[Qemu-devel] [PATCH QEMU-XEN v8 3/8] xen: Switch to libxengnttab interface for compat shims.

In Xen 4.7 we are refactoring parts libxenctrl into a number of separate libraries which will provide backward and forward API and ABI compatiblity. One such library will be libxengnttab which provides access to grant tables. In preparation for this switch the compatibility layer in xen_common.h

[Qemu-devel] [PATCH QEMU-XEN v8 7/8] xen: domainbuild: reopen libxenctrl interface after forking for domain watcher.

Using an existing libxenctrl handle after a fork was never particularly safe (especially if foreign mappings existed at the time of the fork) and the xc fd has been unavailable for many releases. Reopen the handle after fork and therefore do away with xc_fd(). Signed-off-by: Ian Campbell Acked-b

Re: [Qemu-devel] [PATCH 03/51] qapi: qapi for audio backends

Hi, > My pending patches will also allow an anonymous base class, so that we > don't have to specify an intermediate AudiodevCommonOptions class. Not > a show-stopper, though. > > Overall looks rather sane (I think we've done the bulk of the reviewing > last summer), although I didn't read it

Re: [Qemu-devel] [PATCH 00/51] audio 5.1 patches

On Do, 2016-01-14 at 14:45 +0100, Kővágó, Zoltán wrote: > Hi, > > Sorry guys, I've disappeared for a while... No problem. qapi changes still pending anyway ... I'll try to sort with Eric how we'll handle the qapi bits best. > But anyways, I've updated > my 5.1 audio patches to git master. Tha

Re: [Qemu-devel] [V3 3/4] hw/i386: ACPI table for AMD IO MMU

Hi all, I think, from coreboot code, the MMIO reservation is done through an MCFG table. I can't see one in Qemu but I don't have a clue how to extend it. There's literally nothing about MCFG online neither do I have an org that's a member of pcisig. Could someone have the docs describing MCFG ?

Re: [Qemu-devel] Status of my hacks on the MTTCG WIP branch

Pranith Kumar writes: > Hi Alex, > > On Tue, Jan 12, 2016 at 12:29 PM, Alex Bennée > wrote: > >> > https://github.com/stsquad/qemu/tree/mttcg/multi_tcg_v8_wip_ajb_fix_locks >> > > I built this branch and ran an arm64 guest. It seems to be failing > similarly to what I reported earlier: Hi Pran

[Qemu-devel] [RFC][PATCH v3 ] utils: Improve and document error reporting

Adds support for reporting non-terminating errors (dubbed warnings), and briefly documents what routines should developers generally use to keep error reporting consistent. Changes in v3 = * Drop special object 'error_warn' in favour of raw 'error_report()' [suggested by Markus Armb

[Qemu-devel] [PATCH v3 ] doc: Introduce coding style for errors

Gives some general guidelines for reporting errors in QEMU. Signed-off-by: Lluís Vilanova --- HACKING | 36 1 file changed, 36 insertions(+) diff --git a/HACKING b/HACKING index 12fbc8a..1523bad 100644 --- a/HACKING +++ b/HACKING @@ -157,3 +157,39 @@ painf

Re: [Qemu-devel] [PATCH v2] target-arm: Use the right MMU index in arm_regime_using_lpae_format

On 15 January 2016 at 10:37, Alvise Rigo wrote: > arm_regime_using_lpae_format checks whether the LPAE extension is used > for stage 1 translation regimes. MMU indexes not exclusively of a stage 1 > regime won't work with this method. > > In case of ARMMMUIdx_S12NSE0 or ARMMMUIdx_S12NSE1, offset t

[Qemu-devel] [PATCH v3] ARM: Virt: Don't generate RTC ACPI device when using UEFI

When booting the VM with UEFI, UEFI takes ownership of the RTC hardware. While UEFI can use libfdt to disable the RTC device node in the DTB that it passes to the OS, it cannot modify AML. Therefore, we won't generate the RTC ACPI device at all when using UEFI. Signed-off-by: Shannon Zhao Acked-b

Re: [Qemu-devel] [PATCH 2/2] xen-hvm: Clean up xen_ram_alloc() error handling

On Fri, 15 Jan 2016, Markus Armbruster wrote: > Stefano Stabellini writes: > > > On Thu, 14 Jan 2016, Markus Armbruster wrote: > >> xen_ram_alloc() dies with hw_error() on error, even though its caller > >> ram_block_add() handles errors just fine. Add an Error **errp > >> parameter and use it.

Re: [Qemu-devel] [PATCH v5 0/5] Xen PCI passthru: Convert to realize()

On Thu, 14 Jan 2016, Eric Blake wrote: > On 01/14/2016 09:50 AM, Stefano Stabellini wrote: > > Eric, > > > > I'll wait for your reviewed-by on the whole series before committing. > > Found a bug in 2/5, up to you if you want to fix that or wait for a v6. If Cao is happy to update and resend, I'l

Re: [Qemu-devel] [PATCH v2] gdb: provide the name of the architecture in the target.xml

On 14 January 2016 at 14:27, Christian Borntraeger wrote: > Ping? > > On 12/03/2015 01:14 PM, Christian Borntraeger wrote: >> From: David Hildenbrand >> >> This patch provides the name of the architecture in the target.xml >> if available. >> >> This allows the remote gdb to detect the target arc

Re: [Qemu-devel] [PATCH v3] ARM: Virt: Don't generate RTC ACPI device when using UEFI

On Fri, Jan 15, 2016 at 10:11:31PM +0800, Shannon Zhao wrote: > When booting the VM with UEFI, UEFI takes ownership of the RTC hardware. > While UEFI can use libfdt to disable the RTC device node in the DTB that > it passes to the OS, it cannot modify AML. Therefore, we won't generate > the RTC ACP

[Qemu-devel] virtio-blk-dataplane performance numbers

Hi, I made some measurements guest vs bare metal (using virtio-data-plane) and got some results I cannot fully explain. First some details about the setup: - I have an ARM v8 hardware + 1 SSD connected to SATA. I have run FIO using multiple block sizes and IO depths: for i in 1 2 4 8 16 32 do

Re: [Qemu-devel] [PATCH RESEND] softfloat: fix return type of roundAndPackFloat16

On 13 January 2016 at 16:03, Aurelien Jarno wrote: > The roundAndPackFloat16 function should return a float16 value, not a > float32 one. Fix that. > > Cc: Peter Maydell > Signed-off-by: Aurelien Jarno > --- > fpu/softfloat.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > Peter, gi

Re: [Qemu-devel] Status of my hacks on the MTTCG WIP branch

Hi Alex, On Fri, Jan 15, 2016 at 8:53 AM, Alex Bennée wrote: > Can you try this branch: > > https://github.com/stsquad/qemu/tree/mttcg/multi_tcg_v8_wip_ajb_fix_locks-r1 > > I think I've caught all the things likely to screw up addressing. > I tried this branch and the boot hangs like follows: [

Re: [Qemu-devel] [PATCH v4 1/2] blockdev: Error out on negative throttling option values

Fam Zheng writes: > The implicit casting from unsigned int to double changes negative values > into large positive numbers and accepts them. We should instead print > an error. --verbose: * extract_common_blockdev_options() uses qemu_opt_get_number() to parse the number to uint64_t, then con

Re: [Qemu-devel] [PATCH v4 1/2] blockdev: Error out on negative throttling option values

Am 15.01.2016 um 03:09 hat Fam Zheng geschrieben: > The implicit casting from unsigned int to double changes negative values > into large positive numbers and accepts them. We should instead print > an error. > > Check the number range so this case is caught and reported. > > Signed-off-by: Fam

Re: [Qemu-devel] Status of my hacks on the MTTCG WIP branch

Le 15/01/2016 15:24, Pranith Kumar a écrit : Hi Alex, On Fri, Jan 15, 2016 at 8:53 AM, Alex Bennée > wrote: > Can you try this branch: > > https://github.com/stsquad/qemu/tree/mttcg/multi_tcg_v8_wip_ajb_fix_locks-r1 > > I think I've caught all the things likel

Re: [Qemu-devel] Status of my hacks on the MTTCG WIP branch

This problem could be related to a missing multi-threaded aware translation of the atomic instructions. I'm working on this missing piece, probably the next week I will publish something. Regards, alvise On Fri, Jan 15, 2016 at 3:24 PM, Pranith Kumar wrote: > Hi Alex, > > On Fri, Jan 15, 2016 at

Re: [Qemu-devel] [PATCH v2] ARM: Virt: Don't generate RTC ACPI device when using UEFI

On 13 January 2016 at 16:26, Laszlo Ersek wrote: > On 01/13/16 17:16, Andrew Jones wrote: >> On Wed, Jan 13, 2016 at 10:54:17PM +0800, Shannon Zhao wrote: >>> When booting the VM with UEFI, UEFI takes ownership of the RTC hardware. >>> While UEFI can use libfdt to disable the RTC device node in th

Re: [Qemu-devel] [PATCH v5 1/1] xlnx-zynqmp: Add support for high DDR memory regions

On 12 January 2016 at 22:39, Alistair Francis wrote: > The Xilinx ZynqMP SoC and EP108 board supports three memory regions: > - A 2GB region starting at 0 > - A 32GB region starting at 32GB > - A 256GB region starting at 768GB > > This patch adds support for the first two memory regions, which

Re: [Qemu-devel] [PATCH v2] ARM: Virt: Don't generate RTC ACPI device when using UEFI

On 2016/1/15 22:34, Peter Maydell wrote: On 13 January 2016 at 16:26, Laszlo Ersek wrote: >On 01/13/16 17:16, Andrew Jones wrote: >>On Wed, Jan 13, 2016 at 10:54:17PM +0800, Shannon Zhao wrote: >>>When booting the VM with UEFI, UEFI takes ownership of the RTC hardware. >>>While UEFI can use

Re: [Qemu-devel] [PATCH 1/8] target-arm: Properly support EL2 and EL3 in arm_el_is_aa64()

On Thu, Jan 14, 2016 at 06:34:04PM +, Peter Maydell wrote: > Support EL2 and EL3 in arm_el_is_aa64() by implementing the > logic for checking the SCR_EL3 and HCR_EL2 register-width bits > as appropriate to determine the register width of lower exception > levels. > > Signed-off-by: Peter Mayde

Re: [Qemu-devel] [PATCH 2/8] target-arm: Move aarch64_cpu_do_interrupt() to helper.c

On Thu, Jan 14, 2016 at 06:34:05PM +, Peter Maydell wrote: > Move the aarch64_cpu_do_interrupt() function to helper.c. We want > to be able to call this from code that isn't AArch64-only, and > the move allows us to avoid awkward #ifdeffery at the callsite. > > Signed-off-by: Peter Maydell R

Re: [Qemu-devel] [PATCH v4 0/8] target-arm: enable qmp-dump-guest-memory

On 11 January 2016 at 19:56, Andrew Jones wrote: > This series brings qmp-dump-guest-memory to arm and aarch64 > targets. I've detailed my testing and the results in the > following table. > > v4: > - drop aarch64_compat_sp in favor of fixing crash[*] [Peter] > - added more Peter r-b's (fix 1 ni

Re: [Qemu-devel] [PATCH QEMU-XEN v8 5/8] xen: Switch uses of xc_map_foreign_{pages, bulk} to use libxenforeignmemory API.

On Fri, 15 Jan 2016, Ian Campbell wrote: > In Xen 4.7 we are refactoring parts libxenctrl into a number of > separate libraries which will provide backward and forward API and ABI > compatiblity. > > One such library will be libxenforeignmemory which provides access to > privileged foreign mapping

Re: [Qemu-devel] [PATCH QEMU-XEN v8 6/8] xen: Use stable library interfaces when they are available.

On Fri, 15 Jan 2016, Ian Campbell wrote: > In Xen 4.7 we are refactoring parts libxenctrl into a number of > separate libraries which will provide backward and forward API and ABI > compatiblity. > > Specifically libxenevtchn, libxengnttab and libxenforeignmemory. > > Previous patches have alread

Re: [Qemu-devel] [PATCH QEMU-XEN v8 0/8] Begin to disentangle libxenctrl and provide some stable libraries

What's the status of the libxc side changes? Is the interface stable enough for me to commit this series? On Fri, 15 Jan 2016, Ian Campbell wrote: > We intend to stabilise some parts of the libxenctrl interface by > splitting out some functionality into separate stable libraries. > > This is the

Re: [Qemu-devel] Status of my hacks on the MTTCG WIP branch

KONRAD Frederic writes: > Le 15/01/2016 15:24, Pranith Kumar a écrit : >> Hi Alex, >> >> On Fri, Jan 15, 2016 at 8:53 AM, Alex Bennée > > wrote: >> > Can you try this branch: >> > >> > >> https://github.com/stsquad/qemu/tree/mttcg/multi_tcg_v8_wip_ajb_fix_locks-r1

Re: [Qemu-devel] Status of my hacks on the MTTCG WIP branch

Le 15/01/2016 15:46, Alex Bennée a écrit : KONRAD Frederic writes: Le 15/01/2016 15:24, Pranith Kumar a écrit : Hi Alex, On Fri, Jan 15, 2016 at 8:53 AM, Alex Bennée mailto:alex.ben...@linaro.org>> wrote: Can you try this branch: https://github.com/stsquad/qemu/tree/mttcg/multi_tcg_v8_

Re: [Qemu-devel] [PATCH 1/8] target-arm: Properly support EL2 and EL3 in arm_el_is_aa64()

On 15 January 2016 at 14:38, Edgar E. Iglesias wrote: > On Thu, Jan 14, 2016 at 06:34:04PM +, Peter Maydell wrote: >> Support EL2 and EL3 in arm_el_is_aa64() by implementing the >> logic for checking the SCR_EL3 and HCR_EL2 register-width bits >> as appropriate to determine the register width

Re: [Qemu-devel] Status of my hacks on the MTTCG WIP branch

alvise rigo writes: > This problem could be related to a missing multi-threaded aware > translation of the atomic instructions. > I'm working on this missing piece, probably the next week I will > publish something. Maybe. We still have Fred's: Use atomic cmpxchg to atomically check the excl

Re: [Qemu-devel] [PATCH v3] ARM: Virt: Don't generate RTC ACPI device when using UEFI

On 15 January 2016 at 14:11, Shannon Zhao wrote: > When booting the VM with UEFI, UEFI takes ownership of the RTC hardware. > While UEFI can use libfdt to disable the RTC device node in the DTB that > it passes to the OS, it cannot modify AML. Therefore, we won't generate > the RTC ACPI device at

Re: [Qemu-devel] [PATCH 3/8] target-arm: Use a single entry point for AArch64 and AArch32 exceptions

On Thu, Jan 14, 2016 at 06:34:06PM +, Peter Maydell wrote: > If EL2 or EL3 is present on an AArch64 CPU, then exceptions can be > taken to an exception level which is running AArch32 (if only EL0 > and EL1 are present then EL1 must be AArch64 and all exceptions are > taken to AArch64). To suppo

Re: [Qemu-devel] [PATCH v4 5/8] target-arm: support QMP dump-guest-memory

On 11 January 2016 at 19:56, Andrew Jones wrote: > Add the support needed for creating prstatus elf notes. This > allows us to use QMP dump-guest-memory. > > Signed-off-by: Andrew Jones > --- > target-arm/Makefile.objs | 3 +- > target-arm/arch_dump.c | 230 > +++

[Qemu-devel] [PATCH 2/7] target-ppc: rename and export maybe_bswap_register()

This helper will be used to support FP, Altivec and VSX registers when the guest is little-endian. Signed-off-by: Greg Kurz --- target-ppc/cpu.h |1 + target-ppc/gdbstub.c | 10 +- 2 files changed, 6 insertions(+), 5 deletions(-) diff --git a/target-ppc/cpu.h b/target-ppc/cpu.

[Qemu-devel] [PATCH 0/7] target-ppc: gdbstub: endiannes fixes and VSX support

Hi, This series was posted before last Xmas. Since I am not sure if Alex is available to handle this, and this affects ppc64le (hence most people running sPAPR guests), I repost with David Gibson added to the Cc: list. This series is a sequel to Anton's tentative at bringing VSX support in our gd

[Qemu-devel] [PATCH 1/7] target-ppc: kvm: fix floating point registers sync on little-endian hosts

On VSX capable CPUs, the 32 FP registers are mapped to the high-bits of the 32 first VSX registers. So if you have: VSR31 = (uint128) 0x0102030405060708090a0b0c0d0e0f00 then FPR31 = (uint64) 0x0102030405060708 The kernel stores the VSX registers in the fp_state struct following the host endian

[Qemu-devel] [PATCH 5/7] target-ppc: gdbstub: fix altivec registers for little-endian guests

Altivec registers are 128-bit wide. They are stored in memory as two 64-bit values that must be byteswapped when the guest is little-endian. Let's reuse the ppc_maybe_bswap_register() helper for this. We also need to fix the ordering of the 64-bit elements according to the target endianness, for b

[Qemu-devel] [PATCH 3/7] target-ppc: gdbstub: fix float registers for little-endian guests

Let's reuse the ppc_maybe_bswap_register() helper, like we already do with the general registers. Signed-off-by: Greg Kurz --- target-ppc/translate_init.c |4 1 file changed, 4 insertions(+) diff --git a/target-ppc/translate_init.c b/target-ppc/translate_init.c index e88dc7fc7aa3..d31d

[Qemu-devel] [PATCH 4/7] target-ppc: gdbstub: introduce avr_need_swap()

This helper will be used to support Altivec registers in little-endian guests. This patch does not change functionnality. Note: I had to put the helper some lines away from the gdb_*_avr_reg() routines to get a more readable patch. Signed-off-by: Greg Kurz --- target-ppc/translate_init.c | 37

  1   2   3   >