[Qemu-devel] [PATCHv2 3/8] spapr: Simplify unplug path

spapr_lmb_release() and spapr_core_release() call hotplug_handler_unplug() which after a bunch of indirection calls spapr_memory_unplug() or spapr_core_unplug(). But we already know which is the appropriate thing to call here, so we can just fold it directly into the release function. Once

[Qemu-devel] [PATCHv2 6/8] spapr: Consolidate DRC state variables

Each DRC has three fields describing its state: isolation_state, allocation_state and configured. At first this seems like a reasonable representation, since its based directly on the PAPR defined isolation-state and allocation-state indicators. However: * Only a few combinations of the two

[Qemu-devel] [PATCHv2 4/8] spapr: Refactor spapr_drc_detach()

This function has two unused parameters - remove them. It also sets awaiting_release on all paths, except one. On that path setting it is harmless, since it will be immediately cleared by spapr_drc_release(). So factor it out of the if statements. Signed-off-by: David Gibson

[Qemu-devel] [PATCHv2 2/8] spapr: Remove 'awaiting_allocation' DRC flag

The awaiting_allocation flag in the DRC was introduced by aab9913 "spapr_drc: Prevent detach racing against attach for CPU DR", allegedly to prevent a guest crash on racing attach and detach. Except.. information from the BZ actually suggests a qemu crash, not a guest crash. And there shouldn't

[Qemu-devel] [PATCHv2 1/8] spapr: Treat devices added before inbound migration as coldplugged

From: Laurent Vivier When migrating a guest which has already had devices hotplugged, libvirt typically starts the destination qemu with -incoming defer, adds those hotplugged devices with qmp, then initiates the incoming migration. This causes problems for the management of

[Qemu-devel] [PATCHv2 0/8] spapr: DRC cleanups (part VI)

This sixth set of DRC cleanup patches is a complete rework of DRC state management. We stop tracking some unnecessary things, and change the basic state representation to a simpler and more robust model. Many of the patches in this set "break" migration from earlier git snapshots, but not from

[Qemu-devel] [PATCHv2 7/8] spapr: Remove sPAPRConfigureConnectorState sub-structure

Most of the time, the state of a DRC object is contained in the single 'state' variable. However, during the transition from UNISOLATE to CONFIGURED state requires multiple calls to the ibm,configure-connector RTAS call to retrieve the device tree for the attached device. We need some extra

[Qemu-devel] [PATCHv2 5/8] spapr: Cleanups relating to DRC awaiting_release field

'awaiting_release' indicates that the host has requested an unplug of the device attached to the DRC, but the guest has not (yet) put the device into a state where it is safe to complete removal. 1. Rename it to 'unplug_requested' which to me at least is clearer 2. Remove the ->release_pending()

[Qemu-devel] [PATCHv2 8/8] spapr: Implement DR-indicator for physical DRCs only

According to PAPR, the DR-indicator should only be valid for physical DRCs, not logical DRCs. At the moment we implement it for all DRCs, so restrict it to physical ones only. We move the state to the physical DRC subclass, which means adding some QOM boilerplate to handle the newly distinct

Re: [Qemu-devel] change x86 default machine type to Q35?

Hi, > > I think simply not having a default > > machine type (as already suggested elsewhere in this thread) is the > > best way to deal with this. > > I would absolutely hate this. One of the nice things about qemu has > always been that 'qemu disk.img' is enough to start a simple VM. Well,

Re: [Qemu-devel] [PATCH] tcg: move atomic_template.h to accel/tcg/

On 11.07.2017 20:55, Philippe Mathieu-Daudé wrote: > Signed-off-by: Philippe Mathieu-Daudé > --- > same as Thomas previous patch. this file had no entry in MAINTAINERS. > > atomic_template.h => accel/tcg/atomic_template.h | 0 > 1 file changed, 0 insertions(+), 0 deletions(-) >

Re: [Qemu-devel] [PATCH 0/2] target/i386: Implement all TBM instructions

On 07/11/2017 11:21 AM, Richard Henderson wrote: I am in the process of trying to run the gcc testsuite with -mtbm, with and without the patchset, to see (1) if the new insns get used and (2) that they run ok. FWIW, make check-gcc RUNTESTFLAGS='--target_board=unix/-mtbm execute.exp' shows 204

Re: [Qemu-devel] [RFC v2 0/8] VIRTIO-IOMMU device

> -Original Message- > From: Jean-Philippe Brucker [mailto:jean-philippe.bruc...@arm.com] > Sent: Tuesday, July 11, 2017 6:21 PM > To: Bharat Bhushan ; Auger Eric > ; eric.auger@gmail.com; > peter.mayd...@linaro.org;

Re: [Qemu-devel] [PATCH 5/5] migration/rdma: Send error during cancelling

On Tue, Jul 04, 2017 at 07:49:15PM +0100, Dr. David Alan Gilbert (git) wrote: > From: "Dr. David Alan Gilbert" > > When we issue a cancel and clean up the RDMA channel > send a CONTROL_ERROR to get the destination to quit. > > The rdma_cleanup code waits for the event to

