qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] Qemu-devel Digest, Vol 156, Issue 15


From: Abhimanyu Rawat
Subject: Re: [Qemu-devel] Qemu-devel Digest, Vol 156, Issue 15
Date: Wed, 2 Mar 2016 00:44:58 +0530

Hello All,
I am Abhimanyu and want to work on the project "qemu-img new subcommand "dd" ".

I have used QEMU in my last semester. I think through some of the existing "dd" control commands and also by scripting some new once, we can make virtual image conversions/manipulations and pipe the images across hosts easily.

 Kindly tell me more about that i.e. what else can be expected and, /or any other point that I might be missing here? 

Closing with thank you and warm Regards,

Abhimanyu Rawat
M.E. Computer Science, 
CS/IS Department, BITS Pilani, Pilani Campus
Phone. 08930399302 (call/Whatsapp), 09466899302

 ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄


On Tue, Mar 1, 2016 at 11:52 PM, <address@hidden> wrote:
Send Qemu-devel mailing list submissions to
        address@hidden

To subscribe or unsubscribe via the World Wide Web, visit
        https://lists.nongnu.org/mailman/listinfo/qemu-devel
or, via email, send a message with subject or body 'help' to
        address@hidden

You can reach the person managing the list at
        address@hidden

When replying, please edit your Subject line so it is more specific
than "Re: Contents of Qemu-devel digest..."


Today's Topics:

   1. Re: [PATCH V2 0/2] hw/virtio: fix double use of a virtio flag
      (Marcel Apfelbaum)
   2. Re: [PATCH 8/9] nvdimm acpi: emulate dsm method
      (Michael S. Tsirkin)
   3. Re: [PATCH 8/9] nvdimm acpi: emulate dsm method
      (Michael S. Tsirkin)
   4. Re: [PATCH 18/38] ivshmem: Leave INTx alone when using    MSI-X
      (Marc-Andr? Lureau)
   5. [PATCH 1/3] target-tricore: add missing break in insn     decode
      switch stmt (Bastian Koppelmann)
   6. [PATCH 3/3] target-tricore: Fix psw_read() clearing       too many
      bits (Bastian Koppelmann)
   7. [PATCH 0/3] TriCore bugfixes (Bastian Koppelmann)
   8. [PATCH 2/3] target-tricore: Fix helper_msub64_q_ssov      not
      reseting OVF bit (Bastian Koppelmann)
   9. Re: [PATCH v3 0/2] virtio-balloon: improve balloon        statistics
      (Michael S. Tsirkin)
  10. Libvirt accepted to GSoC (Michal Privoznik)
  11. Re: [PATCH 18/38] ivshmem: Leave INTx alone when using MSI-X
      (Paolo Bonzini)
  12. [PATCH v2] hw/arm/virt: Assume EL3 boot rom will  handle PSCI
      if one is provided (Peter Maydell)
  13. [PATCH v2] hw/intc/arm_gic.c: Implement GICv2 GICC_DIR
      (Peter Maydell)
  14. Re: [PATCH 1/7] target-tricore: Add FPU infrastructure
      (Richard Henderson)
  15. Re: [PATCH 2/7] target-tricore: Move general CHECK_REG_PAIR
      of decode_rrr_divide (Richard Henderson)
  16. Re: [PATCH] Use special code for sigsetjmp only in cpu-exec.c
      (Andrew Baumann)
  17. Re: [PATCH] Use special code for sigsetjmp only in cpu-exec.c
      (Paolo Bonzini)
  18. Re: [PATCH v2] hw/arm/virt: Assume EL3 boot rom will handle
      PSCI if one is provided (Laszlo Ersek)
  19. Re: [PATCH] Use special code for sigsetjmp only in        cpu-exec.c
      (Peter Maydell)
  20. Re: [PATCH v2 01/13] Use unsigned types for the 'len'
      argument of all memory read/write functions (Martin Galvan)
  21. [PATCH] target-ppc: fix sync of SPR_SDR1 with KVM (Greg Kurz)
  22. Re: [PATCH 3/7] target-tricore: add add.f/sub.f   instructions
      (Richard Henderson)
  23. Re: [PATCH v2 02/15] Makefile: Rules for docker testing
      (Alex Benn?e)
  24. Re: [RFC] QMP: add query-hotpluggable-cpus (Igor Mammedov)
  25. Re: [PATCH 1/4] bcm2835_peripherals: enable sdhci
      pending-insert quirk for raspberry pi (Peter Maydell)


----------------------------------------------------------------------

Message: 1
Date: Tue, 1 Mar 2016 19:00:43 +0200
From: Marcel Apfelbaum <address@hidden>
To: Marcel Apfelbaum <address@hidden>, address@hidden
Cc: address@hidden, address@hidden, address@hidden,
        address@hidden
Subject: Re: [Qemu-devel] [PATCH V2 0/2] hw/virtio: fix double use of
        a virtio flag
Message-ID: <address@hidden>
Content-Type: text/plain; charset=windows-1252; format=flowed

On 02/10/2016 03:31 PM, Marcel Apfelbaum wrote:
> To the obvious question of "how did that happen?"
> I can say we had an unlucky break.
> Both Jason and me worked on a new different virtio feature in the same
> time, and they were both merged in the same pull request.
> We both saw BIT 3 as the last used
>      https://lists.gnu.org/archive/html/qemu-devel/2015-11/msg03041.html
>
> Commits 1811e64c and a6df8adf use the same virtio feature bit 4
> for different features.
>
> Fix it by using different bits.
> While at it, group all the virtio flags into an enum to avoid that
> in the feature.
>

ping

Thanks,
Marcel

>
> v1 -> v2:
>    - Addressed Laurent Vivier's comment:
>       - forgot to remove a flag
>    - Added teset-by to the first patch
>
> Marcel Apfelbaum (2):
>    hw/virtio: fix double use of a virtio flag
>    hw/virtio: group virtio flags into an enum
>
>   hw/virtio/virtio-pci.h | 17 ++++++++++-------
>   1 file changed, 10 insertions(+), 7 deletions(-)
>




------------------------------

Message: 2
Date: Tue, 1 Mar 2016 19:09:38 +0200
From: "Michael S. Tsirkin" <address@hidden>
To: Xiao Guangrong <address@hidden>
Cc: address@hidden, address@hidden, address@hidden,
        address@hidden, address@hidden, address@hidden,
        address@hidden, address@hidden,       address@hidden,
        address@hidden
Subject: Re: [Qemu-devel] [PATCH 8/9] nvdimm acpi: emulate dsm method
Message-ID: <address@hidden>
Content-Type: text/plain; charset=us-ascii

On Tue, Mar 01, 2016 at 06:56:10PM +0800, Xiao Guangrong wrote:
> Emulate dsm method after IO VM-exit
>
> Currently, we only introduce the framework and no function is actually
> supported
>
> Signed-off-by: Xiao Guangrong <address@hidden>
> ---
>  hw/acpi/aml-build.c         |  2 +-
>  hw/acpi/nvdimm.c            | 44 ++++++++++++++++++++++++++++++++++++++++++++
>  include/hw/acpi/aml-build.h |  1 +
>  include/hw/mem/nvdimm.h     |  8 ++++++++
>  4 files changed, 54 insertions(+), 1 deletion(-)
>
> diff --git a/hw/acpi/aml-build.c b/hw/acpi/aml-build.c
> index ab89ca6..da11bf8 100644
> --- a/hw/acpi/aml-build.c
> +++ b/hw/acpi/aml-build.c
> @@ -227,7 +227,7 @@ static void build_extop_package(GArray *package, uint8_t op)
>      build_prepend_byte(package, 0x5B); /* ExtOpPrefix */
>  }
>
> -static void build_append_int_noprefix(GArray *table, uint64_t value, int size)
> +void build_append_int_noprefix(GArray *table, uint64_t value, int size)
>  {
>      int i;
>
> diff --git a/hw/acpi/nvdimm.c b/hw/acpi/nvdimm.c
> index 781f6c1..e0b483a 100644
> --- a/hw/acpi/nvdimm.c
> +++ b/hw/acpi/nvdimm.c
> @@ -393,12 +393,56 @@ typedef struct NvdimmDsmOut NvdimmDsmOut;
>  static uint64_t
>  nvdimm_dsm_read(void *opaque, hwaddr addr, unsigned size)
>  {
> +    fprintf(stderr, "BUG: we never read _DSM IO Port.\n");
>      return 0;
>  }

Can't guest trigger this?
If yes, don't put such code in production please:
this will fill up disk on the host.


>
>  static void
>  nvdimm_dsm_write(void *opaque, hwaddr addr, uint64_t val, unsigned size)
>  {
> +    NvdimmDsmIn *in;
> +    GArray *out;
> +    uint32_t buf_size;
> +    hwaddr dsm_mem_addr = val;
> +
> +    nvdimm_debug("dsm memory address %#lx.\n", dsm_mem_addr);
> +
> +    /*
> +     * The DSM memory is mapped to guest address space so an evil guest
> +     * can change its content while we are doing DSM emulation. Avoid
> +     * this by copying DSM memory to QEMU local memory.
> +     */
> +    in = g_malloc(TARGET_PAGE_SIZE);
> +    cpu_physical_memory_read(dsm_mem_addr, in, TARGET_PAGE_SIZE);
> +
> +    le32_to_cpus(&in->revision);
> +    le32_to_cpus(&in->function);
> +    le32_to_cpus(&in->handle);
> +
> +    nvdimm_debug("Revision %#x Handler %#x Function %#x.\n", in->revision,
> +                 in->handle, in->function);
> +
> +    out = g_array_new(false, true /* clear */, 1);
> +
> +    /*
> +     * function 0 is called to inquire what functions are supported by
> +     * OSPM
> +     */
> +    if (in->function == 0) {
> +        build_append_int_noprefix(out, 0 /* No function Supported */,
> +                                  sizeof(uint8_t));
> +    } else {
> +        /* No function is supported yet. */
> +        build_append_int_noprefix(out, 1 /* Not Supported */,
> +                                  sizeof(uint8_t));
> +    }
> +
> +    buf_size = cpu_to_le32(out->len);
> +    cpu_physical_memory_write(dsm_mem_addr, &buf_size, sizeof(buf_size));

is there a race here?
can guest read this before data is written?

> +    cpu_physical_memory_write(dsm_mem_addr + sizeof(buf_size), out->data,
> +                              out->len);

What is this doing?
Is this actually writing AML bytecode into guest memory?


> +    g_free(in);
> +    g_array_free(out, true);
>  }
>
>  static const MemoryRegionOps nvdimm_dsm_ops = {
> diff --git a/include/hw/acpi/aml-build.h b/include/hw/acpi/aml-build.h
> index 7404e2a..b0826f0 100644
> --- a/include/hw/acpi/aml-build.h
> +++ b/include/hw/acpi/aml-build.h
> @@ -357,6 +357,7 @@ Aml *aml_derefof(Aml *arg);
>  Aml *aml_sizeof(Aml *arg);
>  Aml *aml_concatenate(Aml *source1, Aml *source2, Aml *target);
>
> +void build_append_int_noprefix(GArray *table, uint64_t value, int size);
>  void
>  build_header(GArray *linker, GArray *table_data,
>               AcpiTableHeader *h, const char *sig, int len, uint8_t rev,
> diff --git a/include/hw/mem/nvdimm.h b/include/hw/mem/nvdimm.h
> index 634c60b..aaa2608 100644
> --- a/include/hw/mem/nvdimm.h
> +++ b/include/hw/mem/nvdimm.h
> @@ -25,6 +25,14 @@
>
>  #include "hw/mem/pc-dimm.h"
>
> +#define NVDIMM_DEBUG 0
> +#define nvdimm_debug(fmt, ...)                                \
> +    do {                                                      \
> +        if (NVDIMM_DEBUG) {                                   \
> +            fprintf(stderr, "nvdimm: " fmt, ## __VA_ARGS__);  \
> +        }                                                     \
> +    } while (0)
> +
>  #define TYPE_NVDIMM             "nvdimm"
>
>  #define NVDIMM_DSM_MEM_FILE     "etc/acpi/nvdimm-mem"
> --
> 1.8.3.1



------------------------------

Message: 3
Date: Tue, 1 Mar 2016 19:12:32 +0200
From: "Michael S. Tsirkin" <address@hidden>
To: Xiao Guangrong <address@hidden>
Cc: address@hidden, address@hidden, address@hidden,
        address@hidden, address@hidden, address@hidden,
        address@hidden, address@hidden,       address@hidden,
        address@hidden
Subject: Re: [Qemu-devel] [PATCH 8/9] nvdimm acpi: emulate dsm method
Message-ID: <address@hidden>
Content-Type: text/plain; charset=us-ascii

On Tue, Mar 01, 2016 at 06:56:10PM +0800, Xiao Guangrong wrote:
> Emulate dsm method after IO VM-exit
>
> Currently, we only introduce the framework and no function is actually
> supported
>
> Signed-off-by: Xiao Guangrong <address@hidden>
> ---
>  hw/acpi/aml-build.c         |  2 +-
>  hw/acpi/nvdimm.c            | 44 ++++++++++++++++++++++++++++++++++++++++++++
>  include/hw/acpi/aml-build.h |  1 +
>  include/hw/mem/nvdimm.h     |  8 ++++++++
>  4 files changed, 54 insertions(+), 1 deletion(-)
>
> diff --git a/hw/acpi/aml-build.c b/hw/acpi/aml-build.c
> index ab89ca6..da11bf8 100644
> --- a/hw/acpi/aml-build.c
> +++ b/hw/acpi/aml-build.c
> @@ -227,7 +227,7 @@ static void build_extop_package(GArray *package, uint8_t op)
>      build_prepend_byte(package, 0x5B); /* ExtOpPrefix */
>  }
>
> -static void build_append_int_noprefix(GArray *table, uint64_t value, int size)
> +void build_append_int_noprefix(GArray *table, uint64_t value, int size)
>  {
>      int i;
>
> diff --git a/hw/acpi/nvdimm.c b/hw/acpi/nvdimm.c
> index 781f6c1..e0b483a 100644
> --- a/hw/acpi/nvdimm.c
> +++ b/hw/acpi/nvdimm.c
> @@ -393,12 +393,56 @@ typedef struct NvdimmDsmOut NvdimmDsmOut;
>  static uint64_t
>  nvdimm_dsm_read(void *opaque, hwaddr addr, unsigned size)
>  {
> +    fprintf(stderr, "BUG: we never read _DSM IO Port.\n");
>      return 0;
>  }
>
>  static void
>  nvdimm_dsm_write(void *opaque, hwaddr addr, uint64_t val, unsigned size)
>  {
> +    NvdimmDsmIn *in;
> +    GArray *out;
> +    uint32_t buf_size;
> +    hwaddr dsm_mem_addr = val;
> +
> +    nvdimm_debug("dsm memory address %#lx.\n", dsm_mem_addr);
> +
> +    /*
> +     * The DSM memory is mapped to guest address space so an evil guest
> +     * can change its content while we are doing DSM emulation. Avoid
> +     * this by copying DSM memory to QEMU local memory.
> +     */
> +    in = g_malloc(TARGET_PAGE_SIZE);
> +    cpu_physical_memory_read(dsm_mem_addr, in, TARGET_PAGE_SIZE);
> +
> +    le32_to_cpus(&in->revision);
> +    le32_to_cpus(&in->function);
> +    le32_to_cpus(&in->handle);
> +
> +    nvdimm_debug("Revision %#x Handler %#x Function %#x.\n", in->revision,
> +                 in->handle, in->function);
> +
> +    out = g_array_new(false, true /* clear */, 1);
> +
> +    /*
> +     * function 0 is called to inquire what functions are supported by
> +     * OSPM
> +     */
> +    if (in->function == 0) {
> +        build_append_int_noprefix(out, 0 /* No function Supported */,
> +                                  sizeof(uint8_t));
> +    } else {
> +        /* No function is supported yet. */
> +        build_append_int_noprefix(out, 1 /* Not Supported */,
> +                                  sizeof(uint8_t));
> +    }
> +
> +    buf_size = cpu_to_le32(out->len);
> +    cpu_physical_memory_write(dsm_mem_addr, &buf_size, sizeof(buf_size));
> +    cpu_physical_memory_write(dsm_mem_addr + sizeof(buf_size), out->data,
> +                              out->len);

BTW, how do we know buffer is big enough? Add assert here?

Also, you have a packed structure with the layout, correct?
Can't you use that instead of open-coding it?

> +    g_free(in);
> +    g_array_free(out, true);
>  }
>
>  static const MemoryRegionOps nvdimm_dsm_ops = {
> diff --git a/include/hw/acpi/aml-build.h b/include/hw/acpi/aml-build.h
> index 7404e2a..b0826f0 100644
> --- a/include/hw/acpi/aml-build.h
> +++ b/include/hw/acpi/aml-build.h
> @@ -357,6 +357,7 @@ Aml *aml_derefof(Aml *arg);
>  Aml *aml_sizeof(Aml *arg);
>  Aml *aml_concatenate(Aml *source1, Aml *source2, Aml *target);
>
> +void build_append_int_noprefix(GArray *table, uint64_t value, int size);
>  void
>  build_header(GArray *linker, GArray *table_data,
>               AcpiTableHeader *h, const char *sig, int len, uint8_t rev,
> diff --git a/include/hw/mem/nvdimm.h b/include/hw/mem/nvdimm.h
> index 634c60b..aaa2608 100644
> --- a/include/hw/mem/nvdimm.h
> +++ b/include/hw/mem/nvdimm.h
> @@ -25,6 +25,14 @@
>
>  #include "hw/mem/pc-dimm.h"
>
> +#define NVDIMM_DEBUG 0
> +#define nvdimm_debug(fmt, ...)                                \
> +    do {                                                      \
> +        if (NVDIMM_DEBUG) {                                   \
> +            fprintf(stderr, "nvdimm: " fmt, ## __VA_ARGS__);  \
> +        }                                                     \
> +    } while (0)
> +
>  #define TYPE_NVDIMM             "nvdimm"
>
>  #define NVDIMM_DSM_MEM_FILE     "etc/acpi/nvdimm-mem"
> --
> 1.8.3.1



------------------------------

Message: 4
Date: Tue, 1 Mar 2016 18:14:54 +0100
From: Marc-Andr? Lureau <address@hidden>
To: Markus Armbruster <address@hidden>
Cc: Paolo Bonzini <address@hidden>, cam <address@hidden>,
        Claudio Fontana <address@hidden>, QEMU
        <address@hidden>,        David Marchand <address@hidden>
Subject: Re: [Qemu-devel] [PATCH 18/38] ivshmem: Leave INTx alone when
        using   MSI-X
Message-ID:
        <address@hidden>
Content-Type: text/plain; charset=UTF-8

On Mon, Feb 29, 2016 at 7:40 PM, Markus Armbruster <address@hidden> wrote:
> The ivshmem device can either use MSI-X or legacy INTx for interrupts.
>
> With MSI-X enabled, peer interrupt events trigger an MSI as they
> should.  But software can still raise INTx via interrupt status and
> mask register in BAR 0.  This is explicitly prohibited by PCI Local
> Bus Specification Revision 3.0, section 6.8.3.3:
>
>     While enabled for MSI or MSI-X operation, a function is prohibited
>     from using its INTx# pin (if implemented) to request service (MSI,
>     MSI-X, and INTx# are mutually exclusive).
>
> Fix the device model to leave INTx alone when using MSI-X.
>
> Document that we claim to use INTx in config space even when we don't.
>
> Signed-off-by: Markus Armbruster <address@hidden>
> ---
>  hw/misc/ivshmem.c | 9 +++++++++
>  1 file changed, 9 insertions(+)
>
> diff --git a/hw/misc/ivshmem.c b/hw/misc/ivshmem.c
> index cfea151..fc37feb 100644
> --- a/hw/misc/ivshmem.c
> +++ b/hw/misc/ivshmem.c
> @@ -126,6 +126,11 @@ static void ivshmem_update_irq(IVShmemState *s)
>      PCIDevice *d = PCI_DEVICE(s);
>      uint32_t isr = s->intrstatus & s->intrmask;
>
> +    /* No INTx with msi=off, whether the guest enabled MSI-X or not */
> +    if (ivshmem_has_feature(s, IVSHMEM_MSI)) {
> +        return;
> +    }
> +
>      /* don't print ISR resets */
>      if (isr) {
>          IVSHMEM_DPRINTF("Set IRQ to %d (%04x %04x)\n",
> @@ -874,6 +879,10 @@ static void pci_ivshmem_realize(PCIDevice *dev, Error **errp)
>      pci_conf = dev->config;
>      pci_conf[PCI_COMMAND] = PCI_COMMAND_IO | PCI_COMMAND_MEMORY;
>
> +    /*
> +     * Note: we don't use INTx with IVSHMEM_MSI at all, so this is a
> +     * bald-faced lie then.  But it's a backwards compatible lie.
> +     */
>      pci_config_set_interrupt_pin(pci_conf, 1);

I am not sure how much of a problem this is. Apparently, other devices
claim interrupt and msi (ich, hda, pvscsi)

Better ask someone more familiar with PCI details.

>
>      memory_region_init_io(&s->ivshmem_mmio, OBJECT(s), &ivshmem_mmio_ops, s,
> --
> 2.4.3
>
>



--
Marc-Andr? Lureau



------------------------------

Message: 5
Date: Tue,  1 Mar 2016 18:15:24 +0100
From: Bastian Koppelmann <address@hidden>
To: address@hidden
Subject: [Qemu-devel] [PATCH 1/3] target-tricore: add missing break in
        insn    decode switch stmt
Message-ID:
        <address@hidden>

After decoding/translating a RRR_DIVIDE type instruction we would simply
fall through and would decode/translate another unintended RRR2_MADD
instruction.

Signed-off-by: Bastian Koppelmann <address@hidden>
---
 target-tricore/translate.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/target-tricore/translate.c b/target-tricore/translate.c
index 6d7f553..f028fb9 100644
--- a/target-tricore/translate.c
+++ b/target-tricore/translate.c
@@ -8632,6 +8632,7 @@ static void decode_32Bit_opc(CPUTriCoreState *env, DisasContext *ctx)
         break;
     case OPCM_32_RRR_DIVIDE:
         decode_rrr_divide(env, ctx);
+        break;
 /* RRR2 Format */
     case OPCM_32_RRR2_MADD:
         decode_rrr2_madd(env, ctx);
--
2.7.2




------------------------------

Message: 6
Date: Tue,  1 Mar 2016 18:15:26 +0100
From: Bastian Koppelmann <address@hidden>
To: address@hidden
Subject: [Qemu-devel] [PATCH 3/3] target-tricore: Fix psw_read()
        clearing        too many bits
Message-ID:
        <address@hidden>

psw_read() ought to sync the PSW value with the
cached status bits (C,V,SV,AV,SAV). For this the bits
are cleared in the PSW before they are written from the
cached bits. The clear mask is too big and clears two
additional bits.

Signed-off-by: Bastian Koppelmann <address@hidden>
---
 target-tricore/helper.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/target-tricore/helper.c b/target-tricore/helper.c
index 7d96dad..adbb6db 100644
--- a/target-tricore/helper.c
+++ b/target-tricore/helper.c
@@ -113,7 +113,7 @@ void tricore_cpu_list(FILE *f, fprintf_function cpu_fprintf)
 uint32_t psw_read(CPUTriCoreState *env)
 {
     /* clear all USB bits */
-    env->PSW &= 0xffffff;
+    env->PSW &= 0x6ffffff;
     /* now set them from the cache */
     env->PSW |= ((env->PSW_USB_C != 0) << 31);
     env->PSW |= ((env->PSW_USB_V   & (1 << 31))  >> 1);
--
2.7.2




------------------------------

Message: 7
Date: Tue,  1 Mar 2016 18:15:23 +0100
From: Bastian Koppelmann <address@hidden>
To: address@hidden
Subject: [Qemu-devel] [PATCH 0/3] TriCore bugfixes
Message-ID:
        <address@hidden>

Hi,

this series tackles the bugfixes found during FPU implementation
and are mostly on liners. This includes a missing break in a switch
statement, a forgotten reset of an OVF bit, and psw_read() clearing
too many bits.

Cheers,
Bastian

Bastian Koppelmann (3):
  target-tricore: add missing break in insn decode switch stmt
  target-tricore: Fix helper_msub64_q_ssov not reseting OVF bit
  target-tricore: Fix psw_read() clearing too many bits

 target-tricore/helper.c    | 2 +-
 target-tricore/op_helper.c | 2 ++
 target-tricore/translate.c | 1 +
 3 files changed, 4 insertions(+), 1 deletion(-)

--
2.7.2




------------------------------

Message: 8
Date: Tue,  1 Mar 2016 18:15:25 +0100
From: Bastian Koppelmann <address@hidden>
To: address@hidden
Subject: [Qemu-devel] [PATCH 2/3] target-tricore: Fix
        helper_msub64_q_ssov    not reseting OVF bit
Message-ID:
        <address@hidden>

When this instruction does not produce an overflow the corresponding
bit has to be reset.

Signed-off-by: Bastian Koppelmann <address@hidden>
---
 target-tricore/op_helper.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/target-tricore/op_helper.c b/target-tricore/op_helper.c
index 55f6724..40656c3 100644
--- a/target-tricore/op_helper.c
+++ b/target-tricore/op_helper.c
@@ -1045,6 +1045,8 @@ uint64_t helper_msub64_q_ssov(CPUTriCoreState *env, uint64_t r1, uint32_t r2,
             } else {
                result = INT64_MIN;
             }
+        } else {
+            env->PSW_USB_V = 0;
         }
     } else {
         if (ovf < 0) {
--
2.7.2




------------------------------

Message: 9
Date: Tue, 1 Mar 2016 19:16:29 +0200
From: "Michael S. Tsirkin" <address@hidden>
To: "Denis V. Lunev" <address@hidden>
Cc: Igor Redko <address@hidden>, address@hidden
Subject: Re: [Qemu-devel] [PATCH v3 0/2] virtio-balloon: improve
        balloon statistics
Message-ID: <address@hidden>
Content-Type: text/plain; charset=us-ascii

On Tue, Mar 01, 2016 at 04:44:34PM +0300, Denis V. Lunev wrote:
> On 02/24/2016 10:50 AM, Denis V. Lunev wrote:
> >New counter from the Linux kernel + generic framework to pass currently
> >unknown counters via QMP for debug purposes.
> >
> >Signed-off-by: Denis V. Lunev <address@hidden>
> >CC: Igor Redko <address@hidden>
> >CC: Michael S. Tsirkin <address@hidden>
> >
> >Changes from v2:
> >- put "export unknown counters" code under ifdef
> >
> >Changes from v1:
> >- removed !err in patch 1 by suggestion from Eric
> >
> >
> any decision on this?

Thanks, I will queue this up.

--
MST



------------------------------

Message: 10
Date: Tue, 1 Mar 2016 18:19:06 +0100
From: Michal Privoznik <address@hidden>
To: libvir-list <address@hidden>,       QEMU Developers
        <address@hidden>
Subject: [Qemu-devel] Libvirt accepted to GSoC
Message-ID: <address@hidden>
Content-Type: text/plain; charset=utf-8

Dear community,

let me announce great news: Libvirt applied for this year's Google
Summer of Code and got accepted [1]!

You may recall that in previous years we created a joint organisation
with QEMU/KVM folks and participated that way. However, since the number
of libvirt students was growing and usually exceeded number of QEMU or
KVM students combined it started to become more and more obvious that
libvirt should no longer misuse hospitality of QEMU/KVM volunteers and
try on its own. And it worked. In addition, QEMU/KVM organisation has
been accepted too - join me in congratulating them and saying big thank
you for all of the work that they have done for us in those previous
years! The idea of splitting has been discussed here too [2].

What to do next?
You can still propose ideas, and ideally add them to the list [3]. Or if
you don't feel confident enough, drop me an e-mail and I'll take care of
that.

It's until 14th March that students are able to start filling in their
proposals. And this is where this year differs from the previous ones -
the deadline for proposals is 25th March. Without proposal no student
can be accepted to the program. So you may help by spreading the word too.

Happy coding!

Michal

1: https://summerofcode.withgoogle.com/organizations/5982501017223168/

2: https://www.redhat.com/archives/libvir-list/2016-January/msg01076.html

3: http://wiki.libvirt.org/page/Google_Summer_of_Code_2016



------------------------------

Message: 11
Date: Tue, 1 Mar 2016 18:30:05 +0100
From: Paolo Bonzini <address@hidden>
To: Marc-Andr? Lureau <address@hidden>,     Markus Armbruster
        <address@hidden>
Cc: cam <address@hidden>, Claudio Fontana
        <address@hidden>,   QEMU <address@hidden>, David
        Marchand <address@hidden>
Subject: Re: [Qemu-devel] [PATCH 18/38] ivshmem: Leave INTx alone when
        using MSI-X
Message-ID: <address@hidden>
Content-Type: text/plain; charset=utf-8



On 01/03/2016 18:14, Marc-Andr? Lureau wrote:
> > +    /*
> > +     * Note: we don't use INTx with IVSHMEM_MSI at all, so this is a
> > +     * bald-faced lie then.  But it's a backwards compatible lie.
> > +     */
> >      pci_config_set_interrupt_pin(pci_conf, 1);
>
> I am not sure how much of a problem this is. Apparently, other devices
> claim interrupt and msi (ich, hda, pvscsi)
>
> Better ask someone more familiar with PCI details.

The interrupt pin is read-only and just helps the OS figure out which
interrupt is routed to intx.  If you return early from
ivshmem_update_irq if IVSHMEM_MSI, you should skip this line too.

I think it's better to leave this line in and check

    if (msix_enabled(pci_dev)) {
        return;
    }

in ivshmem_update_irq instead.  This matches what xhci does, for example.

Paolo



------------------------------

Message: 12
Date: Tue,  1 Mar 2016 17:39:36 +0000
From: Peter Maydell <address@hidden>
To: address@hidden
Cc: Ard Biesheuvel <address@hidden>, address@hidden,
        Laszlo Ersek <address@hidden>, address@hidden
Subject: [Qemu-devel] [PATCH v2] hw/arm/virt: Assume EL3 boot rom will
        handle PSCI if one is provided
Message-ID:
        <address@hidden>

If the user passes us an EL3 boot rom, then it is going to want to
implement the PSCI interface itself. In this case, disable QEMU's
internal PSCI implementation so it does not get in the way, and
instead start all CPUs in an SMP configuration at once (the boot
rom will catch them all and pen up the secondaries until needed).
The boot rom code is also responsible for editing the device tree
to include any necessary information about its own PSCI implementation
before eventually passing it to a NonSecure guest.

(This "start all CPUs at once" approach is what both ARM Trusted
Firmware and UEFI expect, since it is what the ARM Foundation Model
does; the other approach would be to provide some emulated hardware
for "start the secondaries" but this is simplest.)

This is a compatibility break, but I don't believe that anybody
was using a secure boot ROM with an SMP configuration. Such a setup
would be somewhat broken since there was nothing preventing nonsecure
guest code from calling the QEMU PSCI function to start up a secondary
core in a way that completely bypassed the secure world.

Signed-off-by: Peter Maydell <address@hidden>
---
v1->v2 changes:
 * rearranged so we initialise vbi->using_psci properly

 hw/arm/virt.c | 32 +++++++++++++++++++++++++-------
 1 file changed, 25 insertions(+), 7 deletions(-)

diff --git a/hw/arm/virt.c b/hw/arm/virt.c
index 4499e2c..9d07b6d 100644
--- a/hw/arm/virt.c
+++ b/hw/arm/virt.c
@@ -73,6 +73,7 @@ typedef struct VirtBoardInfo {
     uint32_t clock_phandle;
     uint32_t gic_phandle;
     uint32_t v2m_phandle;
+    bool using_psci;
 } VirtBoardInfo;

 typedef struct {
@@ -231,6 +232,10 @@ static void fdt_add_psci_node(const VirtBoardInfo *vbi)
     void *fdt = vbi->fdt;
     ARMCPU *armcpu = ARM_CPU(qemu_get_cpu(0));

+    if (!vbi->using_psci) {
+        return;
+    }
+
     qemu_fdt_add_subnode(fdt, "/psci");
     if (armcpu->psci_version == 2) {
         const char comp[] = "arm,psci-0.2\0arm,psci";
@@ -342,7 +347,7 @@ static void fdt_add_cpu_nodes(const VirtBoardInfo *vbi)
         qemu_fdt_setprop_string(vbi->fdt, nodename, "compatible",
                                     armcpu->dtb_compatible);

-        if (vbi->smp_cpus > 1) {
+        if (vbi->using_psci && vbi->smp_cpus > 1) {
             qemu_fdt_setprop_string(vbi->fdt, nodename,
                                         "enable-method", "psci");
         }
@@ -1081,6 +1086,7 @@ static void machvirt_init(MachineState *machine)
     VirtGuestInfoState *guest_info_state = g_malloc0(sizeof *guest_info_state);
     VirtGuestInfo *guest_info = &guest_info_state->info;
     char **cpustr;
+    bool firmware_loaded = bios_name || drive_get(IF_PFLASH, 0, 0);

     if (!cpu_model) {
         cpu_model = "cortex-a15";
@@ -1108,6 +1114,15 @@ static void machvirt_init(MachineState *machine)
         exit(1);
     }

+    /* If we have an EL3 boot ROM then the assumption is that it will
+     * implement PSCI itself, so disable QEMU's internal implementation
+     * so it doesn't get in the way. Instead of starting secondary
+     * CPUs in PSCI powerdown state we will start them all running and
+     * let the boot ROM sort them out.
+     * The usual case is that we do use QEMU's PSCI implementation.
+     */
+    vbi->using_psci = !(vms->secure && firmware_loaded);
+
     /* The maximum number of CPUs depends on the GIC version, or on how
      * many redistributors we can fit into the memory map.
      */
@@ -1175,12 +1190,15 @@ static void machvirt_init(MachineState *machine)
             object_property_set_bool(cpuobj, false, "has_el3", NULL);
         }

-        object_property_set_int(cpuobj, QEMU_PSCI_CONDUIT_HVC, "psci-conduit",
-                                NULL);
+        if (vbi->using_psci) {
+            object_property_set_int(cpuobj, QEMU_PSCI_CONDUIT_HVC,
+                                    "psci-conduit", NULL);

-        /* Secondary CPUs start in PSCI powered-down state */
-        if (n > 0) {
-            object_property_set_bool(cpuobj, true, "start-powered-off", NULL);
+            /* Secondary CPUs start in PSCI powered-down state */
+            if (n > 0) {
+                object_property_set_bool(cpuobj, true,
+                                         "start-powered-off", NULL);
+            }
         }

         if (object_property_find(cpuobj, "reset-cbar", NULL)) {
@@ -1249,7 +1267,7 @@ static void machvirt_init(MachineState *machine)
     vbi->bootinfo.board_id = -1;
     vbi->bootinfo.loader_start = vbi->memmap[VIRT_MEM].base;
     vbi->bootinfo.get_dtb = machvirt_dtb;
-    vbi->bootinfo.firmware_loaded = bios_name || drive_get(IF_PFLASH, 0, 0);
+    vbi->bootinfo.firmware_loaded = firmware_loaded;
     arm_load_kernel(ARM_CPU(first_cpu), &vbi->bootinfo);

     /*
--
1.9.1




------------------------------

Message: 13
Date: Tue,  1 Mar 2016 17:42:56 +0000
From: Peter Maydell <address@hidden>
To: address@hidden
Cc: address@hidden, address@hidden
Subject: [Qemu-devel] [PATCH v2] hw/intc/arm_gic.c: Implement GICv2
        GICC_DIR
Message-ID:
        <address@hidden>

The GICv2 introduces a new CPU interface register GICC_DIR, which
allows an OS to split the "priority drop" and "deactivate interrupt"
parts of interrupt completion. Implement this register.
(Note that the register is at offset 0x1000 in the CPU interface,
which means it is on a different 4K page from all the other registers.)

Signed-off-by: Peter Maydell <address@hidden>
---
changes v1->v2: remove unnecessary gic_update() call

 hw/cpu/a15mpcore.c       |  2 +-
 hw/intc/arm_gic.c        | 45 ++++++++++++++++++++++++++++++++++++++++++++-
 hw/intc/arm_gic_common.c |  2 +-
 3 files changed, 46 insertions(+), 3 deletions(-)

diff --git a/hw/cpu/a15mpcore.c b/hw/cpu/a15mpcore.c
index e9063ad..a221b8f 100644
--- a/hw/cpu/a15mpcore.c
+++ b/hw/cpu/a15mpcore.c
@@ -109,7 +109,7 @@ static void a15mp_priv_realize(DeviceState *dev, Error **errp)
     /* Memory map (addresses are offsets from PERIPHBASE):
      *  0x0000-0x0fff -- reserved
      *  0x1000-0x1fff -- GIC Distributor
-     *  0x2000-0x2fff -- GIC CPU interface
+     *  0x2000-0x3fff -- GIC CPU interface
      *  0x4000-0x4fff -- GIC virtual interface control (not modelled)
      *  0x5000-0x5fff -- GIC virtual interface control (not modelled)
      *  0x6000-0x7fff -- GIC virtual CPU interface (not modelled)
diff --git a/hw/intc/arm_gic.c b/hw/intc/arm_gic.c
index 60ab9b8..0834c2f 100644
--- a/hw/intc/arm_gic.c
+++ b/hw/intc/arm_gic.c
@@ -500,6 +500,41 @@ static uint8_t gic_get_running_priority(GICState *s, int cpu, MemTxAttrs attrs)
     }
 }

+/* Return true if we should split priority drop and interrupt deactivation,
+ * ie whether the relevant EOIMode bit is set.
+ */
+static bool gic_eoi_split(GICState *s, int cpu, MemTxAttrs attrs)
+{
+    if (s->revision != 2) {
+        /* Before GICv2 prio-drop and deactivate are not separable */
+        return false;
+    }
+    if (s->security_extn && !attrs.secure) {
+        return s->cpu_ctlr[cpu] & GICC_CTLR_EOIMODE_NS;
+    }
+    return s->cpu_ctlr[cpu] & GICC_CTLR_EOIMODE;
+}
+
+static void gic_deactivate_irq(GICState *s, int cpu, int irq, MemTxAttrs attrs)
+{
+    int cm = 1 << cpu;
+    int group = gic_has_groups(s) && GIC_TEST_GROUP(irq, cm);
+
+    if (!gic_eoi_split(s, cpu, attrs)) {
+        /* This is UNPREDICTABLE; we choose to ignore it */
+        qemu_log_mask(LOG_GUEST_ERROR,
+                      "gic_deactivate_irq: GICC_DIR write when EOIMode clear");
+        return;
+    }
+
+    if (s->security_extn && !attrs.secure && !group) {
+        DPRINTF("Non-secure DI for Group0 interrupt %d ignored\n", irq);
+        return;
+    }
+
+    GIC_CLEAR_ACTIVE(irq, cm);
+}
+
 void gic_complete_irq(GICState *s, int cpu, int irq, MemTxAttrs attrs)
 {
     int cm = 1 << cpu;
@@ -544,7 +579,11 @@ void gic_complete_irq(GICState *s, int cpu, int irq, MemTxAttrs attrs)
      */

     gic_drop_prio(s, cpu, group);
-    GIC_CLEAR_ACTIVE(irq, cm);
+
+    /* In GICv2 the guest can choose to split priority-drop and deactivate */
+    if (!gic_eoi_split(s, cpu, attrs)) {
+        GIC_CLEAR_ACTIVE(irq, cm);
+    }
     gic_update(s);
 }

@@ -1210,6 +1249,10 @@ static MemTxResult gic_cpu_write(GICState *s, int cpu, int offset,
         s->nsapr[regno][cpu] = value;
         break;
     }
+    case 0x1000:
+        /* GICC_DIR */
+        gic_deactivate_irq(s, cpu, value & 0x3ff, attrs);
+        break;
     default:
         qemu_log_mask(LOG_GUEST_ERROR,
                       "gic_cpu_write: Bad offset %x\n", (int)offset);
diff --git a/hw/intc/arm_gic_common.c b/hw/intc/arm_gic_common.c
index ac8cf42..707d00d 100644
--- a/hw/intc/arm_gic_common.c
+++ b/hw/intc/arm_gic_common.c
@@ -121,7 +121,7 @@ void gic_init_irqs_and_mmio(GICState *s, qemu_irq_handler handler,
          * neither it can use KVM.
          */
         memory_region_init_io(&s->cpuiomem[0], OBJECT(s), ops ? &ops[1] : NULL,
-                              s, "gic_cpu", s->revision == 2 ? 0x1000 : 0x100);
+                              s, "gic_cpu", s->revision == 2 ? 0x2000 : 0x100);
         sysbus_init_mmio(sbd, &s->cpuiomem[0]);
     }
 }
--
1.9.1




------------------------------

Message: 14
Date: Tue, 1 Mar 2016 09:46:07 -0800
From: Richard Henderson <address@hidden>
To: Bastian Koppelmann <address@hidden>,
        address@hidden
Subject: Re: [Qemu-devel] [PATCH 1/7] target-tricore: Add FPU
        infrastructure
Message-ID: <address@hidden>
Content-Type: text/plain; charset=windows-1252

On 03/01/2016 08:24 AM, Bastian Koppelmann wrote:
> +static inline void f_update_psw_flags(CPUTriCoreState *env, bool calc_z)

You probably need it for compiling this intermediate patch, but probably drop
inline and let the compiler choose.  This is quite a bit of code after all...

> +{
> +    int8_t flags = env->fp_status.float_exception_flags;
> +    int32_t some_excp = 0;

You need to set float_exception_flags to zero after reading, so that you don't
re-copy the flags during the next fp insn.

> +#define FPU_FS PSW_USB_C
> +#define FPU_FI PSW_USB_V
> +#define FPU_FV PSW_USB_SV
> +#define FPU_FZ PSW_USB_AV
> +#define FPU_FU PSW_USB_SAV

What an unfortunate spec.  This is an incredibly broken way to implement fp
exception flags.

Exception flags are the sort of thing that's supposed to be collected across a
whole subroutine, without having to worry about the fp exception flags being
clobbered by the surrounding pointer arithmetic.

In order to implement proper IEEE support with this chip, one would have to
implement the fp exception word in software, clearing the PSW bits before each
group of fp instructions and storing the PSW bits after each such group.

Oh well.  You're doing what the manual says...


r~



------------------------------

Message: 15
Date: Tue, 1 Mar 2016 09:46:35 -0800
From: Richard Henderson <address@hidden>
To: Bastian Koppelmann <address@hidden>,
        address@hidden
Subject: Re: [Qemu-devel] [PATCH 2/7] target-tricore: Move general
        CHECK_REG_PAIR of decode_rrr_divide
Message-ID: <address@hidden>
Content-Type: text/plain; charset=windows-1252

On 03/01/2016 08:24 AM, Bastian Koppelmann wrote:
> The add.f and sub.f to be implemented don't use 64 bit registers
> and a general usage of CHECK_REG_PAIR would always generate an
> exception for them.
>
> Signed-off-by: Bastian Koppelmann <address@hidden>
> ---
>  target-tricore/translate.c | 10 ++++++++--
>  1 file changed, 8 insertions(+), 2 deletions(-)

Reviewed-by: Richard Henderson <address@hidden>


r~



------------------------------

Message: 16
Date: Tue, 1 Mar 2016 17:46:45 +0000
From: Andrew Baumann <address@hidden>
To: Stefan Weil <address@hidden>, Peter Maydell
        <address@hidden>
Cc: Paolo Bonzini <address@hidden>,        Peter Crosthwaite
        <address@hidden>,  QEMU Developer <address@hidden>,
        Richard Henderson <address@hidden>
Subject: Re: [Qemu-devel] [PATCH] Use special code for sigsetjmp only
        in cpu-exec.c
Message-ID:
        <address@hidden>

Content-Type: text/plain; charset="utf-8"

> From: Stefan Weil [mailto:address@hidden]
> Sent: Tuesday, 1 March 2016 5:16 AM
>
> Am 01.03.2016 um 13:22 schrieb Peter Maydell:
> > On 1 March 2016 at 11:54, Stefan Weil <address@hidden> wrote:
> >> Am 01.03.2016 um 10:59 schrieb Peter Maydell:
> >>> I don't understand this patch. Why doesn't it work to have
> >>> sigsetjmp() be implemented the same way for every use that
> >>> QEMU makes of it?
> >> It does, as long as the "same way" is the correct one, namely
> >> the one without stack unwinding.
> >>
> >> The current code used to work, but re-arranged include files
> >> broke the working code somewhere in the past:
> >>
> >> include/sysemu/os-win32.h does the right thing at the
> >> wrong place. Its correct definition of sigsetjmp is overwritten by
> >> the definition from a Mingw-w64 system header file which
> >> triggers stack unwinding. Stack unwinding is fatal for
> >> QEMU's generated code.
> >>
> >> My patch makes sure that the critical code in cpu-exec.c
> >> gets the correct definition of sigsetjmp.
> > I think we should fix this by making sure that osdep.h
> > does the right thing -- ie that it gives us the correct
> > definition and prevents mingw's headers from overriding it
> > with the wrong thing (by ensuring that the offending system
> > header is included before we redefine things, or however
> > necessary). This is what osdep.h's purpose is -- to hide
> > annoying system-header workarounds and hacks rather than
> > putting them in the rest of QEMU code.
> >
> >> In addition, it removes code which might or might not
> >> change the default definition of sigsetjmp (depending
> >> on the order of include files). Now all other files beside
> >> cpu-exec.c will use the default behaviour with stack
> >> unwinding.
> > That seems wrong -- we should have the same behaviour for
> > sigsetjmp/siglongjmp everywhere we use it.
> >
> > thanks
> > -- PMM
>
> Technically there is nothing wrong with using different behaviour
> for each setjmp or sigsetjmp.
>
> The "best" solution would be to add any prologue / epilogue which
> is needed for stack unwinding to the generated code. Like that,
> no tricks with redefinitions of setjmp / sigsetjmp would be necessary.
>
> As long as that solution is not available, I'd prefer the variant which
> is implemented by my patch and keep the workaround close to
> the single location where it is needed.
>
> Your alternate solution would require
> inclusion of setjmp.h in include/sysemu/os-win32.h. Then every
> compilation for Windows would get that header file, resulting
> in a (small) overhead. In addition, there would be no stack
> unwinding for any setjmp/longjmp which is not the standard
> behaviour for Windows 64 bit (but which we had until it was
> broken). I simply don't know whether this has unwanted
> side effects (maybe for debugging or with crash dumps) -
> that's the reason why I'd minimize the non-standard behaviour.

FWIW, I don't see a big problem including setjmp.h from os-win32.h and then modifying the definition globally. The overhead you mention is just in compilation time, and it's pretty minor compared to all the other system header files already included. The lack of stack unwinding is also probably not an issue -- AFAIK nothing in qemu uses structured exception handling, and that is the only reason I'm aware of for needing to be able to unwind from a longjmp.

I have been getting along fine with the following local fix:

--- a/include/sysemu/os-win32.h
+++ b/include/sysemu/os-win32.h
@@ -60,6 +60,7 @@
  * If this parameter is NULL, longjump does no stack unwinding.
  * That is what we need for QEMU. Passing the value of register rsp (default)
  * lets longjmp try a stack unwinding which will crash with generated code. */
+# include <setjmp.h>
 # undef setjmp
 # define setjmp(env) _setjmp(env, NULL)
 #endif

Cheers,
Andrew

------------------------------

Message: 17
Date: Tue, 1 Mar 2016 18:53:26 +0100
From: Paolo Bonzini <address@hidden>
To: Andrew Baumann <address@hidden>,      Stefan Weil
        <address@hidden>, Peter Maydell <address@hidden>
Cc: Peter Crosthwaite <address@hidden>,    QEMU Developer
        <address@hidden>, Richard Henderson <address@hidden>
Subject: Re: [Qemu-devel] [PATCH] Use special code for sigsetjmp only
        in cpu-exec.c
Message-ID: <address@hidden>
Content-Type: text/plain; charset=utf-8



On 01/03/2016 18:46, Andrew Baumann wrote:
> --- a/include/sysemu/os-win32.h
> +++ b/include/sysemu/os-win32.h
> @@ -60,6 +60,7 @@
>   * If this parameter is NULL, longjump does no stack unwinding.
>   * That is what we need for QEMU. Passing the value of register rsp (default)
>   * lets longjmp try a stack unwinding which will crash with generated code. */
> +# include <setjmp.h>
>  # undef setjmp
>  # define setjmp(env) _setjmp(env, NULL)
>  #endif

I like this patch or the similar:

diff --git a/include/qemu/osdep.h b/include/qemu/osdep.h
index 4538fdc..322a7da 100644
--- a/include/qemu/osdep.h
+++ b/include/qemu/osdep.h
@@ -77,6 +77,8 @@ extern int daemon(int, int);
 #include <sys/time.h>
 #include <assert.h>
 #include <signal.h>
+/* This is needed on Mingw-w64 where we redefine setjmp below.  */
+#include <setjmp.h>

 #ifdef __OpenBSD__
 #include <sys/signal.h>

which also includes the file on POSIX systems.

Paolo



------------------------------

Message: 18
Date: Tue, 1 Mar 2016 18:54:27 +0100
From: Laszlo Ersek <address@hidden>
To: Peter Maydell <address@hidden>, address@hidden
Cc: Ard Biesheuvel <address@hidden>, address@hidden,
        address@hidden
Subject: Re: [Qemu-devel] [PATCH v2] hw/arm/virt: Assume EL3 boot rom
        will handle PSCI if one is provided
Message-ID: <address@hidden>
Content-Type: text/plain; charset=windows-1252

On 03/01/16 18:39, Peter Maydell wrote:
> If the user passes us an EL3 boot rom, then it is going to want to
> implement the PSCI interface itself. In this case, disable QEMU's
> internal PSCI implementation so it does not get in the way, and
> instead start all CPUs in an SMP configuration at once (the boot
> rom will catch them all and pen up the secondaries until needed).
> The boot rom code is also responsible for editing the device tree
> to include any necessary information about its own PSCI implementation
> before eventually passing it to a NonSecure guest.
>
> (This "start all CPUs at once" approach is what both ARM Trusted
> Firmware and UEFI expect, since it is what the ARM Foundation Model
> does; the other approach would be to provide some emulated hardware
> for "start the secondaries" but this is simplest.)
>
> This is a compatibility break, but I don't believe that anybody
> was using a secure boot ROM with an SMP configuration. Such a setup
> would be somewhat broken since there was nothing preventing nonsecure
> guest code from calling the QEMU PSCI function to start up a secondary
> core in a way that completely bypassed the secure world.
>
> Signed-off-by: Peter Maydell <address@hidden>
> ---
> v1->v2 changes:
>  * rearranged so we initialise vbi->using_psci properly
>
>  hw/arm/virt.c | 32 +++++++++++++++++++++++++-------
>  1 file changed, 25 insertions(+), 7 deletions(-)
>
> diff --git a/hw/arm/virt.c b/hw/arm/virt.c
> index 4499e2c..9d07b6d 100644
> --- a/hw/arm/virt.c
> +++ b/hw/arm/virt.c
> @@ -73,6 +73,7 @@ typedef struct VirtBoardInfo {
>      uint32_t clock_phandle;
>      uint32_t gic_phandle;
>      uint32_t v2m_phandle;
> +    bool using_psci;
>  } VirtBoardInfo;
>
>  typedef struct {
> @@ -231,6 +232,10 @@ static void fdt_add_psci_node(const VirtBoardInfo *vbi)
>      void *fdt = vbi->fdt;
>      ARMCPU *armcpu = ARM_CPU(qemu_get_cpu(0));
>
> +    if (!vbi->using_psci) {
> +        return;
> +    }
> +
>      qemu_fdt_add_subnode(fdt, "/psci");
>      if (armcpu->psci_version == 2) {
>          const char comp[] = "arm,psci-0.2\0arm,psci";
> @@ -342,7 +347,7 @@ static void fdt_add_cpu_nodes(const VirtBoardInfo *vbi)
>          qemu_fdt_setprop_string(vbi->fdt, nodename, "compatible",
>                                      armcpu->dtb_compatible);
>
> -        if (vbi->smp_cpus > 1) {
> +        if (vbi->using_psci && vbi->smp_cpus > 1) {
>              qemu_fdt_setprop_string(vbi->fdt, nodename,
>                                          "enable-method", "psci");
>          }
> @@ -1081,6 +1086,7 @@ static void machvirt_init(MachineState *machine)
>      VirtGuestInfoState *guest_info_state = g_malloc0(sizeof *guest_info_state);
>      VirtGuestInfo *guest_info = &guest_info_state->info;
>      char **cpustr;
> +    bool firmware_loaded = bios_name || drive_get(IF_PFLASH, 0, 0);
>
>      if (!cpu_model) {
>          cpu_model = "cortex-a15";
> @@ -1108,6 +1114,15 @@ static void machvirt_init(MachineState *machine)
>          exit(1);
>      }
>
> +    /* If we have an EL3 boot ROM then the assumption is that it will
> +     * implement PSCI itself, so disable QEMU's internal implementation
> +     * so it doesn't get in the way. Instead of starting secondary
> +     * CPUs in PSCI powerdown state we will start them all running and
> +     * let the boot ROM sort them out.
> +     * The usual case is that we do use QEMU's PSCI implementation.
> +     */
> +    vbi->using_psci = !(vms->secure && firmware_loaded);
> +
>      /* The maximum number of CPUs depends on the GIC version, or on how
>       * many redistributors we can fit into the memory map.
>       */
> @@ -1175,12 +1190,15 @@ static void machvirt_init(MachineState *machine)
>              object_property_set_bool(cpuobj, false, "has_el3", NULL);
>          }
>
> -        object_property_set_int(cpuobj, QEMU_PSCI_CONDUIT_HVC, "psci-conduit",
> -                                NULL);
> +        if (vbi->using_psci) {
> +            object_property_set_int(cpuobj, QEMU_PSCI_CONDUIT_HVC,
> +                                    "psci-conduit", NULL);
>
> -        /* Secondary CPUs start in PSCI powered-down state */
> -        if (n > 0) {
> -            object_property_set_bool(cpuobj, true, "start-powered-off", NULL);
> +            /* Secondary CPUs start in PSCI powered-down state */
> +            if (n > 0) {
> +                object_property_set_bool(cpuobj, true,
> +                                         "start-powered-off", NULL);
> +            }
>          }
>
>          if (object_property_find(cpuobj, "reset-cbar", NULL)) {
> @@ -1249,7 +1267,7 @@ static void machvirt_init(MachineState *machine)
>      vbi->bootinfo.board_id = -1;
>      vbi->bootinfo.loader_start = vbi->memmap[VIRT_MEM].base;
>      vbi->bootinfo.get_dtb = machvirt_dtb;
> -    vbi->bootinfo.firmware_loaded = bios_name || drive_get(IF_PFLASH, 0, 0);
> +    vbi->bootinfo.firmware_loaded = firmware_loaded;
>      arm_load_kernel(ARM_CPU(first_cpu), &vbi->bootinfo);
>
>      /*
>

I compared this with v1 and the discussion under it:

http://thread.gmane.org/gmane.comp.emulators.qemu/395305

The new, explicit condition looks valid.

Also, the location is right; albeit not visible in the context above,
"vbi->using_psci" is set right after "vbi" is set from find_machine_info().

Reviewed-by: Laszlo Ersek <address@hidden>

Thanks
Laszlo



------------------------------

Message: 19
Date: Tue, 1 Mar 2016 17:54:24 +0000
From: Peter Maydell <address@hidden>
To: Paolo Bonzini <address@hidden>
Cc: Stefan Weil <address@hidden>,       Peter Crosthwaite
        <address@hidden>,  QEMU Developer <address@hidden>,
        Andrew Baumann <address@hidden>,  Richard Henderson
        <address@hidden>
Subject: Re: [Qemu-devel] [PATCH] Use special code for sigsetjmp only
        in      cpu-exec.c
Message-ID:
        <address@hidden>
Content-Type: text/plain; charset=UTF-8

On 1 March 2016 at 17:53, Paolo Bonzini <address@hidden> wrote:
>
>
> On 01/03/2016 18:46, Andrew Baumann wrote:
>> --- a/include/sysemu/os-win32.h
>> +++ b/include/sysemu/os-win32.h
>> @@ -60,6 +60,7 @@
>>   * If this parameter is NULL, longjump does no stack unwinding.
>>   * That is what we need for QEMU. Passing the value of register rsp (default)
>>   * lets longjmp try a stack unwinding which will crash with generated code. */
>> +# include <setjmp.h>
>>  # undef setjmp
>>  # define setjmp(env) _setjmp(env, NULL)
>>  #endif
>
> I like this patch or the similar:
>
> diff --git a/include/qemu/osdep.h b/include/qemu/osdep.h
> index 4538fdc..322a7da 100644
> --- a/include/qemu/osdep.h
> +++ b/include/qemu/osdep.h
> @@ -77,6 +77,8 @@ extern int daemon(int, int);
>  #include <sys/time.h>
>  #include <assert.h>
>  #include <signal.h>
> +/* This is needed on Mingw-w64 where we redefine setjmp below.  */
> +#include <setjmp.h>
>
>  #ifdef __OpenBSD__
>  #include <sys/signal.h>
>
> which also includes the file on POSIX systems.

Yes, that would get my vote. (Followup cleanup -- remove the now
unneeded includes of setjmp.h elsewhere.)

thanks
-- PMM



------------------------------

Message: 20
Date: Tue, 1 Mar 2016 14:56:52 -0300
From: Martin Galvan <address@hidden>
To: Eric Blake <address@hidden>
Cc: Peter Maydell <address@hidden>, address@hidden,        QEMU
        Developers <address@hidden>, address@hidden,
        address@hidden, address@hidden,        Paolo Bonzini
        <address@hidden>, address@hidden,       address@hidden,
        Andreas F?rber <address@hidden>,      address@hidden, Richard
        Henderson <address@hidden>
Subject: Re: [Qemu-devel] [PATCH v2 01/13] Use unsigned types for the
        'len' argument of all memory read/write functions
Message-ID:
        <address@hidden>
Content-Type: text/plain; charset=UTF-8

On Tue, Mar 1, 2016 at 1:05 PM, Eric Blake <address@hidden> wrote:
> On 03/01/2016 08:57 AM, Martin Galvan wrote:
>
> Missing a S-o-b line; we cannot accept patches unless you sign them:
> http://wiki.qemu.org/Contribute/SubmitAPatch
> https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/Documentation/SubmittingPatches?id=f6f94e2a#n297

Oh, I forgot that. I did have a s-o-b in v1, I just forgot to add it here.

> Subject line is long, and lacking a 'topic: summary' prefix.  I'd suggest:
>
> mem: use unsigned 'len' for read/write
>
> Then give more details, if needed, in the body of the commit message.

Yeah, I thought it was too long myself. Will do.

> Also, your threading didn't work right.  Patch 1/13 was sent with:
>
> References:
> <address@hidden>
>
> but with no In-Reply-To:. Meanwhile, the 00/13 cover letter was sent with:
>
> Message-Id:
> <address@hidden>
>
> which is subtly different from the references of all the other patches,
> making it appear as separate threads.

Yeah, I think I messed that up. Sorry.

>>      FILE *f;
>> -    uint32_t l;
>> +    size_t l;
>
> These are both unsigned types.  So based on the subject line alone, this
> doesn't fit in the patch, unless the commit message body goes into more
> details on why you are changing the size of the type, and not just the
> signedness.

You're right, I recall changing that for size correctness, rather than
signedness. I'll mention in the commit message that I also fixed those
issues in a couple of places.

> (adding an appropriate prefix for each maintainer that you are targetting will help).

I actually thought of that, but the files grouped into each e-mail
weren't necessarily related (e.g. Paolo's include some stuff in exec/
and kvm-all.c). I'll see what I can do, though.

Before I re-send them, however, it'd be nice if the patches themselves
could be reviewed.



------------------------------

Message: 21
Date: Tue, 01 Mar 2016 19:03:10 +0100
From: Greg Kurz <address@hidden>
To: David Gibson <address@hidden>
Cc: Alexey Kardashevskiy <address@hidden>, address@hidden,
        Alexander Graf <address@hidden>, address@hidden
Subject: [Qemu-devel] [PATCH] target-ppc: fix sync of SPR_SDR1 with
        KVM
Message-ID: <address@hidden>
Content-Type: text/plain; charset="utf-8"

The gdbstub can't access guest memory with current master. This is what you
get in gdb:

0x00000000100009b8 in main (argc=<error reading variable: Cannot access memory
at address 0x3fffce4d3620>, argv=<error reading variable: Cannot access memory
at address 0x3fffce4d3628>) at fp.c:11

Bisect leads to the following commit:

commit fa48b4328c39b2532e47efcfcba6d4031512f514
Author: David Gibson <address@hidden>
Date:   Tue Feb 9 09:30:21 2016 +1000

    target-ppc: Remove hack for ppc_hash64_load_hpte*() with HV KVM

Looking at the env->external_htab users, I've spotted a behaviour change in
kvm_arch_get_registers(), which now always calls ppc_store_sdr1().

Checking kvmppc_kern_htab, like it is done in the MMU helpers, fixes the
issue.

Signed-off-by: Greg Kurz <address@hidden>
---
 target-ppc/kvm.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/target-ppc/kvm.c b/target-ppc/kvm.c
index d67c169ba324..dbc37f25af2b 100644
--- a/target-ppc/kvm.c
+++ b/target-ppc/kvm.c
@@ -1190,7 +1190,7 @@ int kvm_arch_get_registers(CPUState *cs)
             return ret;
         }

-        if (!env->external_htab) {
+        if (!kvmppc_kern_htab && !env->external_htab) {
             ppc_store_sdr1(env, sregs.u.s.sdr1);
         }





------------------------------

Message: 22
Date: Tue, 1 Mar 2016 10:10:52 -0800
From: Richard Henderson <address@hidden>
To: Bastian Koppelmann <address@hidden>,
        address@hidden
Subject: Re: [Qemu-devel] [PATCH 3/7] target-tricore: add add.f/sub.f
        instructions
Message-ID: <address@hidden>
Content-Type: text/plain; charset=windows-1252

> +    f_set_flags(env);                                                          \

You shouldn't need to set the flags every instruction.
You ought to be able to limit the changes to reset and
stores to the PSW.

> +    arg1 = float32_squash_input_denormal(arg1, &env->fp_status);               \
> +    arg2 = float32_squash_input_denormal(arg2, &env->fp_status);               \
> +                                                                               \
> +    if (float32_is_any_nan(arg1) || float32_is_any_nan(arg2)) {                \
> +        f_result = QUIET_NAN;                                                  \
> +        if (float32_is_signaling_nan(arg1) ||                                  \
> +            float32_is_signaling_nan(arg2)) {                                  \
> +            env->fp_status.float_exception_flags |= float_flag_invalid;        \
> +        }                                                                      \
> +    } else if (f_is_pos_inf(arg1) && f_is_neg_inf(arg2)) {                     \
> +        f_result = ADD_NAN;                                                    \
> +    } else if (f_is_pos_inf(arg2) && f_is_neg_inf(arg1)) {                     \
> +        f_result = ADD_NAN;                                                    \
> +    } else {                                                                   \
> +        f_result = float32_##name(arg1, arg2 , &env->fp_status);               \
> +    }                                                                          \

If we assume that exceptional situations are, well, exceptional, then we can
re-order this to

  f_result = float32_op(arg1, arg2, &env->fp_status);
  flags = env->fp_status.float_exception_flags;
  if (flags) {
      /* If the output is a NaN, but the inputs aren't,
         we return a unique value.  */
      if ((flags & float_flag_invalid)
          && !float32_is_any_nan(arg1)
          && !float32_is_any_nan(arg2)) {
          f_result = ADD_NAN;
      }
      f_update_psw_flags(env, flags, false);
  }

This does assume that fp_status.default_nan_mode = 1, so that
float32_default_nan is returned.  Which means that first patch should touch
fpu/softfloat-specialize.h to add tricore to the list of those defaulting to
0x7fc00000.


r~



------------------------------

Message: 23
Date: Tue, 01 Mar 2016 18:12:52 +0000
From: Alex Benn?e <address@hidden>
To: Fam Zheng <address@hidden>
Cc: address@hidden, address@hidden, address@hidden,
        address@hidden, address@hidden,     Paolo Bonzini
        <address@hidden>, address@hidden,        address@hidden
Subject: Re: [Qemu-devel] [PATCH v2 02/15] Makefile: Rules for docker
        testing
Message-ID: <address@hidden>
Content-Type: text/plain; charset="us-ascii"


Fam Zheng <address@hidden> writes:

> This adds a group of make targets to run docker tests, all are available
> in source tree without running ./configure.
>
> The usage is shown by "make docker".
>
<snip>

OK I've made some tweaks which I think improve the generation and allow
for re-creation of containers when the rules change. I still need an
easy way to see the failed build when it does fail. I think this
requires "docker logs" magic.

Anyway the current state of my Makefile.include attached:

-------------- next part --------------
A non-text attachment was scrubbed...
Name: Makefile.include
Type: application/octet-stream
Size: 4016 bytes
Desc: Current hacked up makfile.include
URL: <http://lists.nongnu.org/archive/html/qemu-devel/attachments/20160301/ff089a12/attachment.obj>
-------------- next part --------------


--
Alex Benn?e

------------------------------

Message: 24
Date: Tue, 1 Mar 2016 19:17:04 +0100
From: Igor Mammedov <address@hidden>
To: David Gibson <address@hidden>
Cc: address@hidden, address@hidden, Peter Krempa
        <address@hidden>,   address@hidden, Eduardo Habkost
        <address@hidden>,  address@hidden, Markus Armbruster
        <address@hidden>,    address@hidden, address@hidden,
        address@hidden,    address@hidden, address@hidden,
        address@hidden
Subject: Re: [Qemu-devel] [RFC] QMP: add query-hotpluggable-cpus
Message-ID: <address@hidden>
Content-Type: text/plain; charset=US-ASCII

On Tue, 1 Mar 2016 11:49:30 +0100
Igor Mammedov <address@hidden> wrote:

> For sPAPR it would be:
>
>   device_add socket-type,core=X
typo here, should be:

device_add core-type,core=X



------------------------------

Message: 25
Date: Tue, 1 Mar 2016 18:21:38 +0000
From: Peter Maydell <address@hidden>
To: Andrew Baumann <address@hidden>
Cc: Gr?gory ESTRADE <address@hidden>,        Stefan Weil
        <address@hidden>,       Peter Crosthwaite <address@hidden>,
        QEMU Developers <address@hidden>, qemu-arm
        <address@hidden>,  Paolo Bonzini <address@hidden>
Subject: Re: [Qemu-devel] [PATCH 1/4] bcm2835_peripherals: enable
        sdhci pending-insert quirk for raspberry pi
Message-ID:
        <address@hidden>
Content-Type: text/plain; charset=UTF-8

On 27 February 2016 at 00:16, Andrew Baumann
<address@hidden> wrote:
> Signed-off-by: Andrew Baumann <address@hidden>
> ---
>  hw/arm/bcm2835_peripherals.c | 7 +++++++
>  1 file changed, 7 insertions(+)
>
> diff --git a/hw/arm/bcm2835_peripherals.c b/hw/arm/bcm2835_peripherals.c
> index 6d66fa0..6ce9cd1 100644
> --- a/hw/arm/bcm2835_peripherals.c
> +++ b/hw/arm/bcm2835_peripherals.c
> @@ -171,6 +171,13 @@ static void bcm2835_peripherals_realize(DeviceState *dev, Error **errp)
>          return;
>      }
>
> +    object_property_set_bool(OBJECT(&s->sdhci), true, "pending-insert-quirk",
> +                             &err);
> +    if (err) {
> +        error_propagate(errp, err);
> +        return;
> +    }
> +
>      object_property_set_bool(OBJECT(&s->sdhci), true, "realized", &err);
>      if (err) {
>          error_propagate(errp, err);
> --
> 2.5.3

Reviewed-by: Peter Maydell <address@hidden>

thanks
-- PMM



------------------------------

_______________________________________________
Qemu-devel mailing list
address@hidden
https://lists.nongnu.org/mailman/listinfo/qemu-devel


End of Qemu-devel Digest, Vol 156, Issue 15
*******************************************


reply via email to

[Prev in Thread] Current Thread [Next in Thread]