Re: [Qemu-devel] [PATCH 4/5] migration/rdma: Safely convert control types

On Tue, Jul 04, 2017 at 07:49:14PM +0100, Dr. David Alan Gilbert (git) wrote: > From: "Dr. David Alan Gilbert" > > control_desc[] is an array of strings that correspond to a > series of message types; they're used only for error messages, but if > the message type is

Re: [Qemu-devel] [PATCH 2/5] migration: Close file on failed migration load

On Tue, Jul 04, 2017 at 07:49:12PM +0100, Dr. David Alan Gilbert (git) wrote: > From: "Dr. David Alan Gilbert" > > Closing the file before exit on a failure allows > the source to cleanup better, especially with RDMA. > > Partial fix for

Re: [Qemu-devel] [PATCH 1/5] migration/rdma: Fix race on source

On Tue, Jul 04, 2017 at 07:49:11PM +0100, Dr. David Alan Gilbert (git) wrote: > From: "Dr. David Alan Gilbert" > > Fix a race where the destination might try and send the source a > WRID_READY before the source has done a post-recv for it. > > rdma_post_recv has to happen

Re: [Qemu-devel] [PATCH v3 2/6] block: Add VFIO based NVMe driver

On Mon, 07/10 15:55, Stefan Hajnoczi wrote: > On Wed, Jul 05, 2017 at 09:36:31PM +0800, Fam Zheng wrote: > > +static bool nvme_identify(BlockDriverState *bs, int namespace, Error > > **errp) > > +{ > > +BDRVNVMeState *s = bs->opaque; > > +uint8_t *resp; > > +int r; > > +uint64_t

Re: [Qemu-devel] [PATCH resend v4 0/3] Generate APEI GHES table and dynamically record CPER

Eric, I have submitted patch version 5 to fix the issue that you are concerned, hope you can have a review this series of patches, thanks. Result: 250 2.6.0 <1499825297-20335-1-git-send-email-gengdong...@huawei.com> [InternalId=34134279] Queued mail for delivery Result: 250 2.6.0

Re: [Qemu-devel] [PATCH v15] migration: spapr: migrate pending_events of spapr state

Applied to ppc-for-2.10, though I'm going to make some minor followup cleanups. -- David Gibson| I'll have my music baroque, and my code david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_ | _way_ _around_!

[Qemu-devel] [PATCH v5 2/3] ACPI: Add APEI GHES Table Generation support

This implements APEI GHES Table by passing the error CPER info to the guest via a fw_cfg_blob. After a CPER info is recorded, an SEA(Synchronous External Abort)/SEI(SError Interrupt) exception will be injected into the guest OS. Below is the table layout, the max number of error soure is 11,

[Qemu-devel] [PATCH v5 0/3] Generate APEI GHES table and dynamically record CPER

In the armv8 platform, the mainly hardware error source are ARMv8 SEA/SEI/GSIV. For the ARMv8 SEA/SEI, the KVM or host kernel will signal SIGBUS or use other interface to notify user space, such as Qemu. After Qemu gets the notification, it will record the CPER and inject the SEA/SEI to KVM. this

[Qemu-devel] [PATCH v5 1/3] ACPI: Add new ACPI structures and macros

(1) Add related APEI/HEST table structures and macros, these definition refer to ACPI 6.1 and UEFI 2.6 spec. (2) Add generic error status block and CPER memory section definition, user space only handle memory section errors. Signed-off-by: Dongjiu Geng ---

[Qemu-devel] [PATCH v5 3/3] ACPI: build and enable APEI GHES in the Makefile and configuration

Add CONFIG_ACPI_APEI configuration in the Makefile and enable it in the arm-softmmu.mak Signed-off-by: Dongjiu Geng --- thanks a lot Laszlo's review and comments: change since v4: (1) fix email threading in this series is incorrect issue change since v3: (1) change

Re: [Qemu-devel] [Qemu-block] [PATCH v3 3/6] block: Introduce bdrv_dma_map and bdrv_dma_unmap

On Tue, 07/11 12:28, Paolo Bonzini wrote: > On 11/07/2017 12:05, Stefan Hajnoczi wrote: > > On Mon, Jul 10, 2017 at 05:08:56PM +0200, Paolo Bonzini wrote: > >> On 10/07/2017 17:07, Stefan Hajnoczi wrote: > >>> On Wed, Jul 05, 2017 at 09:36:32PM +0800, Fam Zheng wrote: > Allow block driver to

Re: [Qemu-devel] [PATCH] util/cacheinfo: add missing include

On 07/10/2017 05:27 PM, Philippe Mathieu-Daudé wrote: For the record, what is the os version? Because this doesn't happen here for Centos7. Oops true I forgot to log this info in the commit. This happens on debian/powerpc Jessie, using GCC 4.9.2-10 Thanks. Queued to tcg-next. r~

[Qemu-devel] [PATCH] target-i386:kvm_get/put_vcpu_events don't handle sipi_vector

qemu call kvm_get_vcpu_events, and kernel return sipi_vector always 0, never valid when reporting to user space. But qemu call kvm_put_vcpu_events will make sipi_vector in kernel be 0. This will accidently modify sipi_vector when sipi_vector in kernel is not 0. Signed-off-by: Peng Hao

Re: [Qemu-devel] [PATCH 09/22] exec-all: shrink tb->invalid to uint8_t

On 07/10/2017 01:57 PM, Emilio G. Cota wrote: What I would prefer to do is generalize tb->cflags. Those values *do* affect how we compile the TB, and yet we don't take them into account. So I think it would be a good idea to feed that into the TB hash. I'm having trouble seeing how this

Re: [Qemu-devel] [PULL 19/21] tests: Add unit tests for the VM Generation ID feature

On Tue, Jul 11, 2017 at 04:43:50PM -0700, Ben Warren wrote: > Hi Laszlo, > > > On Jul 11, 2017, at 3:13 PM, Laszlo Ersek wrote: > > On 07/11/17 22:42, Peter Maydell wrote: > > On 11 July 2017 at 20:10, Michael S. Tsirkin wrote: > >

Re: [Qemu-devel] [PATCH v3] xen-platform: separate unplugging of NVMe disks

On Mon, 10 Jul 2017, Anthony PERARD wrote: > Hi Stefano, > > Looks like this patch can be applied. Thank you for pointing it out to me, because this email has inexplicably disappeared from my inbox. I have now marked it appropriately to be committed. > > On Fri, Mar 24, 2017 at 01:40:25PM

Re: [Qemu-devel] [PULL 22/42] configure: factor out list of supported Xen/KVM/HAX targets

On Mon, 10 Jul 2017, Peter Maydell wrote: > On 10 July 2017 at 17:14, Paolo Bonzini wrote: > > On 10/07/2017 17:49, Peter Maydell wrote: > >> On 5 July 2017 at 08:14, Paolo Bonzini wrote: > >>> This will be useful when the functions are called, early in

Re: [Qemu-devel] [PATCH] build: disable Xen on ARM

On Tue, 11 Jul 2017, Paolo Bonzini wrote: > On 11/07/2017 11:53, Peter Maydell wrote: > > On 11 July 2017 at 09:23, Paolo Bonzini wrote: > >> While ARM could present the xenpv machine, it does not and trying to enable > >> it breaks compilation. > >> > >> Fixes:

Re: [Qemu-devel] [PATCH v3 6/7] scripts/dump-guest-memory.py: add vmcoreinfo

Hi On Tue, Jul 11, 2017 at 10:23 PM Laszlo Ersek wrote: > On 07/11/17 12:30, Marc-André Lureau wrote: > > Add vmcoreinfo ELF note if vmcoreinfo device is ready. > > > > To help the python script, add a little global vmcoreinfo_gdb > > structure, that is populated with

Re: [Qemu-devel] [PATCH v4 0/4] Add shrink image for qcow2

On Tue, 07/11 16:35, Pavel Butsykin wrote: > On 11.07.2017 16:14, no-re...@patchew.org wrote: > > Hi, > > > > This series failed build test on s390x host. Please find the details below. > > > > Type: series > > Subject: [Qemu-devel] [PATCH v4 0/4] Add shrink image for qcow2 > > Message-id:

Re: [Qemu-devel] [PULL 19/21] tests: Add unit tests for the VM Generation ID feature

Hi Laszlo, > On Jul 11, 2017, at 3:13 PM, Laszlo Ersek wrote: > > On 07/11/17 22:42, Peter Maydell wrote: >> On 11 July 2017 at 20:10, Michael S. Tsirkin wrote: >>> On Tue, Jul 11, 2017 at 05:49:07PM +0100, Peter Maydell wrote: The good news is it's not

Re: [Qemu-devel] [1/2] slirp: Handle error returns from slirp_send() in sosendoob()

Peter Maydell, on lun. 05 juin 2017 17:19:35 +0100, wrote: > The code in sosendoob() assumes that slirp_send() always > succeeds, but it might return an OS error code (for instance > if the other end has disconnected). Catch these and return > the caller either -1 on error or the number of urgent

Re: [Qemu-devel] [2/2] slirp: Handle error returns from sosendoob()

Peter Maydell, on lun. 05 juin 2017 17:19:36 +0100, wrote: > diff --git a/slirp/socket.c b/slirp/socket.c > index a17caa9..84cf13a 100644 > --- a/slirp/socket.c > +++ b/slirp/socket.c > @@ -404,7 +404,14 @@ sowrite(struct socket *so) > DEBUG_ARG("so = %p", so); > > if (so->so_urgc) {

Re: [Qemu-devel] [PATCH] slirp: fork_exec(): Don't close() a negative number in fork_exec()

Peter Maydell, on dim. 09 juil. 2017 18:54:22 +0100, wrote: > In a fork_exec() error path we try to closesocket(s) when s might > be a negative number because the thing that failed was the > qemu_socket() call. Add a guard so we don't do this. > > (Spotted by Coverity: CID 1005727 issue 1 of 2.)

Re: [Qemu-devel] [PULL 19/21] tests: Add unit tests for the VM Generation ID feature

On 07/11/17 22:42, Peter Maydell wrote: > On 11 July 2017 at 20:10, Michael S. Tsirkin wrote: >> On Tue, Jul 11, 2017 at 05:49:07PM +0100, Peter Maydell wrote: >>> The good news is it's not aarch64-specific. I just hit this on >>> a build on x86_64 host, gcc, debug build: >>> >>>

Re: [Qemu-devel] [PATCH 0/3] pci: allow PCI bus slots to be marked as reserved

On 11/07/17 18:59, Mark Cave-Ayland wrote: > On 11/07/17 16:57, Michael S. Tsirkin wrote: > >> On Tue, Jul 11, 2017 at 06:51:50PM +0300, Marcel Apfelbaum wrote: >>> On 11/07/2017 18:31, Michael S. Tsirkin wrote: On Fri, Jul 07, 2017 at 08:43:59AM +0100, Mark Cave-Ayland wrote: > For

[Qemu-devel] [PATCH 8/8] sun4u: move in-built devices behind PCI bridge A

This switches the sun4u model to being much closer to a real Ultra 5. Since the existing code previously bypassed the PCI bridge interrupt swizzling, reorganise the interrupt mapping functions so that pci_pbm_map_irq() is used by the PCI bridges and pci_apb_map_irq() is used by the PCI host

[Qemu-devel] [PATCH 5/8] apb: fix endianness for APB and PCI config accesses

Signed-off-by: Mark Cave-Ayland --- hw/pci-host/apb.c |6 ++ 1 file changed, 2 insertions(+), 4 deletions(-) diff --git a/hw/pci-host/apb.c b/hw/pci-host/apb.c index 622c341..5ad7678 100644 --- a/hw/pci-host/apb.c +++ b/hw/pci-host/apb.c @@ -561,7 +561,7

[Qemu-devel] [PATCH 0/8] sun4u: change PCI topology to better match a real Ultra 5

The aim of this patchset is to bring the sun4u machine in line with a real Ultra 5 in order to resolve issues related to PCI bridge windows and interrupt routing. The majority of the changes are designed to accommodate the simba PCI bridges on the root PCI bus, moving the on-board devices behind

[Qemu-devel] [PATCH 1/8] sun4u: pass PCIDevice into pci_ebus_init() instead of PCIBus

In order to wire up the ebus PCI address spaces differently then we need access to the underlying PCIDevice. Signed-off-by: Mark Cave-Ayland --- hw/sparc64/sun4u.c |8 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/hw/sparc64/sun4u.c

[Qemu-devel] [PATCH 7/8] sun4u: create single default onboard ne2k_pci NIC for machine

As we move towards a real Ultra 5 machine, allow only a single NIC to be instantiated with the legacy net options. More devices can be added with the new -netdev and -device options if required. Signed-off-by: Mark Cave-Ayland --- hw/sparc64/sun4u.c |8

[Qemu-devel] [PATCH 2/8] sun4u: switch to using qdev to instantiate fw_cfg interface

Signed-off-by: Mark Cave-Ayland --- hw/sparc64/sun4u.c | 10 +- 1 file changed, 9 insertions(+), 1 deletion(-) diff --git a/hw/sparc64/sun4u.c b/hw/sparc64/sun4u.c index 7738856..8932be9 100644 --- a/hw/sparc64/sun4u.c +++ b/hw/sparc64/sun4u.c @@ -512,7

[Qemu-devel] [PATCH 3/8] sun4u: expose fw_cfg and NVRAM on ebus PCI IO address space

To allow future changes to the sun4u PCI topology. Signed-off-by: Mark Cave-Ayland Reviewed-by: Philippe Mathieu-Daudé Acked-By: Artyom Tarasenko --- hw/sparc64/sun4u.c |9 - 1 file changed, 4 insertions(+), 5

[Qemu-devel] [PATCH 4/8] apb: fix up PCI bus nomenclature

Rather than referring to the PCI busses as bus2 and bus3, refer to them as busA and busB as per the documentation. Also replace the long bus names with the shorter pciA and pciB aliases (to make it easier to attach additional devices to either from the command line). Signed-off-by: Mark

[Qemu-devel] [PATCH 6/8] apb: add busA qdev property to PBM PCI bridge

As future sun4u PCI topologies place the ebus containing the in-built devices behind a PCI bridge, add a busA property to the PBM PCI bridge that is then used to allow IO accesses by default. This allows early fw_cfg/NVRAM/serial access to occur even before OpenBIOS has had a chance to configure

[Qemu-devel] [PATCHv2 2/2] pci: add reserved slot check to do_pci_register_device()

Add a new slot_reserved_mask bitmask to PCIBus indicating whether or not each PCI slot on the bus is reserved. Ensure that it is initialised to zero to maintain the existing behaviour that all slots are available by default, and add the additional check with appropriate error reporting to

[Qemu-devel] [PATCHv2 0/2] pci: allow PCI bus slots to be marked as reserved

For some machines it is impossible to plug devices into a particular PCI bus slot, e.g. for a real Ultra 5 there are 2 PCI bridges attached to the root bus behind which all devices must be plugged. Ignoring this rule will cause problems with interrupt routing since the interrupt numbers are

[Qemu-devel] [PATCHv2 1/2] pci: move check for existing devfn into new pci_bus_devfn_available() helper

Also touch up the logic in do_pci_register_device() accordingly. Signed-off-by: Mark Cave-Ayland --- hw/pci/pci.c | 14 -- 1 file changed, 12 insertions(+), 2 deletions(-) diff --git a/hw/pci/pci.c b/hw/pci/pci.c index 0c6f74a..04e6edb 100644 ---

Re: [Qemu-devel] [PATCHv8 1/3] fw_cfg: switch fw_cfg_find() to locate the fw_cfg device by type rather than path

(off-topic) On 07/11/17 22:49, Peter Maydell wrote: > On 11 July 2017 at 21:26, Mark Cave-Ayland > wrote: >> On 11/07/17 21:18, Michael S. Tsirkin wrote: >> >>> Multi-line comments also should formatted >>> >>> /* >>> * like >>> * this >>> */ >>> >>> not >>> >>>

[Qemu-devel] [PATCH 0/2] target/i386: Implement all TBM instructions

These are general purpose bit manipulation instructions akin to the BMI1 and BMI2 instructions. This is an AMD extension and uses the XOP instruction prefix. I am in the process of trying to run the gcc testsuite with -mtbm, with and without the patchset, to see (1) if the new insns get used and

[Qemu-devel] [PATCH 1/2] target/i386: Decode AMD XOP prefix

Signed-off-by: Richard Henderson --- target/i386/translate.c | 46 -- 1 file changed, 32 insertions(+), 14 deletions(-) diff --git a/target/i386/translate.c b/target/i386/translate.c index ed3b896..6082db2 100644 ---

[Qemu-devel] [PATCH 2/2] target/i386: Implement all TBM instructions

Reported-by: Ricardo Ribalda Delgado Signed-off-by: Richard Henderson --- target/i386/cc_helper_template.h | 18 ++ target/i386/cpu.h| 7 ++- target/i386/cc_helper.c | 28 +++-- target/i386/cpu.c|

Re: [Qemu-devel] [RFC PATCH 03/26] target/ppc/POWER9: add POWERPC_EXCP_POWER9

On Tue, 2017-07-11 at 15:52 +0200, Cédric Le Goater wrote: > > > Just as we could build a POWER9 with XICS in qemu, we could build a > > POWER8 with XIVE. > > That might be the case with a POWER9 running in POWER8 compat mode. > I need to check. Yes. In "compat" mode (or more generally if

Re: [Qemu-devel] [PATCH] slirp: fork_exec(): Don't close() a negative number in fork_exec()

On 07/11/2017 03:40 PM, Peter Maydell wrote: >>> >>> The problem is you can only bail while you're in the parent >>> before forking. Once you've started the child there's no >>> mechanism for dealing with failure. >> >> Well, you can always exit the child before anything worse can happen. > > You

Re: [Qemu-devel] [PATCHv8 2/3] fw_cfg: move qdev_init_nofail() from fw_cfg_init1() to callers

On Tue, Jul 11, 2017 at 09:02:12PM +0100, Mark Cave-Ayland wrote: > When looking to instantiate a TYPE_FW_CFG_MEM or TYPE_FW_CFG_IO device to be > able to wire it up differently, it is much more convenient for the caller to > instantiate the device and have the fw_cfg default files already

Re: [Qemu-devel] [PATCH v3 4/6] target/arm/translate: ensure gen_goto_tb sets exit flags

On 07/11/2017 09:20 AM, Alex Bennée wrote: Richard Henderson writes: On 07/11/2017 07:59 AM, Alex Bennée wrote: if (use_goto_tb(s, dest)) { tcg_gen_goto_tb(n); gen_set_pc_im(s, dest); tcg_gen_exit_tb((uintptr_t)s->tb + n); +

Re: [Qemu-devel] [PATCHv8 1/3] fw_cfg: switch fw_cfg_find() to locate the fw_cfg device by type rather than path

On 11 July 2017 at 21:58, Eduardo Habkost wrote: > On Tue, Jul 11, 2017 at 09:49:30PM +0100, Peter Maydell wrote: >> It's basically GNU coding standard style vs Linux kernel style; >> there's a mix because some contributors are more used to working >> on the kernel, and some

Re: [Qemu-devel] [PATCHv8 1/3] fw_cfg: switch fw_cfg_find() to locate the fw_cfg device by type rather than path

On Tue, Jul 11, 2017 at 09:49:30PM +0100, Peter Maydell wrote: > On 11 July 2017 at 21:26, Mark Cave-Ayland > wrote: > > On 11/07/17 21:18, Michael S. Tsirkin wrote: > > > >> Multi-line comments also should formatted > >> > >> /* > >> * like > >> * this > >> */ >

Re: [Qemu-devel] [PATCH 2/7] hw/char/cmsdk-apb-uart.c: Implement CMSDK APB UART

On 11 July 2017 at 21:42, Philippe Mathieu-Daudé wrote: > Hi Peter, > > There is probably no need yet, but we could model a generic APB slave with > this code, as an overlapping subregion (device top 0x30 bytes). > > For now only PID0 differs, but since all ID are 8bit the device

Re: [Qemu-devel] [PATCHv8 1/3] fw_cfg: switch fw_cfg_find() to locate the fw_cfg device by type rather than path

On 11 July 2017 at 21:26, Mark Cave-Ayland wrote: > On 11/07/17 21:18, Michael S. Tsirkin wrote: > >> Multi-line comments also should formatted >> >> /* >> * like >> * this >> */ >> >> not >> >> /* like >> * this */ >> > > Interesting, I never knew there was a

Re: [Qemu-devel] [PATCH v2] specs: Describe the TPM support in QEMU

On 07/11/2017 03:36 PM, Laszlo Ersek wrote: On 07/11/17 16:31, Stefan Berger wrote: This patch adds a description of the current TPM support in QEMU to the specs. Several public specs are referenced via their landing page on the trustedcomputinggroup.org website. Signed-off-by: Stefan Berger

Re: [Qemu-devel] [Bug 1095531] Re: sparc32plus (and others?) has x86 code generation errors on 64bit hosts

I no longer have a setup to test this so I can only say to close it. On Jul 11, 2017 4:15 PM, "Thomas Huth" <1095...@bugs.launchpad.net> wrote: > Can you still reproduce this problem wit the latest release of QEMU > (currently version 2.9.0), or could we close this bug nowadays? > > ** Changed

Re: [Qemu-devel] [PATCH 2/7] hw/char/cmsdk-apb-uart.c: Implement CMSDK APB UART

Hi Peter, There is probably no need yet, but we could model a generic APB slave with this code, as an overlapping subregion (device top 0x30 bytes). For now only PID0 differs, but since all ID are 8bit the device could even instantiate the subregion with some u64 PID, 32 CID args.

Re: [Qemu-devel] [PULL 19/21] tests: Add unit tests for the VM Generation ID feature

On 11 July 2017 at 20:10, Michael S. Tsirkin wrote: > On Tue, Jul 11, 2017 at 05:49:07PM +0100, Peter Maydell wrote: >> The good news is it's not aarch64-specific. I just hit this on >> a build on x86_64 host, gcc, debug build: >> >> GTESTER check-qtest-x86_64 >> ** >>

Re: [Qemu-devel] [PATCH] slirp: fork_exec(): Don't close() a negative number in fork_exec()

On 11 July 2017 at 20:08, Dr. David Alan Gilbert wrote: > * Peter Maydell (peter.mayd...@linaro.org) wrote: >> [cc'd Eric as the sort of person >> >> On 11 July 2017 at 17:29, Dr. David Alan Gilbert wrote: >> > * Peter Maydell (peter.mayd...@linaro.org)

Re: [Qemu-devel] [PATCH 2/2] slirp: Handle error returns from sosendoob()

On 11 July 2017 at 19:46, Dr. David Alan Gilbert wrote: > * Peter Maydell (peter.mayd...@linaro.org) wrote: >> sosendoob() can return a failure code, but all its callers ignore it. >> This is OK in sbappend(), as the comment there states -- we will try >> again later in

Re: [Qemu-devel] [PATCHv8 1/3] fw_cfg: switch fw_cfg_find() to locate the fw_cfg device by type rather than path

On Tue, Jul 11, 2017 at 09:26:22PM +0100, Mark Cave-Ayland wrote: > On 11/07/17 21:18, Michael S. Tsirkin wrote: > > > Multi-line comments also should formatted > > > > /* > > * like > > * this > > */ > > > > not > > > > /* like > > * this */ > > > > Interesting, I never knew there was a

Re: [Qemu-devel] [PATCHv8 1/3] fw_cfg: switch fw_cfg_find() to locate the fw_cfg device by type rather than path

On 11/07/17 21:18, Michael S. Tsirkin wrote: > Multi-line comments also should formatted > > /* > * like > * this > */ > > not > > /* like > * this */ > Interesting, I never knew there was a preferred format for comments (I see both styles throughout the codebase). FWIW it's probably

Re: [Qemu-devel] [PATCH v3 0/7] KASLR kernel dump support

On 07/11/17 12:30, Marc-André Lureau wrote: > v3: from Laszlo review > - change vmcoreinfo offset to 36 > - reset err to null after report > - use PRIu32 > - change name_size and desc_size against MAX_VMCOREINFO_SIZE > - python code simplification > - check boundaries of blocks in

Re: [Qemu-devel] [PATCH v3 6/7] scripts/dump-guest-memory.py: add vmcoreinfo

On 07/11/17 12:30, Marc-André Lureau wrote: > Add vmcoreinfo ELF note if vmcoreinfo device is ready. > > To help the python script, add a little global vmcoreinfo_gdb > structure, that is populated with vmcoreinfo_gdb_update(). > > Signed-off-by: Marc-André Lureau >

Re: [Qemu-devel] [PATCHv8 1/3] fw_cfg: switch fw_cfg_find() to locate the fw_cfg device by type rather than path

On Tue, Jul 11, 2017 at 05:10:59PM -0300, Eduardo Habkost wrote: > On Tue, Jul 11, 2017 at 09:02:11PM +0100, Mark Cave-Ayland wrote: > > This will enable the fw_cfg device to be placed anywhere within the QOM tree > > regardless of its machine location. > > > > Note that we also add a comment to

[Qemu-devel] [Bug 1094950] Re: crash at qemu_iohandler_poll (iohandler.c:124) on macos 10.8.2

Can you still reproduce this problem wit the latest release of QEMU (currently version 2.9.0) and macOS, or could we close this bug nowadays? ** Changed in: qemu Status: New => Incomplete -- You received this bug notification because you are a member of qemu- devel-ml, which is

[Qemu-devel] [Bug 1093360] Re: files on microsoft iso images mounted to qemu VM get stripped from Version info. E.G. Microsoft UAG installation fails

Can you still reproduce this problem wit the latest release of QEMU (currently version 2.9.0), or could we close this bug nowadays? ** Changed in: qemu Status: New => Incomplete -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU.

[Qemu-devel] [Bug 1095531] Re: sparc32plus (and others?) has x86 code generation errors on 64bit hosts

Can you still reproduce this problem wit the latest release of QEMU (currently version 2.9.0), or could we close this bug nowadays? ** Changed in: qemu Status: New => Incomplete -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU.

Re: [Qemu-devel] [PATCHv8 1/3] fw_cfg: switch fw_cfg_find() to locate the fw_cfg device by type rather than path

On 11/07/17 21:10, Eduardo Habkost wrote: > On Tue, Jul 11, 2017 at 09:02:11PM +0100, Mark Cave-Ayland wrote: >> This will enable the fw_cfg device to be placed anywhere within the QOM tree >> regardless of its machine location. >> >> Note that we also add a comment to document the behaviour that

[Qemu-devel] [Bug 1099403] Re: High CPU utilization in vnc mode

Triaging old bug tickets ... Can you still reproduce this problem wit the latest release of QEMU (currently version 2.9.0), or could we close this bug nowadays? ** Changed in: qemu Status: New => Incomplete -- You received this bug notification because you are a member of qemu- devel-ml,

[Qemu-devel] [Bug 1095857] Re: incorrect handling of [r32] address (long mode)

** Changed in: qemu Status: New => Incomplete -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/1095857 Title: incorrect handling of [r32] address (long mode) Status in QEMU: Incomplete Bug

Re: [Qemu-devel] [PATCH v3 4/7] dump: add vmcoreinfo ELF note

On Tue, Jul 11, 2017 at 10:04:43PM +0200, Laszlo Ersek wrote: [...] > > +lines = g_strsplit((char *)vmci, "\n", -1); > > +for (i = 0; lines[i]; i++) { > > +if (g_str_has_prefix(lines[i], "NUMBER(phys_base)=")) { > > +if (qemu_strtou64(lines[i] + 18, NULL, 16, > > +

Re: [Qemu-devel] [PATCHv8 1/3] fw_cfg: switch fw_cfg_find() to locate the fw_cfg device by type rather than path

On Tue, Jul 11, 2017 at 09:02:11PM +0100, Mark Cave-Ayland wrote: > This will enable the fw_cfg device to be placed anywhere within the QOM tree > regardless of its machine location. > > Note that we also add a comment to document the behaviour that we return NULL > to > indicate failure where

[Qemu-devel] [Bug 1089006] Re: Qemu scrambles order of eth devices in vm

Is there still something left to do here, or could we close this bug nowadays? ** Changed in: qemu Status: New => Incomplete -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/1089006 Title:

Re: [Qemu-devel] [PATCH v3 4/7] dump: add vmcoreinfo ELF note

On 07/11/17 12:30, Marc-André Lureau wrote: > Read the vmcoreinfo ELF PT_NOTE from guest memory when vmcoreinfo > device provides the location, and write it as an ELF note in the dump. > > There are now 2 possible sources of phys_base information. > > (1) arch guessed value from

[Qemu-devel] [Bug 1089281] Re: kvm crash when writing on disk

Closing according to comment #2 and #3 ** Changed in: qemu Status: New => Won't Fix -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/1089281 Title: kvm crash when writing on disk Status in

[Qemu-devel] [PATCHv8 2/3] fw_cfg: move qdev_init_nofail() from fw_cfg_init1() to callers

When looking to instantiate a TYPE_FW_CFG_MEM or TYPE_FW_CFG_IO device to be able to wire it up differently, it is much more convenient for the caller to instantiate the device and have the fw_cfg default files already preloaded during realize. Move fw_cfg_init1() to the end of both the

[Qemu-devel] [PATCHv8 3/3] fw_cfg: move QOM type defines and fw_cfg types into fw_cfg.h

By exposing FWCfgIoState and FWCfgMemState internals we allow the possibility for the internal MemoryRegion fields to be mapped by name for boards that wish to wire up the fw_cfg device themselves. Signed-off-by: Mark Cave-Ayland Reviewed-by: Laszlo Ersek

[Qemu-devel] [PATCHv8 0/3] fw_cfg: qdev-related tidy-ups

As part of some ongoing sun4u work, I need to be able to wire the fw_cfg IO interface to a separate IO space by instantiating the qdev device instead of calling fw_cfg_init_io(). This patchset brings FW_CFG_IO in line with FW_CFG_MEM and tidies up the realize methods accordingly. Signed-off-by:

[Qemu-devel] [PATCHv8 1/3] fw_cfg: switch fw_cfg_find() to locate the fw_cfg device by type rather than path

This will enable the fw_cfg device to be placed anywhere within the QOM tree regardless of its machine location. Note that we also add a comment to document the behaviour that we return NULL to indicate failure where either no fw_cfg device or multiple fw_cfg devices are found. Signed-off-by:

Re: [Qemu-devel] [PATCH v3 3/7] tests: add simple vmcoreinfo test

On 07/11/17 12:30, Marc-André Lureau wrote: > This test is based off vmgenid test from Ben Warren > . It simply checks the vmcoreinfo ACPI device > is present and that the memory region associated can be read. > > Signed-off-by: Marc-André Lureau

Re: [Qemu-devel] [PATCH v2] specs: Describe the TPM support in QEMU

On 07/11/17 16:31, Stefan Berger wrote: > This patch adds a description of the current TPM support in QEMU > to the specs. > > Several public specs are referenced via their landing page on the > trustedcomputinggroup.org website. > > Signed-off-by: Stefan Berger > >

Re: [Qemu-devel] [PATCH v12 02/27] cpu-exec: Avoid global variables in icount-related functions

Lluís Vilanova writes: > Signed-off-by: Lluís Vilanova I guess. I assume this is also something Emilio is targeting with his multi-threaded translation work. Reviewed-by: Alex Bennée > --- > include/exec/gen-icount.h | 10

Re: [Qemu-devel] [PATCH v12 01/27] Pass generic CPUState to gen_intermediate_code()

Lluís Vilanova writes: > Needed to implement a target-agnostic gen_intermediate_code() in the > future. > > Signed-off-by: Lluís Vilanova > Reviewed-by: David Gibson > Reviewed-by: Richard Henderson

Re: [Qemu-devel] [PATCH v3 4/6] target/arm/translate: ensure gen_goto_tb sets exit flags

Richard Henderson writes: > On 07/11/2017 07:59 AM, Alex Bennée wrote: >> if (use_goto_tb(s, dest)) { >> tcg_gen_goto_tb(n); >> gen_set_pc_im(s, dest); >> tcg_gen_exit_tb((uintptr_t)s->tb + n); >> +s->is_jmp = DISAS_TB_JUMP; >>

Re: [Qemu-devel] [PULL 19/21] tests: Add unit tests for the VM Generation ID feature

On Tue, Jul 11, 2017 at 05:49:07PM +0100, Peter Maydell wrote: > On 11 July 2017 at 16:22, Peter Maydell wrote: > > On 11 July 2017 at 16:07, Ben Warren wrote: > >> Hi Peter, > >>> On Jul 11, 2017, at 6:32 AM, Peter Maydell

Re: [Qemu-devel] [PATCH] slirp: fork_exec(): Don't close() a negative number in fork_exec()

* Peter Maydell (peter.mayd...@linaro.org) wrote: > [cc'd Eric as the sort of person > > On 11 July 2017 at 17:29, Dr. David Alan Gilbert wrote: > > * Peter Maydell (peter.mayd...@linaro.org) wrote: > >> In a fork_exec() error path we try to closesocket(s) when s might > >>

Re: [Qemu-devel] [PATCH v9 6/9] qcow2: add bdrv_measure() support

On 07/05/2017 07:57 AM, Stefan Hajnoczi wrote: > Use qcow2_calc_prealloc_size() to get the required file size. > > Signed-off-by: Stefan Hajnoczi > Reviewed-by: Alberto Garcia > --- > +for (sector_num = 0; > + sector_num <

Re: [Qemu-devel] [PATCH v9 6/9] qcow2: add bdrv_measure() support

On 07/05/2017 07:57 AM, Stefan Hajnoczi wrote: > Use qcow2_calc_prealloc_size() to get the required file size. > > Signed-off-by: Stefan Hajnoczi > Reviewed-by: Alberto Garcia > --- > > +static BlockMeasureInfo *qcow2_measure(QemuOpts *opts,

[Qemu-devel] [PATCH] tcg: move atomic_template.h to accel/tcg/

Signed-off-by: Philippe Mathieu-Daudé --- same as Thomas previous patch. this file had no entry in MAINTAINERS. atomic_template.h => accel/tcg/atomic_template.h | 0 1 file changed, 0 insertions(+), 0 deletions(-) rename atomic_template.h => accel/tcg/atomic_template.h (100%)

  1   2   3   4   5   6   >