Re: [Qemu-devel] [PATCH v7 0/5] IOMMU: intel_iommu support map and unmap notifications

[Lan Tianyu]

On 2016年12月01日 12:21, Tian, Kevin wrote:
>> I am thinking about this replay thing recently and now I start to
>> > doubt whether the whole vt-d vIOMMU framework suites this...
>> > 
>> > Generally speaking, current work is throwing away the IOMMU "domain"
>> > layer here. We maintain the mapping only per device, and we don't care
>> > too much about which domain it belongs. This seems problematic.
>> > 
>> > A simplest wrong case for this is (let's assume cache-mode is
>> > enabled): if we have two assigned devices A and B, both belong to the
>> > same domain 1. Meanwhile, in domain 1 assume we have one mapping which
>> > is the first page (iova range 0-0xfff). Then, if guest wants to
>> > invalidate the page, it'll notify VT-d vIOMMU with an invalidation
>> > message. If we do this invalidation per-device, we'll need to UNMAP
>> > the region twice - once for A, once for B (if we have more devices, we
>> > will unmap more times), and we can never know we have done duplicated
>> > work since we don't keep domain info, so we don't know they are using
>> > the same address space. The first unmap will work, and then we'll
>> > possibly get some errors on the rest of dma unmap failures.
> Tianyu and I discussed there is a bigger problem: today VFIO assumes 
> only one address space per container, which is fine w/o vIOMMU (all devices 
> in 
> same container share same GPA->HPA translation). However it's not the case
> when vIOMMU is enabled, because guest Linux implements per-device 
> IOVA space. If a VFIO container includes multiple devices, it means 
> multiple address spaces required per container...
> 

Hi All:
Some updates about relationship about assigned device and container.

If vIOMMU is disabled, all assigned devices will use global
address_space_memory as address space (Detail please see
pci_device_iommu_address_space()). VFIO creates container according to
address space and so all assigned devices will put into one container.

If vIOMMU is enabled, Intel vIOMMU will allocate separate address spaces
for each assigned devices and then VFIO will create different container
for each assigned device. In other word, it will be one assigned device
per container when vIOMMU is enabled. The original concern won't take
place. This is my understanding and please correct me if something wrong.

-- 
Best regards
Tianyu Lan

[Qemu-devel] QEMU Advent Calendar 2016

[Thomas Huth]

 Hi all,

it's now December 1st, so the first door of the QEMU Advent Calendar
2016 can now be opened:

http://www.qemu-advent-calendar.org/2016/#day-1

For the next 23 days, we are going to present a new disk image each day,
so if you like, stop by regularly (I won't send a reminder each day).

And yes, we still need more disk images to complete the run this year -
if you are interested in contributing, please have a look at my original
mail below.

 Enjoy,
  Thomas


On 17.09.2016 15:05, Thomas Huth wrote:
> 
>  Hi all!
> 
> This year, we are celebrating the 10th anniversary of KVM [1] (and the
> 25th anniversary of Linux), so to contribute to this celebration, we
> would like to reanimate the QEMU Advent Calendar.
> 
> If you didn't see the previous QEMU Advent Calendar 2014 yet, have a look at
> 
>   http://www.qemu-advent-calendar.org/
> 
> This year, too, the QEMU Advent Calendar 2016 will be a website that
> reveals a new disk image for download each day in December until the
> holiday season starts. Launching the disk image under QEMU will bring up
> a nice surprise!
> 
> But to be able to make this happen, we need help from people who
> - have ideas for disk images
> - would like to prepare one or more disk images.
> Ideally, you have an idea for a disk image and also prepare it yourself.
> But we also are glad to get just the ideas, or help from people who
> would like to prepare a disk image with the idea from somebody else!
> 
> Disk image requirements:
>  * We need 24 disk images (for the first 24 days of December)
>  * Content must be freely redistributable (i.e. no proprietary
>license that prevents distribution). For GPL based software,
>you need to provide the source code, too.
>  * Provide a name and a short description of the disk image
>(e.g. with hints on what to try)
>  * Provide a ./run shell script that prints out the name and
>description/hints and launches QEMU
>  * Provide a screenshot/image/logo for the website
>  * Size should be ideally under 100 MB per disk image
> 
> Are you interested in participating? Then please reply to this email
> (off-list if you do not want to spoil your idea for disk images).
> 
> Or do you have questions? Then feel free to reply or ask on the #qemu
> channel on irc.oftc.net, too.
> 
>  Thomas & Kashyap
> 
> 
> PS: The QEMU Advent Calendar 2016 is a secular calendar (not
> religious). The idea is for the QEMU community to create a fun
> experience to share with everyone, and to celebrate the 10th anniversary
> of KVM. You don't need to celebrate Christmas or another religious
> festival to participate!

Re: [Qemu-devel] [PATCH v7 0/5] IOMMU: intel_iommu support map and unmap notifications

[Lan Tianyu]

On 2016年11月30日 17:23, Peter Xu wrote:
> On Mon, Nov 28, 2016 at 05:51:50PM +0200, Aviv B.D wrote:
>> * intel_iommu's replay op is not implemented yet (May come in different 
>> patch 
>>   set).
>>   The replay function is required for hotplug vfio device and to move 
>> devices 
>>   between existing domains.
> 
> I am thinking about this replay thing recently and now I start to
> doubt whether the whole vt-d vIOMMU framework suites this...
> 
> Generally speaking, current work is throwing away the IOMMU "domain"
> layer here. We maintain the mapping only per device, and we don't care
> too much about which domain it belongs. This seems problematic.
> 
> A simplest wrong case for this is (let's assume cache-mode is
> enabled): if we have two assigned devices A and B, both belong to the
> same domain 1. Meanwhile, in domain 1 assume we have one mapping which
> is the first page (iova range 0-0xfff). Then, if guest wants to
> invalidate the page, it'll notify VT-d vIOMMU with an invalidation
> message. If we do this invalidation per-device, we'll need to UNMAP
> the region twice - once for A, once for B (if we have more devices, we
> will unmap more times), and we can never know we have done duplicated
> work since we don't keep domain info, so we don't know they are using
> the same address space. The first unmap will work, and then we'll
> possibly get some errors on the rest of dma unmap failures.


Hi Peter:
According VTD spec 6.2.2.1, "Software must ensure that, if multiple
context-entries (or extended-context-entries) are programmed
with the same Domain-id (DID), such entries must be programmed with same
value for the secondlevel page-table pointer (SLPTPTR) field, and same
value for the PASID Table Pointer (PASIDTPTR) field.".

So if two assigned device may have different IO page table, they should
be put into different domains.


> 
> Looks like we just cannot live without knowing this domain layer.
> Because the address space is binded to the domain. If we want to sync
> the address space (here to setup a correct shadow page table), we need
> to do it per-domain.
> 
> What I can think of as a solution is that we introduce this "domain"
> layer - like a memory region per domain. When invalidation happens,
> it's per-domain, not per-device any more (actually I guess that's what
> current vt-d iommu driver in kernel is doing, we just ignored it - we
> fetch the devices that matches the domain ID). We can/need to maintain
> something different, like sid <-> domain mappings (we can do this as
> long as we are notified when context entries changed), per-domain
> mappings (just like per-device mappings that we are trying to build in
> this series, but what we really need is IMHO per domain one), etc.
> When device switches domain, we switch the IOMMU memory region
> accordingly.
> 
> Does this make any sense? Comments are greatly welcomed (especially
> from AlexW and DavidG).
> 
> Thanks,
> 
> -- peterx
> 


-- 
Best regards
Tianyu Lan

Re: [Qemu-devel] GTK UI keycodes broken under Wayland

[Thomas Huth]

On 01.12.2016 08:24, Stefan Hajnoczi wrote:
> I recently upgraded to Fedora 25 which runs Wayland by default.
> 
> The GTK UI is now sending unknown keycodes to the guests.  Although
> alphanumeric keys work, the cursor keys are broken.
> 
> There is X11-specific code for keycode mapping in ui/gtk.c.  Perhaps
> something is needed to make that work under Wayland?

There is certainly something missing for Wayland. Somebody already
reported this issue here and posted a "quick and dirty" patch:

https://bugs.launchpad.net/qemu/+bug/1578192

 Thomas

Re: [Qemu-devel] QEMU Advent Calendar 2016

[Stefan Hajnoczi]

On Thu, Dec 1, 2016 at 8:24 AM, Thomas Huth  wrote:
> it's now December 1st, so the first door of the QEMU Advent Calendar
> 2016 can now be opened:
>
> http://www.qemu-advent-calendar.org/2016/#day-1
>
> For the next 23 days, we are going to present a new disk image each day,
> so if you like, stop by regularly (I won't send a reminder each day).
>
> And yes, we still need more disk images to complete the run this year -
> if you are interested in contributing, please have a look at my original
> mail below.

Thanks for running QEMU Advent Calendar 2016.  I'll send you the 2
disk images we discussed this weekend.  Looking forward to seeing what
you have in store for us!

Stefan

Re: [Qemu-devel] Support for using TCG frontend as a library

[Paolo Bonzini]

- Original Message -
> From: "Alessandro Di Federico" 
> To: "Paolo Bonzini" , "Liviu Ionescu" 
> Cc: "qemu-devel" 
> Sent: Thursday, December 1, 2016 12:01:12 AM
> Subject: Re: [Qemu-devel] Support for using TCG frontend as a library
> 
> On Tue, 29 Nov 2016 17:26:59 +0100
> Paolo Bonzini  wrote:
> 
> > It's pretty clean!  I would rather avoid the duplicate enums, possibly
> > by automatically generating large parts of ptc.h, but that's pretty
> > much it.  I see that you check that the constants match (that cpp
> > stuff is disgusting :)), and that is already a good thing.
> 
> Does QEMU already have some mechanism to generate code? Otherwise I can
> try to factor out the enum in a file that can be included in multiple
> places.

If you count scripts/shaderinclude.pl, scripts/feature_to_c.sh and
the like, yes.  The biggest is probably tracetool.  It's ad hoc.

> > As to dumping the assembly code, I think that's beyond the scope of
> > QEMU---rather, if there is an existing library to do so, QEMU would
> > like to use it because currently we're stuck with an old
> > GPLv2-compatible version of GNU binutils.  For everything else it
> > makes sense to use a "librarified" QEMU frontend and even backend.
> 
> My idea was to offer it externally, if available, more for debugging
> purposes than for actual usage, in a "best-effort" way, let's say.
> Isolating the backend too makes sense, but I'm not sure how much
> interest there is on this, I'll first focus on exposing the frontends,
> which is the killer feature for many of us.

Yes, of course.

> > It would even be better, I think, to make linux-user a client of the
> > library itself, because this will prevent bitrot.
> 
> This is something I didn't think about, it might be interesting indeed.
> But why only linux-user and not full system emulation too?

It would simplify the library.  The front-end and helpers have some differences
between usermode and softmmu, and the latter is much more intertwined with
the rest of the QEMU infrastructure (MMU indices, limits on multi-page
translations, etc.)

> If most how the new helpers will be pure it might make sense to make a
> one-time effort to annotate existing helpers with the list of parts of
> the CPU they might access. I currently have an LLVM pass which analyzes
> the helpers and collect programmatically this information.

It can also be used to guide the conversion to pure helpers, I guess.
For example, helpers such as helper_divb_AL should definitely get and
return globals instead of reading/writing to CPUX86State (in the specific
case of division, of course they would keep the side effects because they
can raise a division by zero exception).

Paolo

Re: [Qemu-devel] [kvm-unit-tests PATCH v13 1/4] arm: Define macros for accessing system registers

[Andrew Jones]

Should this be From: Andre?

On Wed, Nov 30, 2016 at 11:16:39PM -0600, Wei Huang wrote:
> This patch defines four macros to assist creating system register
> accessors under both ARMv7 and AArch64:
>* DEFINE_GET_SYSREG32(name, ...)
>* DEFINE_SET_SYSREG32(name, ...)
>* DEFINE_GET_SYSREG64(name, ...)
>* DEFINE_SET_SYSREG64(name, ...)
> These macros are translated to inline functions with consistent naming,
> get_##name() and set_##name(), which can be used by C code directly.
> 
> Signed-off-by: Andre Przywara 
> Signed-off-by: Wei Huang 
> ---
>  lib/arm/asm/processor.h   | 37 -
>  lib/arm64/asm/processor.h | 35 ---
>  2 files changed, 60 insertions(+), 12 deletions(-)
> 
> diff --git a/lib/arm/asm/processor.h b/lib/arm/asm/processor.h
> index f25e7ee..3ca6b42 100644
> --- a/lib/arm/asm/processor.h
> +++ b/lib/arm/asm/processor.h
> @@ -33,13 +33,40 @@ static inline unsigned long current_cpsr(void)
>  
>  #define current_mode() (current_cpsr() & MODE_MASK)
>  
> -static inline unsigned int get_mpidr(void)
> -{
> - unsigned int mpidr;
> - asm volatile("mrc p15, 0, %0, c0, c0, 5" : "=r" (mpidr));
> - return mpidr;
> +#define DEFINE_GET_SYSREG32(name, opc1, crn, crm, opc2)  
> \
> +static inline uint32_t get_##name(void)  
> \
> +{\
> + uint32_t reg;   \
> + asm volatile("mrc p15, " #opc1 ", %0, " #crn ", " #crm ", " \
> +  #opc2 : "=r" (reg));   \
> + return reg; \
> +}
> +
> +#define DEFINE_SET_SYSREG32(name, opc1, crn, crm, opc2)  
> \
> +static inline void set_##name(uint32_t value)
> \
> +{\
> + asm volatile("mcr p15, " #opc1 ", %0, " #crn ", " #crm ", " \
> +  #opc2 :: "r" (value)); \
   ^ nit: no space here, checkpatch would complain
> +}
> +
> +#define DEFINE_GET_SYSREG64(name, opc, crm)  \
> +static inline uint64_t get_##name(void)  
> \
> +{\
> + uint32_t lo, hi;\
> + asm volatile("mrrc p15, " #opc ", %0, %1, " #crm\
> +  : "=r" (lo), "=r" (hi));   \
> + return (uint64_t)hi << 32 | lo; \
> +}
> +
> +#define DEFINE_SET_SYSREG64(name, opc, crm)  \
> +static inline void set_##name(uint64_t value)
> \
> +{\
> + asm volatile("mcrr p15, " #opc ", %0, %1, " #crm\
> +  :: "r" (value & 0x), "r" (value >> 32));   \
>  }
>  
> +DEFINE_GET_SYSREG32(mpidr, 0, c0, c0, 5)
> +
>  /* Only support Aff0 for now, up to 4 cpus */
>  #define mpidr_to_cpu(mpidr) ((int)((mpidr) & 0xff))
>  
> diff --git a/lib/arm64/asm/processor.h b/lib/arm64/asm/processor.h
> index 84d5c7c..dfa75eb 100644
> --- a/lib/arm64/asm/processor.h
> +++ b/lib/arm64/asm/processor.h
> @@ -66,14 +66,35 @@ static inline unsigned long current_level(void)
>   return el & 0xc;
>  }
>  
> -#define DEFINE_GET_SYSREG32(reg) \
> -static inline unsigned int get_##reg(void)   \
> -{\
> - unsigned int reg;   \
> - asm volatile("mrs %0, " #reg "_el1" : "=r" (reg));  \
> - return reg; \
> +#define DEFINE_GET_SYSREG32(reg, el) \
> +static inline uint32_t get_##reg(void)   
> \
> +{\
> + uint32_t reg;   \
> + asm volatile("mrs %0, " #reg "_" #el : "=r" (reg)); \
> + return reg; \
>  }
> -DEFINE_GET_SYSREG32(mpidr)
> +
> +#define DEFINE_SET_SYSREG32(reg, el) \
> +static inline void set_##reg(uint32_t value) \
> +{\
> + asm volatile("msr " #reg "_" #el ", %0" :: "r" (value));\
> +}
> +
> +#define DEFINE_GET_SYSREG64(reg, el) \
> +static inline uint64_t get_##reg(void)   
> \
> +{  

Re: [Qemu-devel] [kvm-unit-tests PATCH v13 2/4] arm: Add PMU test

[Andrew Jones]

On Wed, Nov 30, 2016 at 11:16:40PM -0600, Wei Huang wrote:
> From: Christopher Covington 
> 
> Beginning with a simple sanity check of the control register, add
> a unit test for the ARM Performance Monitors Unit (PMU). PMU register
> was read using the newly defined macros.
> 
> Signed-off-by: Christopher Covington 
> Signed-off-by: Wei Huang 
> Reviewed-by: Andrew Jones 
> ---
>  arm/Makefile.common |  3 ++-
>  arm/pmu.c   | 62 
> +
>  arm/unittests.cfg   |  5 +
>  3 files changed, 69 insertions(+), 1 deletion(-)
>  create mode 100644 arm/pmu.c
> 
> diff --git a/arm/Makefile.common b/arm/Makefile.common
> index f37b5c2..5da2fdd 100644
> --- a/arm/Makefile.common
> +++ b/arm/Makefile.common
> @@ -12,7 +12,8 @@ endif
>  tests-common = \
>   $(TEST_DIR)/selftest.flat \
>   $(TEST_DIR)/spinlock-test.flat \
> - $(TEST_DIR)/pci-test.flat
> + $(TEST_DIR)/pci-test.flat \
> + $(TEST_DIR)/pmu.flat
>  
>  all: test_cases
>  
> diff --git a/arm/pmu.c b/arm/pmu.c
> new file mode 100644
> index 000..1fe2b1a
> --- /dev/null
> +++ b/arm/pmu.c
> @@ -0,0 +1,62 @@
> +/*
> + * Test the ARM Performance Monitors Unit (PMU).
> + *
> + * Copyright (c) 2015-2016, The Linux Foundation. All rights reserved.
> + *
> + * This program is free software; you can redistribute it and/or modify it
> + * under the terms of the GNU Lesser General Public License version 2.1 and
> + * only version 2.1 as published by the Free Software Foundation.
> + *
> + * This program is distributed in the hope that it will be useful, but 
> WITHOUT
> + * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
> + * FITNESS FOR A PARTICULAR PURPOSE. See the GNU Lesser General Public 
> License
> + * for more details.
> + */
> +#include "libcflat.h"
> +#include "asm/barrier.h"
> +#include "asm/processor.h"
> +
> +#define PMU_PMCR_N_SHIFT   11
> +#define PMU_PMCR_N_MASK0x1f
> +#define PMU_PMCR_ID_SHIFT  16
> +#define PMU_PMCR_ID_MASK   0xff
> +#define PMU_PMCR_IMP_SHIFT 24
> +#define PMU_PMCR_IMP_MASK  0xff
> +
> +#if defined(__arm__)
> +DEFINE_GET_SYSREG32(pmcr, 0, c9, c12, 0)
> +#elif defined(__aarch64__)
> +DEFINE_GET_SYSREG32(pmcr, el0)
> +#endif
> +
> +/*
> + * As a simple sanity check on the PMCR_EL0, ensure the implementer field 
> isn't
> + * null. Also print out a couple other interesting fields for diagnostic
> + * purposes. For example, as of fall 2016, QEMU TCG mode doesn't implement
> + * event counters and therefore reports zero event counters, but hopefully
> + * support for at least the instructions event will be added in the future 
> and
> + * the reported number of event counters will become nonzero.
> + */
> +static bool check_pmcr(void)
> +{
> + uint32_t pmcr;

So based on my comments from the previous patch, pmcr should be
'unsigned int'

> +
> + pmcr = get_pmcr();
> +
> + report_info("PMU implementer/ID code/counters: 0x%x(\"%c\")/0x%x/%d",
> + (pmcr >> PMU_PMCR_IMP_SHIFT) & PMU_PMCR_IMP_MASK,
> + ((pmcr >> PMU_PMCR_IMP_SHIFT) & PMU_PMCR_IMP_MASK) ? : ' ',
> + (pmcr >> PMU_PMCR_ID_SHIFT) & PMU_PMCR_ID_MASK,
> + (pmcr >> PMU_PMCR_N_SHIFT) & PMU_PMCR_N_MASK);
> +
> + return ((pmcr >> PMU_PMCR_IMP_SHIFT) & PMU_PMCR_IMP_MASK) != 0;
> +}
> +
> +int main(void)
> +{
> + report_prefix_push("pmu");
> +
> + report("Control register", check_pmcr());
> +
> + return report_summary();
> +}
> diff --git a/arm/unittests.cfg b/arm/unittests.cfg
> index ae32a42..816f494 100644
> --- a/arm/unittests.cfg
> +++ b/arm/unittests.cfg
> @@ -58,3 +58,8 @@ groups = selftest
>  [pci-test]
>  file = pci-test.flat
>  groups = pci
> +
> +# Test PMU support
> +[pmu]
> +file = pmu.flat
> +groups = pmu
> -- 
> 1.8.3.1
> 
>

drew 

Re: [Qemu-devel] QEMU 2.8 release approaching

[Stefan Hajnoczi]

On Wed, Nov 30, 2016 at 3:42 PM, Stefan Hajnoczi  wrote:
> If you are currently looking into pending issues or have bug fixes
> needing attention from maintainers, please reply to this email.

Laszlo, Gonglei,
Thanks for pointing out these patches that should be included in QEMU 2.8.

Patches still need to go through the maintainers identified by
scripts/get_maintainer.pl.  I'll receive pull requests from them.

Please let me know if there is no maintainer and I'll merge them myself.

Thanks,
Stefan

[Qemu-devel] [PATCH] qemu-timer: check active_timers outside lock/event

[Paolo Bonzini]

This avoids taking the active_timers_lock or resetting/setting the
timers_done_ev if there are no active timers.  This removes a small
(2-3%) source of overhead for dataplane.  The list is then checked
again inside the lock, or a NULL pointer could be dereferenced.

Signed-off-by: Paolo Bonzini 
---
 qemu-timer.c | 20 
 1 file changed, 16 insertions(+), 4 deletions(-)

diff --git a/qemu-timer.c b/qemu-timer.c
index 9299cdc..ff620ec 100644
--- a/qemu-timer.c
+++ b/qemu-timer.c
@@ -174,7 +174,7 @@ void qemu_clock_enable(QEMUClockType type, bool enabled)
 
 bool timerlist_has_timers(QEMUTimerList *timer_list)
 {
-return !!timer_list->active_timers;
+return !!atomic_read(&timer_list->active_timers);
 }
 
 bool qemu_clock_has_timers(QEMUClockType type)
@@ -187,6 +187,10 @@ bool timerlist_expired(QEMUTimerList *timer_list)
 {
 int64_t expire_time;
 
+if (!atomic_read(&timer_list->active_timers)) {
+return false;
+}
+
 qemu_mutex_lock(&timer_list->active_timers_lock);
 if (!timer_list->active_timers) {
 qemu_mutex_unlock(&timer_list->active_timers_lock);
@@ -214,6 +218,10 @@ int64_t timerlist_deadline_ns(QEMUTimerList *timer_list)
 int64_t delta;
 int64_t expire_time;
 
+if (!atomic_read(&timer_list->active_timers)) {
+return -1;
+}
+
 if (!timer_list->clock->enabled) {
 return -1;
 }
@@ -363,7 +371,7 @@ static void timer_del_locked(QEMUTimerList *timer_list, 
QEMUTimer *ts)
 if (!t)
 break;
 if (t == ts) {
-*pt = t->next;
+atomic_set(pt, t->next);
 break;
 }
 pt = &t->next;
@@ -386,7 +394,7 @@ static bool timer_mod_ns_locked(QEMUTimerList *timer_list,
 }
 ts->expire_time = MAX(expire_time, 0);
 ts->next = *pt;
-*pt = ts;
+atomic_set(pt, ts);
 
 return pt == &timer_list->active_timers;
 }
@@ -481,8 +489,12 @@ bool timerlist_run_timers(QEMUTimerList *timer_list)
 QEMUTimerCB *cb;
 void *opaque;
 
+if (!atomic_read(&timer_list->active_timers)) {
+return false;
+}
+
 qemu_event_reset(&timer_list->timers_done_ev);
-if (!timer_list->clock->enabled || !timer_list->active_timers) {
+if (!timer_list->clock->enabled) {
 goto out;
 }
 
-- 
2.9.3

Re: [Qemu-devel] QEMU 2.8 release approaching

[Hailiang Zhang]

Cc: Juan Quintela 
Cc: Amit Shah 

Hi Stefan,

I have one, but I'm not quite sure．Anyway, we caught this bug in our test.

[PATCH] migration: re-active images when migration fails to complete

Thanks,
hailiang

On 2016/11/30 23:42, Stefan Hajnoczi wrote:

Dear QEMU community,
QEMU 2.8.0-rc3 will be tagged on December 6th.  If there are no
pending issues -rc3 will become the QEMU 2.8 final release on December
13th.  Let's make this tag a good one!

If you are currently looking into pending issues or have bug fixes
needing attention from maintainers, please reply to this email.

At this stage only critical bugs, regressions, and build breakage
should hold up the release.

Thanks,
Stefan

Re: [Qemu-devel] [kvm-unit-tests PATCH v13 3/4] arm: pmu: Check cycle count increases

[Andrew Jones]

On Wed, Nov 30, 2016 at 11:16:41PM -0600, Wei Huang wrote:
> From: Christopher Covington 
> 
> Ensure that reads of the PMCCNTR_EL0 are monotonically increasing,
> even for the smallest delta of two subsequent reads.
> 
> Signed-off-by: Christopher Covington 
> Signed-off-by: Wei Huang 
> Reviewed-by: Andrew Jones 
> ---
>  arm/pmu.c | 94 
> +++
>  1 file changed, 94 insertions(+)
> 
> diff --git a/arm/pmu.c b/arm/pmu.c
> index 1fe2b1a..3566a27 100644
> --- a/arm/pmu.c
> +++ b/arm/pmu.c
> @@ -16,6 +16,9 @@
>  #include "asm/barrier.h"
>  #include "asm/processor.h"
>  
> +#define PMU_PMCR_E (1 << 0)
> +#define PMU_PMCR_C (1 << 2)
> +#define PMU_PMCR_LC(1 << 6)
>  #define PMU_PMCR_N_SHIFT   11
>  #define PMU_PMCR_N_MASK0x1f
>  #define PMU_PMCR_ID_SHIFT  16
> @@ -23,10 +26,57 @@
>  #define PMU_PMCR_IMP_SHIFT 24
>  #define PMU_PMCR_IMP_MASK  0xff
>  
> +#define ID_DFR0_PERFMON_SHIFT 24
> +#define ID_DFR0_PERFMON_MASK  0xf
> +
> +#define PMU_CYCLE_IDX 31
> +
> +#define NR_SAMPLES 10
> +
> +static unsigned int pmu_version;
>  #if defined(__arm__)
>  DEFINE_GET_SYSREG32(pmcr, 0, c9, c12, 0)
> +DEFINE_SET_SYSREG32(pmcr, 0, c9, c12, 0)
> +DEFINE_GET_SYSREG32(id_dfr0, 0, c0, c1, 2)
> +DEFINE_SET_SYSREG32(pmselr, 0, c9, c12, 5)
> +DEFINE_SET_SYSREG32(pmxevtyper, 0, c9, c13, 1)
> +DEFINE_GET_SYSREG32(pmccntr32, 0, c9, c13, 0)
> +DEFINE_SET_SYSREG32(pmccntr32, 0, c9, c13, 0)
> +DEFINE_GET_SYSREG64(pmccntr64, 0, c9)
> +DEFINE_SET_SYSREG64(pmccntr64, 0, c9)
> +DEFINE_SET_SYSREG32(pmcntenset, 0, c9, c12, 1)

Seeing how we get lots of redundant looking lines, I think instead
of defining DEFINE_SET/GET_SYSREG32/64, we should instead have

DEFINE_SYSREG32/64  ... creates both get_ and set_
DEFINE_SYSREG32/64_RO   ... creates just get_

> +
> +static inline uint64_t get_pmccntr(void)
> +{
> + if (pmu_version == 0x3)
> + return get_pmccntr64();
> + else
> + return get_pmccntr32();
> +}
> +
> +static inline void set_pmccntr(uint64_t value)
> +{
> + if (pmu_version == 0x3)
> + set_pmccntr64(value);
> + else
> + set_pmccntr32(value & 0x);
> +}

So the two accessors above are exceptional, which is why we don't
use SYSREG for them. These can have uint64_t for there external
interface. We can't require 'unsigned long' or 'unsigned long long'

> +
> +/* PMCCFILTR is an obsolete name for PMXEVTYPER31 in ARMv7 */
> +static inline void set_pmccfiltr(uint32_t value)
> +{
> + set_pmselr(PMU_CYCLE_IDX);
> + set_pmxevtyper(value);
> + isb();
> +}
>  #elif defined(__aarch64__)
>  DEFINE_GET_SYSREG32(pmcr, el0)
> +DEFINE_SET_SYSREG32(pmcr, el0)
> +DEFINE_GET_SYSREG32(id_dfr0, el1)
> +DEFINE_GET_SYSREG64(pmccntr, el0);
> +DEFINE_SET_SYSREG64(pmccntr, el0);
> +DEFINE_SET_SYSREG32(pmcntenset, el0);
> +DEFINE_SET_SYSREG32(pmccfiltr, el0);
>  #endif
>  
>  /*
> @@ -52,11 +102,55 @@ static bool check_pmcr(void)
>   return ((pmcr >> PMU_PMCR_IMP_SHIFT) & PMU_PMCR_IMP_MASK) != 0;
>  }
>  
> +/*
> + * Ensure that the cycle counter progresses between back-to-back reads.
> + */
> +static bool check_cycles_increase(void)
> +{
> + bool success = true;
> +
> + /* init before event access, this test only cares about cycle count */
> + set_pmcntenset(1 << PMU_CYCLE_IDX);
> + set_pmccfiltr(0); /* count cycles in EL0, EL1, but not EL2 */
> + set_pmccntr(0);
> +
> + set_pmcr(get_pmcr() | PMU_PMCR_LC | PMU_PMCR_C | PMU_PMCR_E);
> +
> + for (int i = 0; i < NR_SAMPLES; i++) {
> + uint64_t a, b;
> +
> + a = get_pmccntr();
> + b = get_pmccntr();
> +
> + if (a >= b) {
> + printf("Read %"PRId64" then %"PRId64".\n", a, b);
> + success = false;
> + break;
> + }
> + }
> +
> + set_pmcr(get_pmcr() & ~PMU_PMCR_E);
> +
> + return success;
> +}
> +
> +void pmu_init(void)
> +{
> + uint32_t dfr0;
> +
> + /* probe pmu version */
> + dfr0 = get_id_dfr0();
> + pmu_version = (dfr0 >> ID_DFR0_PERFMON_SHIFT) & ID_DFR0_PERFMON_MASK;
> + report_info("PMU version: %d", pmu_version);
> +}
> +
>  int main(void)
>  {
>   report_prefix_push("pmu");
>  
> + pmu_init();
>   report("Control register", check_pmcr());
> + report("Monotonically increasing cycle count", check_cycles_increase());
>  
>   return report_summary();
>  }
> -- 
> 1.8.3.1
> 
>

drew 

Re: [Qemu-devel] [PATCH v5 00/19] Cleanup of TCG tests

[Peter Maydell]

On 1 December 2016 at 05:14, Pranith Kumar  wrote:
> Hello,
>
> This patch series cleans up the tcg tests in tests/tcg folder.

>  linux-user/mmap.c   |  27 +++---
>  linux-user/syscall.c|   2 +-

These aren't test code -- it would probably be better not
to mix actual bug fixes up in a series that's mostly trying
to fix up test code.

I'd still like to see what the plan is for having this
actually work given that you don't know whether there's a
cross-toolchain available. That's the fundamental reason
why these tests have been left to bitrot.

thanks
-- PMM

Re: [Qemu-devel] [PATCH] monitor: fix object_del for command-line-created objects

[Daniel P. Berrange]

On Wed, Nov 30, 2016 at 05:06:16PM -0600, Michael Roth wrote:
> Currently objects specified on the command-line are only partially
> cleaned up when 'object_del' is issued in either HMP or QMP: the
> object itself is fully finalized, but the QemuOpts are not removed.
> This results in the following behavior:
> 
>   x86_64-softmmu/qemu-system-x86_64 -monitor stdio \
> -object memory-backend-ram,id=ram1,size=256M
> 
>   QEMU 2.7.91 monitor - type 'help' for more information
>   (qemu) object_del ram1
>   (qemu) object_del ram1
>   object 'ram1' not found
>   (qemu) object_add memory-backend-ram,id=ram1,size=256M
>   Duplicate ID 'ram1' for object
>   Try "help object_add" for more information
> 
> which can be an issue for use-cases like memory hotplug.
> 
> This happens on the HMP side because hmp_object_add() attempts to
> create a temporary QemuOpts entry with ID 'ram1', which ends up
> conflicting with the command-line-created entry, since it was never
> cleaned up during the previous hmp_object_del() call.
> 
> We address this by adding checks in {qmp,hmp}_object_del to determine
> whether an option group entry matching the object's ID is present,
> and removing it if it is.
> 
> Note that qmp_object_add() never attempts to create a temporary
> QemuOpts entry, so it does not encounter the duplicate ID error,
> which is why this isn't generally visible in libvirt.
> 
> Cc: "Dr. David Alan Gilbert" 
> Cc: Markus Armbruster 
> Cc: Eric Blake 
> Cc: Daniel Berrange 
> Signed-off-by: Michael Roth 
> ---
>  hmp.c | 10 ++
>  qmp.c | 10 ++
>  2 files changed, 20 insertions(+)
> 
> diff --git a/hmp.c b/hmp.c
> index b869617..99b8bf3 100644
> --- a/hmp.c
> +++ b/hmp.c
> @@ -2072,6 +2072,16 @@ void hmp_object_del(Monitor *mon, const QDict *qdict)
>  
>  user_creatable_del(id, &err);
>  hmp_handle_error(mon, &err);
> +
> +/* if object was defined on the command-line, remove its corresponding
> + * option group entry
> + */
> +if (err == NULL) {
> +QemuOptsList *opt_group = qemu_find_opts_err("object", &err);
> +if (opt_group) {
> +qemu_opts_del(qemu_opts_find(opt_group, id));
> +}
> +}
>  }
>  
>  void hmp_info_memdev(Monitor *mon, const QDict *qdict)
> diff --git a/qmp.c b/qmp.c
> index 0028f0b..87c545d 100644
> --- a/qmp.c
> +++ b/qmp.c
> @@ -686,6 +686,16 @@ void qmp_object_add(const char *type, const char *id,
>  void qmp_object_del(const char *id, Error **errp)
>  {
>  user_creatable_del(id, errp);
> +
> +/* if object was defined on the command-line, remove its corresponding
> + * option group entry
> + */
> +if (!(errp && *errp)) {
> +QemuOptsList *opt_group = qemu_find_opts_err("object", errp);
> +if (opt_group) {
> +qemu_opts_del(qemu_opts_find(opt_group, id));
> +}
> +}
>  }

I rather feel like this code ought to be in user_creatable_del(), since
all code paths which call user_creatable_del() need to do deal with
this scenario.

Also I'd like to see a unit test added that exposes this problem and
demonstrates the fix - could att it to tests/check-qom-proplist.c

Regards,
Daniel
-- 
|: http://berrange.com  -o-http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org  -o- http://virt-manager.org :|
|: http://entangle-photo.org   -o-http://search.cpan.org/~danberr/ :|

Re: [Qemu-devel] [kvm-unit-tests PATCH v13 4/4] arm: pmu: Add CPI checking

[Andrew Jones]

On Wed, Nov 30, 2016 at 11:16:42PM -0600, Wei Huang wrote:
> From: Christopher Covington 
> 
> Calculate the numbers of cycles per instruction (CPI) implied by ARM
> PMU cycle counter values. The code includes a strict checking facility
> intended for the -icount option in TCG mode in the configuration file.
> 
> Signed-off-by: Christopher Covington 
> Signed-off-by: Wei Huang 
> Reviewed-by: Andrew Jones 
> ---
>  arm/pmu.c | 123 
> +-
>  arm/unittests.cfg |  14 +++
>  2 files changed, 136 insertions(+), 1 deletion(-)
> 
> diff --git a/arm/pmu.c b/arm/pmu.c
> index 3566a27..29d7c2c 100644
> --- a/arm/pmu.c
> +++ b/arm/pmu.c
> @@ -69,6 +69,27 @@ static inline void set_pmccfiltr(uint32_t value)
>   set_pmxevtyper(value);
>   isb();
>  }
> +
> +/*
> + * Extra instructions inserted by the compiler would be difficult to 
> compensate
> + * for, so hand assemble everything between, and including, the PMCR accesses
> + * to start and stop counting. isb instructions were inserted to make sure
> + * pmccntr read after this function returns the exact instructions executed 
> in
> + * the controlled block. Total instrs = isb + mcr + 2*loop = 2 + 2*loop.
> + */
> +static inline void precise_instrs_loop(int loop, uint32_t pmcr)
> +{
> + asm volatile(
> + "   mcr p15, 0, %[pmcr], c9, c12, 0\n"
> + "   isb\n"
> + "1: subs%[loop], %[loop], #1\n"
> + "   bgt 1b\n"
> + "   mcr p15, 0, %[z], c9, c12, 0\n"
> + "   isb\n"
> + : [loop] "+r" (loop)
> + : [pmcr] "r" (pmcr), [z] "r" (0)
> + : "cc");
> +}
>  #elif defined(__aarch64__)
>  DEFINE_GET_SYSREG32(pmcr, el0)
>  DEFINE_SET_SYSREG32(pmcr, el0)
> @@ -77,6 +98,27 @@ DEFINE_GET_SYSREG64(pmccntr, el0);
>  DEFINE_SET_SYSREG64(pmccntr, el0);
>  DEFINE_SET_SYSREG32(pmcntenset, el0);
>  DEFINE_SET_SYSREG32(pmccfiltr, el0);
> +
> +/*
> + * Extra instructions inserted by the compiler would be difficult to 
> compensate
> + * for, so hand assemble everything between, and including, the PMCR accesses
> + * to start and stop counting. isb instructions are inserted to make sure
> + * pmccntr read after this function returns the exact instructions executed
> + * in the controlled block. Total instrs = isb + msr + 2*loop = 2 + 2*loop.
> + */
> +static inline void precise_instrs_loop(int loop, uint32_t pmcr)
> +{
> + asm volatile(
> + "   msr pmcr_el0, %[pmcr]\n"
> + "   isb\n"
> + "1: subs%[loop], %[loop], #1\n"
> + "   b.gt1b\n"
> + "   msr pmcr_el0, xzr\n"
> + "   isb\n"
> + : [loop] "+r" (loop)
> + : [pmcr] "r" (pmcr)
> + : "cc");
> +}
>  #endif
>  
>  /*
> @@ -134,6 +176,79 @@ static bool check_cycles_increase(void)
>   return success;
>  }
>  
> +/*
> + * Execute a known number of guest instructions. Only even instruction counts
> + * greater than or equal to 4 are supported by the in-line assembly code. The
> + * control register (PMCR_EL0) is initialized with the provided value 
> (allowing
> + * for example for the cycle counter or event counters to be reset). At the 
> end
> + * of the exact instruction loop, zero is written to PMCR_EL0 to disable
> + * counting, allowing the cycle counter or event counters to be read at the
> + * leisure of the calling code.
> + */
> +static void measure_instrs(int num, uint32_t pmcr)
> +{
> + int loop = (num - 2) / 2;
> +
> + assert(num >= 4 && ((num - 2) % 2 == 0));
> + precise_instrs_loop(loop, pmcr);
> +}
> +
> +/*
> + * Measure cycle counts for various known instruction counts. Ensure that the
> + * cycle counter progresses (similar to check_cycles_increase() but with more
> + * instructions and using reset and stop controls). If supplied a positive,
> + * nonzero CPI parameter, also strictly check that every measurement matches
> + * it. Strict CPI checking is used to test -icount mode.
> + */
> +static bool check_cpi(int cpi)
> +{
> + uint32_t pmcr = get_pmcr() | PMU_PMCR_LC | PMU_PMCR_C | PMU_PMCR_E;
> +
> + /* init before event access, this test only cares about cycle count */
> + set_pmcntenset(1 << PMU_CYCLE_IDX);
> + set_pmccfiltr(0); /* count cycles in EL0, EL1, but not EL2 */
> +
> + if (cpi > 0)
> + printf("Checking for CPI=%d.\n", cpi);
> + printf("instrs : cycles0 cycles1 ...\n");
> +
> + for (unsigned int i = 4; i < 300; i += 32) {
> + uint64_t avg, sum = 0;
> +
> + printf("%d :", i);
> + for (int j = 0; j < NR_SAMPLES; j++) {
> + uint64_t cycles;
> +
> + set_pmccntr(0);
> + measure_instrs(i, pmcr);
> + cycles = get_pmccntr();
> + printf(" %"PRId64"", cycles);
> +
> + if (!cycles) {
> + printf("\ncycles not incrementing!\n");
> + return 

[Qemu-devel] [PATCH] ui: use evdev keymap when running under wayland

[Daniel P. Berrange]

Wayland always uses evdev as its input source, so QEMU
can use the existing evdev keymap data

Signed-off-by: Daniel P. Berrange 
---
 ui/gtk.c | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/ui/gtk.c b/ui/gtk.c
index e816428..81dba57 100644
--- a/ui/gtk.c
+++ b/ui/gtk.c
@@ -90,6 +90,9 @@
 #ifndef GDK_IS_X11_DISPLAY
 #define GDK_IS_X11_DISPLAY(dpy) (dpy == dpy)
 #endif
+#ifndef GDK_IS_WAYLAND_DISPLAY
+#define GDK_IS_WAYLAND_DISPLAY(dpy) (dpy == dpy)
+#endif
 #ifndef GDK_IS_WIN32_DISPLAY
 #define GDK_IS_WIN32_DISPLAY(dpy) (dpy == dpy)
 #endif
@@ -1054,6 +1057,10 @@ static int gd_map_keycode(GtkDisplayState *s, GdkDisplay 
*dpy, int gdk_keycode)
 qemu_keycode = translate_xfree86_keycode(gdk_keycode - 97);
 }
 #endif
+#ifdef GDK_WINDOWING_WAYLAND
+} else if (GDK_IS_WAYLAND_DISPLAY(dpy) && gdk_keycode < 158) {
+qemu_keycode = translate_evdev_keycode(gdk_keycode - 97);
+#endif
 } else if (gdk_keycode == 208) { /* Hiragana_Katakana */
 qemu_keycode = 0x70;
 } else if (gdk_keycode == 211) { /* backslash */
-- 
2.9.3

Re: [Qemu-devel] GTK UI keycodes broken under Wayland

[Daniel P. Berrange]

On Thu, Dec 01, 2016 at 09:32:34AM +0100, Thomas Huth wrote:
> On 01.12.2016 08:24, Stefan Hajnoczi wrote:
> > I recently upgraded to Fedora 25 which runs Wayland by default.
> > 
> > The GTK UI is now sending unknown keycodes to the guests.  Although
> > alphanumeric keys work, the cursor keys are broken.
> > 
> > There is X11-specific code for keycode mapping in ui/gtk.c.  Perhaps
> > something is needed to make that work under Wayland?
> 
> There is certainly something missing for Wayland. Somebody already
> reported this issue here and posted a "quick and dirty" patch:
> 
> https://bugs.launchpad.net/qemu/+bug/1578192

That patch doesn't seem to apply for me and does more than is
needed. I've just sent a simpler patch that ought to fix it,
though I've not personally tested it, so would appreciate
feedback from Stefan that his test VM keyboard works now.

Regards,
Daniel
-- 
|: http://berrange.com  -o-http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org  -o- http://virt-manager.org :|
|: http://entangle-photo.org   -o-http://search.cpan.org/~danberr/ :|

Re: [Qemu-devel] [kvm-unit-tests PATCH v13 1/4] arm: Define macros for accessing system registers

[Andrew Jones]

On Thu, Dec 01, 2016 at 09:59:03AM +0100, Andrew Jones wrote:
> 
> Should this be From: Andre?
> 
> On Wed, Nov 30, 2016 at 11:16:39PM -0600, Wei Huang wrote:
> > This patch defines four macros to assist creating system register
> > accessors under both ARMv7 and AArch64:
> >* DEFINE_GET_SYSREG32(name, ...)
> >* DEFINE_SET_SYSREG32(name, ...)
> >* DEFINE_GET_SYSREG64(name, ...)
> >* DEFINE_SET_SYSREG64(name, ...)
> > These macros are translated to inline functions with consistent naming,
> > get_##name() and set_##name(), which can be used by C code directly.
> > 
> > Signed-off-by: Andre Przywara 
> > Signed-off-by: Wei Huang 
> > ---
> >  lib/arm/asm/processor.h   | 37 -
> >  lib/arm64/asm/processor.h | 35 ---
> >  2 files changed, 60 insertions(+), 12 deletions(-)
> > 
> > diff --git a/lib/arm/asm/processor.h b/lib/arm/asm/processor.h
> > index f25e7ee..3ca6b42 100644
> > --- a/lib/arm/asm/processor.h
> > +++ b/lib/arm/asm/processor.h
> > @@ -33,13 +33,40 @@ static inline unsigned long current_cpsr(void)
> >  
> >  #define current_mode() (current_cpsr() & MODE_MASK)
> >  
> > -static inline unsigned int get_mpidr(void)
> > -{
> > -   unsigned int mpidr;
> > -   asm volatile("mrc p15, 0, %0, c0, c0, 5" : "=r" (mpidr));
> > -   return mpidr;
> > +#define DEFINE_GET_SYSREG32(name, opc1, crn, crm, opc2)
> > \
> > +static inline uint32_t get_##name(void)
> > \
> > +{  \
> > +   uint32_t reg;   \
> > +   asm volatile("mrc p15, " #opc1 ", %0, " #crn ", " #crm ", " \
> > +#opc2 : "=r" (reg));   \
> > +   return reg; \
> > +}
> > +
> > +#define DEFINE_SET_SYSREG32(name, opc1, crn, crm, opc2)
> > \
> > +static inline void set_##name(uint32_t value)  
> > \
> > +{  \
> > +   asm volatile("mcr p15, " #opc1 ", %0, " #crn ", " #crm ", " \
> > +#opc2 :: "r" (value)); \
>^ nit: no space here, checkpatch would complain
> > +}
> > +
> > +#define DEFINE_GET_SYSREG64(name, opc, crm)
> > \
> > +static inline uint64_t get_##name(void)
> > \
> > +{  \
> > +   uint32_t lo, hi;\
> > +   asm volatile("mrrc p15, " #opc ", %0, %1, " #crm\
> > +: "=r" (lo), "=r" (hi));   \
> > +   return (uint64_t)hi << 32 | lo; \
> > +}
> > +
> > +#define DEFINE_SET_SYSREG64(name, opc, crm)
> > \
> > +static inline void set_##name(uint64_t value)  
> > \
> > +{  \
> > +   asm volatile("mcrr p15, " #opc ", %0, %1, " #crm\
> > +:: "r" (value & 0x), "r" (value >> 32));   \
> >  }
> >  
> > +DEFINE_GET_SYSREG32(mpidr, 0, c0, c0, 5)
> > +
> >  /* Only support Aff0 for now, up to 4 cpus */
> >  #define mpidr_to_cpu(mpidr) ((int)((mpidr) & 0xff))
> >  
> > diff --git a/lib/arm64/asm/processor.h b/lib/arm64/asm/processor.h
> > index 84d5c7c..dfa75eb 100644
> > --- a/lib/arm64/asm/processor.h
> > +++ b/lib/arm64/asm/processor.h
> > @@ -66,14 +66,35 @@ static inline unsigned long current_level(void)
> > return el & 0xc;
> >  }
> >  
> > -#define DEFINE_GET_SYSREG32(reg)   \
> > -static inline unsigned int get_##reg(void) \
> > -{  \
> > -   unsigned int reg;   \
> > -   asm volatile("mrs %0, " #reg "_el1" : "=r" (reg));  \
> > -   return reg; \
> > +#define DEFINE_GET_SYSREG32(reg, el)   
> > \
> > +static inline uint32_t get_##reg(void) 
> > \
> > +{  \
> > +   uint32_t reg;   \
> > +   asm volatile("mrs %0, " #reg "_" #el : "=r" (reg)); \
> > +   return reg; \
> >  }
> > -DEFINE_GET_SYSREG32(mpidr)
> > +
> > +#define DEFINE_SET_SYSREG32(reg, el)   
> > \
> > +static inline void set_##reg(uint32_t value)   
> > \
> > +{  \
> > +   asm volatile("msr " #re

[Qemu-devel] [PATCH v2] ui: use evdev keymap when running under wayland

[Daniel P. Berrange]

Wayland always uses evdev as its input source, so QEMU
can use the existing evdev keymap data

Signed-off-by: Daniel P. Berrange 
---

Changed in v2

 - Actually add all changed files to commit - gtk.h :-)

 include/ui/gtk.h | 4 
 ui/gtk.c | 7 +++
 2 files changed, 11 insertions(+)

diff --git a/include/ui/gtk.h b/include/ui/gtk.h
index 42ca0fe..b3b5005 100644
--- a/include/ui/gtk.h
+++ b/include/ui/gtk.h
@@ -18,6 +18,10 @@
 #include 
 #endif
 
+#ifdef GDK_WINDOWING_WAYLAND
+#include 
+#endif
+
 #if defined(CONFIG_OPENGL)
 #include "ui/egl-helpers.h"
 #include "ui/egl-context.h"
diff --git a/ui/gtk.c b/ui/gtk.c
index e816428..81dba57 100644
--- a/ui/gtk.c
+++ b/ui/gtk.c
@@ -90,6 +90,9 @@
 #ifndef GDK_IS_X11_DISPLAY
 #define GDK_IS_X11_DISPLAY(dpy) (dpy == dpy)
 #endif
+#ifndef GDK_IS_WAYLAND_DISPLAY
+#define GDK_IS_WAYLAND_DISPLAY(dpy) (dpy == dpy)
+#endif
 #ifndef GDK_IS_WIN32_DISPLAY
 #define GDK_IS_WIN32_DISPLAY(dpy) (dpy == dpy)
 #endif
@@ -1054,6 +1057,10 @@ static int gd_map_keycode(GtkDisplayState *s, GdkDisplay 
*dpy, int gdk_keycode)
 qemu_keycode = translate_xfree86_keycode(gdk_keycode - 97);
 }
 #endif
+#ifdef GDK_WINDOWING_WAYLAND
+} else if (GDK_IS_WAYLAND_DISPLAY(dpy) && gdk_keycode < 158) {
+qemu_keycode = translate_evdev_keycode(gdk_keycode - 97);
+#endif
 } else if (gdk_keycode == 208) { /* Hiragana_Katakana */
 qemu_keycode = 0x70;
 } else if (gdk_keycode == 211) { /* backslash */
-- 
2.9.3

Re: [Qemu-devel] QEMU 1.1.2: block IO throttle might occasionally freeze running process's IO to zero

[Fam Zheng]

On Thu, 12/01 12:07, Bob Chen wrote:
> Test case:
> 
> 1. QEMU 1.1.2
> 2. Run fio inside the vm, give it some pressure. Watch the realtime
> throughput
> 3. block_set_io_throttle drive_2 1 0 0 2000 0 0 # throttle
> bps and iops, any value
> 4. Observed that the IO is very likely to freeze to zero. The fio process
> stuck!
> 5. Kill the former fio process, start a new one. The IO turns back to normal
> 
> Didn't reproduce it with QEMU 2.5.
> 
> 
> Actually I'm not wishfully thinking the community would help fix this bug
> on such an ancient version. Just hope someone can tell me what is the root
> cause. Then I have to evaluate whether I should move to higher version
> QEMU, or fix this bug on 1.1.2 in-place(if it is a small one).

The throttling implementation is completely refreshed so I think it's not easy
to suggest a root cause for you.

Fam

Re: [Qemu-devel] [PATCH v6 4/4] hw/intc/arm_gicv3_kvm: Reset GICv3 cpu interface registers

[Vijay Kilari]

On Wed, Nov 30, 2016 at 10:29 PM, Peter Maydell
 wrote:
> On 30 November 2016 at 16:23, Vijay Kilari  wrote:
>> On Mon, Nov 28, 2016 at 10:05 PM, Peter Maydell
>>  wrote:
>>> Still I would prefer it if we did this with the same
>>> mechanism for both TCG and KVM. A generic mechanism for
>>> "let the CPU reset trigger reset of many other devices in the
>>> system" isn't widely useful because real hardware doesn't
>>> have that kind of action-at-a-distance behaviour.
>>
>> To make direct call from arm_cpu_reset() to reset CPUIF,
>> I could not find a way to get GICv3CPUState from CPUARMState or
>> ARMCPU struct.
>
> You don't want to directly call from arm_cpu_reset().
> Coprocessor regs registered via cpregs can have
> reset functions, which get called automatically.
> This is what the TCG gicv3 code already does to reset
> the CPU i/f, the relevant code just needs to be
> arranged so it's used for KVM too.

Yes, the reset functions of cpregs get CPUARMState as parameter
and still we cannot fetch GICv3CPUState from it.

The TCG code in arm_gicv3_cpuif.c is rely on el_hook to get
GICv3CPUState.
>
>> Any idea how to get GICv3CPUState?
>>
>> In  hw/intc/arm_gicv3_cpuif.c implementation,
>> el_hook function is registered to fetch GICv3CPUState
>> from CPUARMState struct, but it is for TCG
>
> Yes, you don't need the el hook.

Without this is there a way to get GICv3CPUState for KVM?
I am not familiar with this code.

>
> thanks
> -- PMM

Re: [Qemu-devel] [Nbd] [PATCH v3] doc: Add NBD_CMD_BLOCK_STATUS extension

[Wouter Verhelst]

Here's another update.

Changes since previous version:
- Rename "allocation context" to "metadata context"
- Stop making metadata context 0 be special; instead, name it
  "BASE:allocation" and allow it to be selected like all other contexts.
- Clarify in a bit more detail when a server MAY omit metadata
  information on a particular metadata context (i.e., only if another
  metadata context that we actually got information for implies it can't
  have meaning). This was always meant that way, but the spec could have
  been a bit more explicit about it.
- Change one SHOULD to a MUST, where it should not have been a SHOULD
  in the first place.

(This applies on top of my previous patch)

Applied and visible at the usual place.

diff --git a/doc/proto.md b/doc/proto.md
index fe7ae53..9c0981f 100644
--- a/doc/proto.md
+++ b/doc/proto.md
@@ -869,16 +869,16 @@ of the newstyle negotiation.
 
 Defined by the experimental `INFO` 
[extension](https://github.com/NetworkBlockDevice/nbd/blob/extension-info/doc/proto.md).
 
-- `NBD_OPT_ALLOC_CONTEXT` (10)
+- `NBD_OPT_META_CONTEXT` (10)
 
-Return a list of `NBD_REP_ALLOC_CONTEXT` replies, one per context,
+Return a list of `NBD_REP_META_CONTEXT` replies, one per context,
 followed by an `NBD_REP_ACK`. If a server replies to such a request
 with no error message, clients MAY send NBD_CMD_BLOCK_STATUS
 commands during the transmission phase.
 
 If the query string is syntactically invalid, the server SHOULD send
 `NBD_REP_ERR_INVALID`. If the query string is syntactically valid
-but finds no allocation contexts, the server MUST send a single
+but finds no metadata contexts, the server MUST send a single
 reply of type `NBD_REP_ACK`.
 
 This option MUST NOT be requested unless structured replies have
@@ -887,9 +887,9 @@ of the newstyle negotiation.
 
 Data:
 - 32 bits, type
-- String, query to select a subset of the available allocation
+- String, query to select a subset of the available metadata
   contexts. If this is not specified (i.e., length is 4 and no
-  command is sent), then the server MUST send all the allocation
+  command is sent), then the server MUST send all the metadata
   contexts it knows about. If specified, this query string MUST
   start with a name that uniquely identifies a server
   implementation; e.g., the reference implementation that
@@ -897,18 +897,22 @@ of the newstyle negotiation.
   with 'nbd-server:'
 
 The type may be one of:
-- `NBD_ALLOC_LIST_CONTEXT` (1): the list of allocation contexts
+- `NBD_META_LIST_CONTEXT` (1): the list of metadata contexts
   selected by the query string is returned to the client without
-  changing any state (i.e., this does not add allocation contexts
+  changing any state (i.e., this does not add metadata contexts
   for further usage).
-- `NBD_ALLOC_ADD_CONTEXT` (2): the list of allocation contexts
+- `NBD_META_ADD_CONTEXT` (2): the list of metadata contexts
   selected by the query string is added to the list of existing
-  allocation contexts.
-- `NBD_ALLOC_DEL_CONTEXT` (3): the list of allocation contexts
+  metadata contexts.
+- `NBD_META_DEL_CONTEXT` (3): the list of metadata contexts
   selected by the query string is removed from the list of used
-  allocation contexts. Servers SHOULD NOT reuse existing allocation
+  metadata contexts. Servers SHOULD NOT reuse existing metadata
   context IDs.
 
+The syntax of the query string is not specified, except that
+implementations MUST support adding and removing individual metadata
+contexts by simply listing their names.
+
  Option reply types
 
 These values are used in the "reply type" field, sent by the server
@@ -920,7 +924,7 @@ during option haggling in the fixed newstyle negotiation.
 information is available, or when sending data related to the option
 (in the case of `NBD_OPT_LIST`) has finished. No data.
 
-* `NBD_REP_SERVER` (2)
+- `NBD_REP_SERVER` (2)
 
 A description of an export. Data:
 
@@ -935,21 +939,20 @@ during option haggling in the fixed newstyle negotiation.
   particular client request, this field is defined to be a string
   suitable for direct display to a human being.
 
-* `NBD_REP_INFO` (3)
+- `NBD_REP_INFO` (3)
 
 Defined by the experimental `INFO` 
[extension](https://github.com/NetworkBlockDevice/nbd/blob/extension-info/doc/proto.md).
 
-- `NBD_REP_ALLOC_CONTEXT` (4)
+- `NBD_REP_META_CONTEXT` (4)
 
-A description of an allocation context. Data:
+A description of a metadata context. Data:
 
-- 32 bits, NBD allocation context ID. If the request was NOT of type
-  `NBD_ALLOC_LIST_CONTEXT`, this field MUST NOT be zero.
-- String, name of the allocation context. This is not required to be
+- 32 bits, NBD metadata context ID.
+- String, name of the metadata context. This is not required to be
   a hum

Re: [Qemu-devel] QEMU 1.1.2: block IO throttle might occasionally freeze running process's IO to zero

[Paolo Bonzini]

On 01/12/2016 05:07, Bob Chen wrote:
> Test case:
> 
> 1. QEMU 1.1.2
> 2. Run fio inside the vm, give it some pressure. Watch the realtime
> throughput
> 3. block_set_io_throttle drive_2 1 0 0 2000 0 0 #
> throttle bps and iops, any value
> 4. Observed that the IO is very likely to freeze to zero. The fio
> process stuck!
> 5. Kill the former fio process, start a new one. The IO turns back to normal
> 
> Didn't reproduce it with QEMU 2.5.
> 
> 
> Actually I'm not wishfully thinking the community would help fix this
> bug on such an ancient version. Just hope someone can tell me what is
> the root cause. Then I have to evaluate whether I should move to higher
> version QEMU, or fix this bug on 1.1.2 in-place(if it is a small one).

Hi,

throttling has been rewritten in QEMU 2.0 (see the commits around
5ddfffb, "throttle: Add a new throttling API implementing continuous
leaky bucket.", 2013-09-06), so the root cause is simply that the old
algorithms were buggy. :)

I think that the new implementation has been backported to QEMU versions
as old as 1.1.2, but if you can move to a newer version it would be simpler.

Paolo

Re: [Qemu-devel] [kvm-unit-tests PATCH v13 4/4] arm: pmu: Add CPI checking

[Andre Przywara]

Hi Drew,

actually unrelated to this actual patch, but since you mentioned it:

> As we work out how best to handle tcg-only tests in order to get Alex
> Bennee's MTTCG tests merged, we'll probably revisit this file,

So when I was experimenting with kvmtool, I realized that some tests
would need to be QEMU only. Also I was tempted to try some tests either
on bare metal machines or in a Fast Model.
So I wonder if we should have some constraints or tags on the tests, so
that a certain backend can filter on this and skip if it's not capable?

Just wanted to mention this so that we can use this refactoring
opportunity to come up with something more generic than just a boolean
TGC vs. KVM.
Maybe we should introduce the notion of a "test backend"? That could be
QEMU/KVM and TCG for now, but later extended to cover kvmtool and
probably other hypervisors like Xen as well.

Cheers,
Andre.

Re: [Qemu-devel] QEMU 2.8 release approaching

[Gonglei (Arei)]

> -Original Message-
> From: Stefan Hajnoczi [mailto:stefa...@gmail.com]
> Sent: Thursday, December 01, 2016 5:04 PM
> To: Laszlo Ersek; Gonglei (Arei)
> Cc: Peter Maydell; qemu-devel
> Subject: Re: QEMU 2.8 release approaching
> 
> On Wed, Nov 30, 2016 at 3:42 PM, Stefan Hajnoczi 
> wrote:
> > If you are currently looking into pending issues or have bug fixes
> > needing attention from maintainers, please reply to this email.
> 
> Laszlo, Gonglei,
> Thanks for pointing out these patches that should be included in QEMU 2.8.
> 
> Patches still need to go through the maintainers identified by
> scripts/get_maintainer.pl.  I'll receive pull requests from them.
> 
> Please let me know if there is no maintainer and I'll merge them myself.
> 

It seems that Andreas isn't in the list recently. :(

CC Andreas.

Regards,
-Gonglei

Re: [Qemu-devel] GTK UI keycodes broken under Wayland

[Stefan Hajnoczi]

On Thu, Dec 1, 2016 at 9:35 AM, Daniel P. Berrange  wrote:
> On Thu, Dec 01, 2016 at 09:32:34AM +0100, Thomas Huth wrote:
>> On 01.12.2016 08:24, Stefan Hajnoczi wrote:
>> > I recently upgraded to Fedora 25 which runs Wayland by default.
>> >
>> > The GTK UI is now sending unknown keycodes to the guests.  Although
>> > alphanumeric keys work, the cursor keys are broken.
>> >
>> > There is X11-specific code for keycode mapping in ui/gtk.c.  Perhaps
>> > something is needed to make that work under Wayland?
>>
>> There is certainly something missing for Wayland. Somebody already
>> reported this issue here and posted a "quick and dirty" patch:
>>
>> https://bugs.launchpad.net/qemu/+bug/1578192
>
> That patch doesn't seem to apply for me and does more than is
> needed. I've just sent a simpler patch that ought to fix it,
> though I've not personally tested it, so would appreciate
> feedback from Stefan that his test VM keyboard works now.

Cool, thank you!  I will test it.

Stefan

[Qemu-devel] [RFC PATCH] glusterfs: allow partial reads

[Wolfgang Bumiller]

Fixes #1644754.

Signed-off-by: Wolfgang Bumiller 
---
I'm not sure what the original rationale was to treat both partial
reads as well as well as writes as I/O error. (Seems to have happened
from original glusterfs v1 to v2 series with a note but no reasoning
for the read side as far as I could see.)
The general direction lately seems to be to move away from sector
based block APIs. Also eg. the NFS code allows partial reads. (It
does, however, have an old patch (c2eb918e3) dedicated to aligning
sizes to 512 byte boundaries for file creation for compatibility to
other parts of qemu like qcow2. This already happens in glusterfs,
though, but if you move a file from a different storage over to
glusterfs you may end up with a qcow2 file with eg. the L1 table in
the last 80 bytes of the file aligned to _begin_ at a 512 boundary,
but not _end_ at one.)

 block/gluster.c | 10 +-
 1 file changed, 9 insertions(+), 1 deletion(-)

diff --git a/block/gluster.c b/block/gluster.c
index 891c13b..3db0bf8 100644
--- a/block/gluster.c
+++ b/block/gluster.c
@@ -41,6 +41,7 @@ typedef struct GlusterAIOCB {
 int ret;
 Coroutine *coroutine;
 AioContext *aio_context;
+bool is_write;
 } GlusterAIOCB;
 
 typedef struct BDRVGlusterState {
@@ -716,8 +717,10 @@ static void gluster_finish_aiocb(struct glfs_fd *fd, 
ssize_t ret, void *arg)
 acb->ret = 0; /* Success */
 } else if (ret < 0) {
 acb->ret = -errno; /* Read/Write failed */
+} else if (acb->is_write) {
+acb->ret = -EIO; /* Partial write - fail it */
 } else {
-acb->ret = -EIO; /* Partial read/write - fail it */
+acb->ret = 0; /* Success */
 }
 
 aio_bh_schedule_oneshot(acb->aio_context, qemu_gluster_complete_aio, acb);
@@ -965,6 +968,7 @@ static coroutine_fn int 
qemu_gluster_co_pwrite_zeroes(BlockDriverState *bs,
 acb.ret = 0;
 acb.coroutine = qemu_coroutine_self();
 acb.aio_context = bdrv_get_aio_context(bs);
+acb.is_write = true;
 
 ret = glfs_zerofill_async(s->fd, offset, size, gluster_finish_aiocb, &acb);
 if (ret < 0) {
@@ -1087,9 +1091,11 @@ static coroutine_fn int 
qemu_gluster_co_rw(BlockDriverState *bs,
 acb.aio_context = bdrv_get_aio_context(bs);
 
 if (write) {
+acb.is_write = true;
 ret = glfs_pwritev_async(s->fd, qiov->iov, qiov->niov, offset, 0,
  gluster_finish_aiocb, &acb);
 } else {
+acb.is_write = false;
 ret = glfs_preadv_async(s->fd, qiov->iov, qiov->niov, offset, 0,
 gluster_finish_aiocb, &acb);
 }
@@ -1153,6 +1159,7 @@ static coroutine_fn int 
qemu_gluster_co_flush_to_disk(BlockDriverState *bs)
 acb.ret = 0;
 acb.coroutine = qemu_coroutine_self();
 acb.aio_context = bdrv_get_aio_context(bs);
+acb.is_write = true;
 
 ret = glfs_fsync_async(s->fd, gluster_finish_aiocb, &acb);
 if (ret < 0) {
@@ -1199,6 +1206,7 @@ static coroutine_fn int 
qemu_gluster_co_pdiscard(BlockDriverState *bs,
 acb.ret = 0;
 acb.coroutine = qemu_coroutine_self();
 acb.aio_context = bdrv_get_aio_context(bs);
+acb.is_write = true;
 
 ret = glfs_discard_async(s->fd, offset, size, gluster_finish_aiocb, &acb);
 if (ret < 0) {
-- 
2.1.4

Re: [Qemu-devel] QEMU 2.8 release approaching

[Stefan Hajnoczi]

On Thu, Dec 1, 2016 at 10:30 AM, Gonglei (Arei)  wrote:
>
>> -Original Message-
>> From: Stefan Hajnoczi [mailto:stefa...@gmail.com]
>> Sent: Thursday, December 01, 2016 5:04 PM
>> To: Laszlo Ersek; Gonglei (Arei)
>> Cc: Peter Maydell; qemu-devel
>> Subject: Re: QEMU 2.8 release approaching
>>
>> On Wed, Nov 30, 2016 at 3:42 PM, Stefan Hajnoczi 
>> wrote:
>> > If you are currently looking into pending issues or have bug fixes
>> > needing attention from maintainers, please reply to this email.
>>
>> Laszlo, Gonglei,
>> Thanks for pointing out these patches that should be included in QEMU 2.8.
>>
>> Patches still need to go through the maintainers identified by
>> scripts/get_maintainer.pl.  I'll receive pull requests from them.
>>
>> Please let me know if there is no maintainer and I'll merge them myself.
>>
>
> It seems that Andreas isn't in the list recently. :(
>
> CC Andreas.

Andreas: please let us know if your availability has changed.  You
could add a QOM co-maintainer if you are busy, for example.

Stefan

Re: [Qemu-devel] [kvm-unit-tests PATCH v13 1/4] arm: Define macros for accessing system registers

[Andre Przywara]

Hi,

On 01/12/16 08:59, Andrew Jones wrote:
> 
> Should this be From: Andre?

No need from my side, this way all the bug reports are send to Wei ;-)

> On Wed, Nov 30, 2016 at 11:16:39PM -0600, Wei Huang wrote:
>> This patch defines four macros to assist creating system register
>> accessors under both ARMv7 and AArch64:
>>* DEFINE_GET_SYSREG32(name, ...)
>>* DEFINE_SET_SYSREG32(name, ...)
>>* DEFINE_GET_SYSREG64(name, ...)
>>* DEFINE_SET_SYSREG64(name, ...)
>> These macros are translated to inline functions with consistent naming,
>> get_##name() and set_##name(), which can be used by C code directly.
>>
>> Signed-off-by: Andre Przywara 
>> Signed-off-by: Wei Huang 
>> ---
>>  lib/arm/asm/processor.h   | 37 -
>>  lib/arm64/asm/processor.h | 35 ---
>>  2 files changed, 60 insertions(+), 12 deletions(-)
>>
>> diff --git a/lib/arm/asm/processor.h b/lib/arm/asm/processor.h
>> index f25e7ee..3ca6b42 100644
>> --- a/lib/arm/asm/processor.h
>> +++ b/lib/arm/asm/processor.h
>> @@ -33,13 +33,40 @@ static inline unsigned long current_cpsr(void)
>>  
>>  #define current_mode() (current_cpsr() & MODE_MASK)
>>  
>> -static inline unsigned int get_mpidr(void)
>> -{
>> -unsigned int mpidr;
>> -asm volatile("mrc p15, 0, %0, c0, c0, 5" : "=r" (mpidr));
>> -return mpidr;
>> +#define DEFINE_GET_SYSREG32(name, opc1, crn, crm, opc2) 
>> \
>> +static inline uint32_t get_##name(void) 
>> \
>> +{   \
>> +uint32_t reg;   \
>> +asm volatile("mrc p15, " #opc1 ", %0, " #crn ", " #crm ", " \
>> + #opc2 : "=r" (reg));   \
>> +return reg; \
>> +}
>> +
>> +#define DEFINE_SET_SYSREG32(name, opc1, crn, crm, opc2) 
>> \
>> +static inline void set_##name(uint32_t value)   
>> \
>> +{   \
>> +asm volatile("mcr p15, " #opc1 ", %0, " #crn ", " #crm ", " \
>> + #opc2 :: "r" (value)); \
>^ nit: no space here, checkpatch would complain
>> +}
>> +
>> +#define DEFINE_GET_SYSREG64(name, opc, crm) \
>> +static inline uint64_t get_##name(void) 
>> \
>> +{   \
>> +uint32_t lo, hi;\
>> +asm volatile("mrrc p15, " #opc ", %0, %1, " #crm\
>> + : "=r" (lo), "=r" (hi));   \
>> +return (uint64_t)hi << 32 | lo; \
>> +}
>> +
>> +#define DEFINE_SET_SYSREG64(name, opc, crm) \
>> +static inline void set_##name(uint64_t value)   
>> \
>> +{   \
>> +asm volatile("mcrr p15, " #opc ", %0, %1, " #crm\
>> + :: "r" (value & 0x), "r" (value >> 32));   \
>>  }
>>  
>> +DEFINE_GET_SYSREG32(mpidr, 0, c0, c0, 5)
>> +
>>  /* Only support Aff0 for now, up to 4 cpus */
>>  #define mpidr_to_cpu(mpidr) ((int)((mpidr) & 0xff))
>>  
>> diff --git a/lib/arm64/asm/processor.h b/lib/arm64/asm/processor.h
>> index 84d5c7c..dfa75eb 100644
>> --- a/lib/arm64/asm/processor.h
>> +++ b/lib/arm64/asm/processor.h
>> @@ -66,14 +66,35 @@ static inline unsigned long current_level(void)
>>  return el & 0xc;
>>  }
>>  
>> -#define DEFINE_GET_SYSREG32(reg)\
>> -static inline unsigned int get_##reg(void)  \
>> -{   \
>> -unsigned int reg;   \
>> -asm volatile("mrs %0, " #reg "_el1" : "=r" (reg));  \
>> -return reg; \
>> +#define DEFINE_GET_SYSREG32(reg, el)
>> \
>> +static inline uint32_t get_##reg(void)  
>> \
>> +{   \
>> +uint32_t reg;   \
>> +asm volatile("mrs %0, " #reg "_" #el : "=r" (reg)); \
>> +return reg; \
>>  }
>> -DEFINE_GET_SYSREG32(mpidr)
>> +
>> +#define DEFINE_SET_SYSREG32(reg, el)
>> \
>> +static inline void set_##reg(uint32_t value)
>> \
>> +{   \
>> +asm volatile("msr " #reg "_" #el ", %0" :: "r" (value));  

Re: [Qemu-devel] [PATCH v2] ui: use evdev keymap when running under wayland

[Stefan Hajnoczi]

On Thu, Dec 1, 2016 at 9:41 AM, Daniel P. Berrange  wrote:
> Wayland always uses evdev as its input source, so QEMU
> can use the existing evdev keymap data
>
> Signed-off-by: Daniel P. Berrange 
> ---
>
> Changed in v2
>
>  - Actually add all changed files to commit - gtk.h :-)
>
>  include/ui/gtk.h | 4 
>  ui/gtk.c | 7 +++
>  2 files changed, 11 insertions(+)
>
> diff --git a/include/ui/gtk.h b/include/ui/gtk.h
> index 42ca0fe..b3b5005 100644
> --- a/include/ui/gtk.h
> +++ b/include/ui/gtk.h
> @@ -18,6 +18,10 @@
>  #include 
>  #endif
>
> +#ifdef GDK_WINDOWING_WAYLAND
> +#include 
> +#endif
> +
>  #if defined(CONFIG_OPENGL)
>  #include "ui/egl-helpers.h"
>  #include "ui/egl-context.h"
> diff --git a/ui/gtk.c b/ui/gtk.c
> index e816428..81dba57 100644
> --- a/ui/gtk.c
> +++ b/ui/gtk.c
> @@ -90,6 +90,9 @@
>  #ifndef GDK_IS_X11_DISPLAY
>  #define GDK_IS_X11_DISPLAY(dpy) (dpy == dpy)
>  #endif
> +#ifndef GDK_IS_WAYLAND_DISPLAY
> +#define GDK_IS_WAYLAND_DISPLAY(dpy) (dpy == dpy)
> +#endif
>  #ifndef GDK_IS_WIN32_DISPLAY
>  #define GDK_IS_WIN32_DISPLAY(dpy) (dpy == dpy)
>  #endif
> @@ -1054,6 +1057,10 @@ static int gd_map_keycode(GtkDisplayState *s, 
> GdkDisplay *dpy, int gdk_keycode)
>  qemu_keycode = translate_xfree86_keycode(gdk_keycode - 97);
>  }
>  #endif
> +#ifdef GDK_WINDOWING_WAYLAND
> +} else if (GDK_IS_WAYLAND_DISPLAY(dpy) && gdk_keycode < 158) {
> +qemu_keycode = translate_evdev_keycode(gdk_keycode - 97);
> +#endif
>  } else if (gdk_keycode == 208) { /* Hiragana_Katakana */
>  qemu_keycode = 0x70;
>  } else if (gdk_keycode == 211) { /* backslash */
> --
> 2.9.3
>

Great, you've fixed Wayland!

This is GTK3-only so I used ./configure --with-gtkabi=3.0 on my system
that has both GTK2 and GTK3 headers installed.  ./configure will
select GTK2 by default and I'm not sure if that is a good idea
nowadays.

Tested-by: Stefan Hajnoczi 

Re: [Qemu-devel] [PATCH v2] ui: use evdev keymap when running under wayland

[Stefan Hajnoczi]

On Thu, Dec 1, 2016 at 11:20 AM, Stefan Hajnoczi  wrote:
> On Thu, Dec 1, 2016 at 9:41 AM, Daniel P. Berrange  
> wrote:
>> Wayland always uses evdev as its input source, so QEMU
>> can use the existing evdev keymap data
>>
>> Signed-off-by: Daniel P. Berrange 
>> ---
>>
>> Changed in v2
>>
>>  - Actually add all changed files to commit - gtk.h :-)
>>
>>  include/ui/gtk.h | 4 
>>  ui/gtk.c | 7 +++
>>  2 files changed, 11 insertions(+)
>>
>> diff --git a/include/ui/gtk.h b/include/ui/gtk.h
>> index 42ca0fe..b3b5005 100644
>> --- a/include/ui/gtk.h
>> +++ b/include/ui/gtk.h
>> @@ -18,6 +18,10 @@
>>  #include 
>>  #endif
>>
>> +#ifdef GDK_WINDOWING_WAYLAND
>> +#include 
>> +#endif
>> +
>>  #if defined(CONFIG_OPENGL)
>>  #include "ui/egl-helpers.h"
>>  #include "ui/egl-context.h"
>> diff --git a/ui/gtk.c b/ui/gtk.c
>> index e816428..81dba57 100644
>> --- a/ui/gtk.c
>> +++ b/ui/gtk.c
>> @@ -90,6 +90,9 @@
>>  #ifndef GDK_IS_X11_DISPLAY
>>  #define GDK_IS_X11_DISPLAY(dpy) (dpy == dpy)
>>  #endif
>> +#ifndef GDK_IS_WAYLAND_DISPLAY
>> +#define GDK_IS_WAYLAND_DISPLAY(dpy) (dpy == dpy)
>> +#endif
>>  #ifndef GDK_IS_WIN32_DISPLAY
>>  #define GDK_IS_WIN32_DISPLAY(dpy) (dpy == dpy)
>>  #endif
>> @@ -1054,6 +1057,10 @@ static int gd_map_keycode(GtkDisplayState *s, 
>> GdkDisplay *dpy, int gdk_keycode)
>>  qemu_keycode = translate_xfree86_keycode(gdk_keycode - 97);
>>  }
>>  #endif
>> +#ifdef GDK_WINDOWING_WAYLAND
>> +} else if (GDK_IS_WAYLAND_DISPLAY(dpy) && gdk_keycode < 158) {
>> +qemu_keycode = translate_evdev_keycode(gdk_keycode - 97);
>> +#endif
>>  } else if (gdk_keycode == 208) { /* Hiragana_Katakana */
>>  qemu_keycode = 0x70;
>>  } else if (gdk_keycode == 211) { /* backslash */
>> --
>> 2.9.3
>>
>
> Great, you've fixed Wayland!
>
> This is GTK3-only so I used ./configure --with-gtkabi=3.0 on my system
> that has both GTK2 and GTK3 headers installed.  ./configure will
> select GTK2 by default and I'm not sure if that is a good idea
> nowadays.
>
> Tested-by: Stefan Hajnoczi 

Re: [Qemu-devel] [Nbd] [PATCH v3] doc: Add NBD_CMD_BLOCK_STATUS extension

[Vladimir Sementsov-Ogievskiy]

01.12.2016 13:14, Wouter Verhelst wrote:

Here's another update.

Changes since previous version:
- Rename "allocation context" to "metadata context"
- Stop making metadata context 0 be special; instead, name it
   "BASE:allocation" and allow it to be selected like all other contexts.
- Clarify in a bit more detail when a server MAY omit metadata
   information on a particular metadata context (i.e., only if another
   metadata context that we actually got information for implies it can't
   have meaning). This was always meant that way, but the spec could have
   been a bit more explicit about it.
- Change one SHOULD to a MUST, where it should not have been a SHOULD
   in the first place.

(This applies on top of my previous patch)

Applied and visible at the usual place.

diff --git a/doc/proto.md b/doc/proto.md
index fe7ae53..9c0981f 100644
--- a/doc/proto.md
+++ b/doc/proto.md
@@ -869,16 +869,16 @@ of the newstyle negotiation.
  
  Defined by the experimental `INFO` [extension](https://github.com/NetworkBlockDevice/nbd/blob/extension-info/doc/proto.md).
  
-- `NBD_OPT_ALLOC_CONTEXT` (10)

+- `NBD_OPT_META_CONTEXT` (10)
  
-Return a list of `NBD_REP_ALLOC_CONTEXT` replies, one per context,

+Return a list of `NBD_REP_META_CONTEXT` replies, one per context,
  followed by an `NBD_REP_ACK`. If a server replies to such a request
  with no error message, clients MAY send NBD_CMD_BLOCK_STATUS
  commands during the transmission phase.
  
  If the query string is syntactically invalid, the server SHOULD send

  `NBD_REP_ERR_INVALID`. If the query string is syntactically valid
-but finds no allocation contexts, the server MUST send a single
+but finds no metadata contexts, the server MUST send a single
  reply of type `NBD_REP_ACK`.
  
  This option MUST NOT be requested unless structured replies have

@@ -887,9 +887,9 @@ of the newstyle negotiation.
  
  Data:

  - 32 bits, type
-- String, query to select a subset of the available allocation
+- String, query to select a subset of the available metadata
contexts. If this is not specified (i.e., length is 4 and no
-  command is sent), then the server MUST send all the allocation
+  command is sent), then the server MUST send all the metadata
contexts it knows about. If specified, this query string MUST
start with a name that uniquely identifies a server
implementation; e.g., the reference implementation that
@@ -897,18 +897,22 @@ of the newstyle negotiation.
with 'nbd-server:'
  
  The type may be one of:

-- `NBD_ALLOC_LIST_CONTEXT` (1): the list of allocation contexts
+- `NBD_META_LIST_CONTEXT` (1): the list of metadata contexts
selected by the query string is returned to the client without
-  changing any state (i.e., this does not add allocation contexts
+  changing any state (i.e., this does not add metadata contexts
for further usage).
-- `NBD_ALLOC_ADD_CONTEXT` (2): the list of allocation contexts
+- `NBD_META_ADD_CONTEXT` (2): the list of metadata contexts
selected by the query string is added to the list of existing


If I understand correctly, it should be not 'existing', but 'exporting'. 
So there are several contexts, server knows about. They are definitely 
exists. Some of them may be selected (by client) for export (to client, 
through get_block_status).


so, what about 'list of metadata contexts to export' or something like this?


-  allocation contexts.
-- `NBD_ALLOC_DEL_CONTEXT` (3): the list of allocation contexts
+  metadata contexts.
+- `NBD_META_DEL_CONTEXT` (3): the list of metadata contexts
selected by the query string is removed from the list of used
-  allocation contexts. Servers SHOULD NOT reuse existing allocation
+  metadata contexts. Servers SHOULD NOT reuse existing metadata
context IDs.
  
+The syntax of the query string is not specified, except that

+implementations MUST support adding and removing individual metadata
+contexts by simply listing their names.
+
   Option reply types
  
  These values are used in the "reply type" field, sent by the server

@@ -920,7 +924,7 @@ during option haggling in the fixed newstyle negotiation.
  information is available, or when sending data related to the option
  (in the case of `NBD_OPT_LIST`) has finished. No data.
  
-* `NBD_REP_SERVER` (2)

+- `NBD_REP_SERVER` (2)
  
  A description of an export. Data:
  
@@ -935,21 +939,20 @@ during option haggling in the fixed newstyle negotiation.

particular client request, this field is defined to be a string
suitable for direct display to a human being.
  
-* `NBD_REP_INFO` (3)

+- `NBD_REP_INFO` (3)
  
  Defined by the experimental `INFO` [extension](https://github.com/NetworkBlockDevice/nbd/blob/extension-info/doc/proto.md).
  
-- `NBD_REP_ALLOC_CONTEXT` (4)

+- `NBD_REP_META_CONTEXT` (4)
  
-  

Re: [Qemu-devel] [PATCH v2] ui: use evdev keymap when running under wayland

[Stefan Hajnoczi]

On Thu, Dec 1, 2016 at 11:25 AM, Stefan Hajnoczi  wrote:
> On Thu, Dec 1, 2016 at 11:20 AM, Stefan Hajnoczi  wrote:
>> On Thu, Dec 1, 2016 at 9:41 AM, Daniel P. Berrange  
>> wrote:
>>> Wayland always uses evdev as its input source, so QEMU
>>> can use the existing evdev keymap data
>>>
>>> Signed-off-by: Daniel P. Berrange 
>>> ---
>>>
>>> Changed in v2
>>>
>>>  - Actually add all changed files to commit - gtk.h :-)
>>>
>>>  include/ui/gtk.h | 4 
>>>  ui/gtk.c | 7 +++
>>>  2 files changed, 11 insertions(+)
>>>
>>> diff --git a/include/ui/gtk.h b/include/ui/gtk.h
>>> index 42ca0fe..b3b5005 100644
>>> --- a/include/ui/gtk.h
>>> +++ b/include/ui/gtk.h
>>> @@ -18,6 +18,10 @@
>>>  #include 
>>>  #endif
>>>
>>> +#ifdef GDK_WINDOWING_WAYLAND
>>> +#include 
>>> +#endif
>>> +
>>>  #if defined(CONFIG_OPENGL)
>>>  #include "ui/egl-helpers.h"
>>>  #include "ui/egl-context.h"
>>> diff --git a/ui/gtk.c b/ui/gtk.c
>>> index e816428..81dba57 100644
>>> --- a/ui/gtk.c
>>> +++ b/ui/gtk.c
>>> @@ -90,6 +90,9 @@
>>>  #ifndef GDK_IS_X11_DISPLAY
>>>  #define GDK_IS_X11_DISPLAY(dpy) (dpy == dpy)
>>>  #endif
>>> +#ifndef GDK_IS_WAYLAND_DISPLAY
>>> +#define GDK_IS_WAYLAND_DISPLAY(dpy) (dpy == dpy)
>>> +#endif
>>>  #ifndef GDK_IS_WIN32_DISPLAY
>>>  #define GDK_IS_WIN32_DISPLAY(dpy) (dpy == dpy)
>>>  #endif
>>> @@ -1054,6 +1057,10 @@ static int gd_map_keycode(GtkDisplayState *s, 
>>> GdkDisplay *dpy, int gdk_keycode)
>>>  qemu_keycode = translate_xfree86_keycode(gdk_keycode - 97);
>>>  }
>>>  #endif
>>> +#ifdef GDK_WINDOWING_WAYLAND
>>> +} else if (GDK_IS_WAYLAND_DISPLAY(dpy) && gdk_keycode < 158) {
>>> +qemu_keycode = translate_evdev_keycode(gdk_keycode - 97);
>>> +#endif
>>>  } else if (gdk_keycode == 208) { /* Hiragana_Katakana */
>>>  qemu_keycode = 0x70;
>>>  } else if (gdk_keycode == 211) { /* backslash */
>>> --
>>> 2.9.3
>>>
>>
>> Great, you've fixed Wayland!
>>
>> This is GTK3-only so I used ./configure --with-gtkabi=3.0 on my system
>> that has both GTK2 and GTK3 headers installed.  ./configure will
>> select GTK2 by default and I'm not sure if that is a good idea
>> nowadays.
>>
>> Tested-by: Stefan Hajnoczi 

Sorry, Cole.  I pressed Send too quickly :).  I meant to add:

This patch is especially relevant for Fedora 25 where Wayland is the
default.  Without the GTK UI will not handle cursor and other keys
correctly.

Dan: Come to think of it, ui/sdl.c also has X11 keycode mangling.
Perhaps that is broken too... :(

Stefan

Re: [Qemu-devel] [PATCH v2] ui: use evdev keymap when running under wayland

[Daniel P. Berrange]

On Thu, Dec 01, 2016 at 11:26:59AM +, Stefan Hajnoczi wrote:
> On Thu, Dec 1, 2016 at 11:25 AM, Stefan Hajnoczi  wrote:
> > On Thu, Dec 1, 2016 at 11:20 AM, Stefan Hajnoczi  wrote:
> >> On Thu, Dec 1, 2016 at 9:41 AM, Daniel P. Berrange  
> >> wrote:
> >>> Wayland always uses evdev as its input source, so QEMU
> >>> can use the existing evdev keymap data
> >>>
> >>> Signed-off-by: Daniel P. Berrange 
> >>> ---
> >>>
> >>> Changed in v2
> >>>
> >>>  - Actually add all changed files to commit - gtk.h :-)
> >>>
> >>>  include/ui/gtk.h | 4 
> >>>  ui/gtk.c | 7 +++
> >>>  2 files changed, 11 insertions(+)
> >>>
> >>> diff --git a/include/ui/gtk.h b/include/ui/gtk.h
> >>> index 42ca0fe..b3b5005 100644
> >>> --- a/include/ui/gtk.h
> >>> +++ b/include/ui/gtk.h
> >>> @@ -18,6 +18,10 @@
> >>>  #include 
> >>>  #endif
> >>>
> >>> +#ifdef GDK_WINDOWING_WAYLAND
> >>> +#include 
> >>> +#endif
> >>> +
> >>>  #if defined(CONFIG_OPENGL)
> >>>  #include "ui/egl-helpers.h"
> >>>  #include "ui/egl-context.h"
> >>> diff --git a/ui/gtk.c b/ui/gtk.c
> >>> index e816428..81dba57 100644
> >>> --- a/ui/gtk.c
> >>> +++ b/ui/gtk.c
> >>> @@ -90,6 +90,9 @@
> >>>  #ifndef GDK_IS_X11_DISPLAY
> >>>  #define GDK_IS_X11_DISPLAY(dpy) (dpy == dpy)
> >>>  #endif
> >>> +#ifndef GDK_IS_WAYLAND_DISPLAY
> >>> +#define GDK_IS_WAYLAND_DISPLAY(dpy) (dpy == dpy)
> >>> +#endif
> >>>  #ifndef GDK_IS_WIN32_DISPLAY
> >>>  #define GDK_IS_WIN32_DISPLAY(dpy) (dpy == dpy)
> >>>  #endif
> >>> @@ -1054,6 +1057,10 @@ static int gd_map_keycode(GtkDisplayState *s, 
> >>> GdkDisplay *dpy, int gdk_keycode)
> >>>  qemu_keycode = translate_xfree86_keycode(gdk_keycode - 97);
> >>>  }
> >>>  #endif
> >>> +#ifdef GDK_WINDOWING_WAYLAND
> >>> +} else if (GDK_IS_WAYLAND_DISPLAY(dpy) && gdk_keycode < 158) {
> >>> +qemu_keycode = translate_evdev_keycode(gdk_keycode - 97);
> >>> +#endif
> >>>  } else if (gdk_keycode == 208) { /* Hiragana_Katakana */
> >>>  qemu_keycode = 0x70;
> >>>  } else if (gdk_keycode == 211) { /* backslash */
> >>> --
> >>> 2.9.3
> >>>
> >>
> >> Great, you've fixed Wayland!
> >>
> >> This is GTK3-only so I used ./configure --with-gtkabi=3.0 on my system
> >> that has both GTK2 and GTK3 headers installed.  ./configure will
> >> select GTK2 by default and I'm not sure if that is a good idea
> >> nowadays.
> >>
> >> Tested-by: Stefan Hajnoczi 
> 
> Sorry, Cole.  I pressed Send too quickly :).  I meant to add:
> 
> This patch is especially relevant for Fedora 25 where Wayland is the
> default.  Without the GTK UI will not handle cursor and other keys
> correctly.
> 
> Dan: Come to think of it, ui/sdl.c also has X11 keycode mangling.
> Perhaps that is broken too... :(

SDL doesn't have native Wayland support, so it will be running
via Xwayland, which will use regulard Xorg evdev mapping, so that
should be fine still.

Regards,
Daniel
-- 
|: http://berrange.com  -o-http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org  -o- http://virt-manager.org :|
|: http://entangle-photo.org   -o-http://search.cpan.org/~danberr/ :|

Re: [Qemu-devel] [PATCH v2] ui: use evdev keymap when running under wayland

[Daniel P. Berrange]

On Thu, Dec 01, 2016 at 11:20:36AM +, Stefan Hajnoczi wrote:
> On Thu, Dec 1, 2016 at 9:41 AM, Daniel P. Berrange  
> wrote:
> > Wayland always uses evdev as its input source, so QEMU
> > can use the existing evdev keymap data
> >
> > Signed-off-by: Daniel P. Berrange 
> > ---
> >
> > Changed in v2
> >
> >  - Actually add all changed files to commit - gtk.h :-)
> >
> >  include/ui/gtk.h | 4 
> >  ui/gtk.c | 7 +++
> >  2 files changed, 11 insertions(+)
> >
> > diff --git a/include/ui/gtk.h b/include/ui/gtk.h
> > index 42ca0fe..b3b5005 100644
> > --- a/include/ui/gtk.h
> > +++ b/include/ui/gtk.h
> > @@ -18,6 +18,10 @@
> >  #include 
> >  #endif
> >
> > +#ifdef GDK_WINDOWING_WAYLAND
> > +#include 
> > +#endif
> > +
> >  #if defined(CONFIG_OPENGL)
> >  #include "ui/egl-helpers.h"
> >  #include "ui/egl-context.h"
> > diff --git a/ui/gtk.c b/ui/gtk.c
> > index e816428..81dba57 100644
> > --- a/ui/gtk.c
> > +++ b/ui/gtk.c
> > @@ -90,6 +90,9 @@
> >  #ifndef GDK_IS_X11_DISPLAY
> >  #define GDK_IS_X11_DISPLAY(dpy) (dpy == dpy)
> >  #endif
> > +#ifndef GDK_IS_WAYLAND_DISPLAY
> > +#define GDK_IS_WAYLAND_DISPLAY(dpy) (dpy == dpy)
> > +#endif
> >  #ifndef GDK_IS_WIN32_DISPLAY
> >  #define GDK_IS_WIN32_DISPLAY(dpy) (dpy == dpy)
> >  #endif
> > @@ -1054,6 +1057,10 @@ static int gd_map_keycode(GtkDisplayState *s, 
> > GdkDisplay *dpy, int gdk_keycode)
> >  qemu_keycode = translate_xfree86_keycode(gdk_keycode - 97);
> >  }
> >  #endif
> > +#ifdef GDK_WINDOWING_WAYLAND
> > +} else if (GDK_IS_WAYLAND_DISPLAY(dpy) && gdk_keycode < 158) {
> > +qemu_keycode = translate_evdev_keycode(gdk_keycode - 97);
> > +#endif
> >  } else if (gdk_keycode == 208) { /* Hiragana_Katakana */
> >  qemu_keycode = 0x70;
> >  } else if (gdk_keycode == 211) { /* backslash */
> > --
> > 2.9.3
> >
> 
> Great, you've fixed Wayland!
> 
> This is GTK3-only so I used ./configure --with-gtkabi=3.0 on my system
> that has both GTK2 and GTK3 headers installed.  ./configure will
> select GTK2 by default and I'm not sure if that is a good idea
> nowadays.

We had a discussion on IRC a few weeks back about default UI frontends.

We should certainly prefer GTK3 over GTK2 if both a present, since GTK2
is essentially a dead technology at this time.

> Tested-by: Stefan Hajnoczi 

Regards,
Daniel
-- 
|: http://berrange.com  -o-http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org  -o- http://virt-manager.org :|
|: http://entangle-photo.org   -o-http://search.cpan.org/~danberr/ :|

Re: [Qemu-devel] [kvm-unit-tests PATCH v13 3/4] arm: pmu: Check cycle count increases

[Andre Przywara]

Hi,

On 01/12/16 05:16, Wei Huang wrote:
> From: Christopher Covington 
> 
> Ensure that reads of the PMCCNTR_EL0 are monotonically increasing,
> even for the smallest delta of two subsequent reads.
> 
> Signed-off-by: Christopher Covington 
> Signed-off-by: Wei Huang 
> Reviewed-by: Andrew Jones 
> ---
>  arm/pmu.c | 94 
> +++
>  1 file changed, 94 insertions(+)
> 
> diff --git a/arm/pmu.c b/arm/pmu.c
> index 1fe2b1a..3566a27 100644
> --- a/arm/pmu.c
> +++ b/arm/pmu.c
> @@ -16,6 +16,9 @@
>  #include "asm/barrier.h"
>  #include "asm/processor.h"
>  
> +#define PMU_PMCR_E (1 << 0)
> +#define PMU_PMCR_C (1 << 2)
> +#define PMU_PMCR_LC(1 << 6)
>  #define PMU_PMCR_N_SHIFT   11
>  #define PMU_PMCR_N_MASK0x1f
>  #define PMU_PMCR_ID_SHIFT  16
> @@ -23,10 +26,57 @@
>  #define PMU_PMCR_IMP_SHIFT 24
>  #define PMU_PMCR_IMP_MASK  0xff
>  
> +#define ID_DFR0_PERFMON_SHIFT 24
> +#define ID_DFR0_PERFMON_MASK  0xf
> +
> +#define PMU_CYCLE_IDX 31
> +
> +#define NR_SAMPLES 10
> +
> +static unsigned int pmu_version;
>  #if defined(__arm__)
>  DEFINE_GET_SYSREG32(pmcr, 0, c9, c12, 0)
> +DEFINE_SET_SYSREG32(pmcr, 0, c9, c12, 0)
> +DEFINE_GET_SYSREG32(id_dfr0, 0, c0, c1, 2)
> +DEFINE_SET_SYSREG32(pmselr, 0, c9, c12, 5)
> +DEFINE_SET_SYSREG32(pmxevtyper, 0, c9, c13, 1)
> +DEFINE_GET_SYSREG32(pmccntr32, 0, c9, c13, 0)
> +DEFINE_SET_SYSREG32(pmccntr32, 0, c9, c13, 0)
> +DEFINE_GET_SYSREG64(pmccntr64, 0, c9)
> +DEFINE_SET_SYSREG64(pmccntr64, 0, c9)
> +DEFINE_SET_SYSREG32(pmcntenset, 0, c9, c12, 1)
> +
> +static inline uint64_t get_pmccntr(void)
> +{
> + if (pmu_version == 0x3)
> + return get_pmccntr64();
> + else
> + return get_pmccntr32();
> +}
> +
> +static inline void set_pmccntr(uint64_t value)
> +{
> + if (pmu_version == 0x3)
> + set_pmccntr64(value);
> + else
> + set_pmccntr32(value & 0x);
> +}
> +
> +/* PMCCFILTR is an obsolete name for PMXEVTYPER31 in ARMv7 */
> +static inline void set_pmccfiltr(uint32_t value)
> +{
> + set_pmselr(PMU_CYCLE_IDX);
> + set_pmxevtyper(value);
> + isb();
> +}
>  #elif defined(__aarch64__)
>  DEFINE_GET_SYSREG32(pmcr, el0)
> +DEFINE_SET_SYSREG32(pmcr, el0)
> +DEFINE_GET_SYSREG32(id_dfr0, el1)
> +DEFINE_GET_SYSREG64(pmccntr, el0);
> +DEFINE_SET_SYSREG64(pmccntr, el0);
> +DEFINE_SET_SYSREG32(pmcntenset, el0);
> +DEFINE_SET_SYSREG32(pmccfiltr, el0);
>  #endif
>  
>  /*
> @@ -52,11 +102,55 @@ static bool check_pmcr(void)
>   return ((pmcr >> PMU_PMCR_IMP_SHIFT) & PMU_PMCR_IMP_MASK) != 0;
>  }
>  
> +/*
> + * Ensure that the cycle counter progresses between back-to-back reads.
> + */
> +static bool check_cycles_increase(void)
> +{
> + bool success = true;
> +
> + /* init before event access, this test only cares about cycle count */
> + set_pmcntenset(1 << PMU_CYCLE_IDX);
> + set_pmccfiltr(0); /* count cycles in EL0, EL1, but not EL2 */
> + set_pmccntr(0);

Why do we need this? Shouldn't PMU_PMCR_C below take care of that?

> +
> + set_pmcr(get_pmcr() | PMU_PMCR_LC | PMU_PMCR_C | PMU_PMCR_E);
> +
> + for (int i = 0; i < NR_SAMPLES; i++) {
> + uint64_t a, b;
> +
> + a = get_pmccntr();
> + b = get_pmccntr();
> +
> + if (a >= b) {
> + printf("Read %"PRId64" then %"PRId64".\n", a, b);
> + success = false;
> + break;
> + }
> + }
> +
> + set_pmcr(get_pmcr() & ~PMU_PMCR_E);
> +
> + return success;
> +}
> +
> +void pmu_init(void)

Mmh, this function doesn't really initialize anything, does it?
Should it be named pmu_available() or pmu_version() or the like?

And should we bail out early here (or rather at the caller) if this
register reports that no PMU is available? For instance by making it
return a boolean?

> +{
> + uint32_t dfr0;
> +
> + /* probe pmu version */
> + dfr0 = get_id_dfr0();
> + pmu_version = (dfr0 >> ID_DFR0_PERFMON_SHIFT) & ID_DFR0_PERFMON_MASK;
> + report_info("PMU version: %d", pmu_version);
> +}
> +
>  int main(void)
>  {
>   report_prefix_push("pmu");
>  
> + pmu_init();
>   report("Control register", check_pmcr());
> + report("Monotonically increasing cycle count", check_cycles_increase());

I wonder if we should skip this test if check_pmcr() has returned false
before? We let it return a boolean, so it seems quite natural to use
this information here.
This would avoid a lot of false FAILs due to the PMU not being available
(because QEMU is too old, for instance).

Cheers,
Andre.

Re: [Qemu-devel] [kvm-unit-tests PATCH v13 2/4] arm: Add PMU test

[Andre Przywara]

Hi,

On 01/12/16 09:03, Andrew Jones wrote:
> On Wed, Nov 30, 2016 at 11:16:40PM -0600, Wei Huang wrote:
>> From: Christopher Covington 
>>
>> Beginning with a simple sanity check of the control register, add
>> a unit test for the ARM Performance Monitors Unit (PMU). PMU register
>> was read using the newly defined macros.
>>
>> Signed-off-by: Christopher Covington 
>> Signed-off-by: Wei Huang 
>> Reviewed-by: Andrew Jones 
>> ---
>>  arm/Makefile.common |  3 ++-
>>  arm/pmu.c   | 62 
>> +
>>  arm/unittests.cfg   |  5 +
>>  3 files changed, 69 insertions(+), 1 deletion(-)
>>  create mode 100644 arm/pmu.c
>>
>> diff --git a/arm/Makefile.common b/arm/Makefile.common
>> index f37b5c2..5da2fdd 100644
>> --- a/arm/Makefile.common
>> +++ b/arm/Makefile.common
>> @@ -12,7 +12,8 @@ endif
>>  tests-common = \
>>  $(TEST_DIR)/selftest.flat \
>>  $(TEST_DIR)/spinlock-test.flat \
>> -$(TEST_DIR)/pci-test.flat
>> +$(TEST_DIR)/pci-test.flat \
>> +$(TEST_DIR)/pmu.flat
>>  
>>  all: test_cases
>>  
>> diff --git a/arm/pmu.c b/arm/pmu.c
>> new file mode 100644
>> index 000..1fe2b1a
>> --- /dev/null
>> +++ b/arm/pmu.c
>> @@ -0,0 +1,62 @@
>> +/*
>> + * Test the ARM Performance Monitors Unit (PMU).
>> + *
>> + * Copyright (c) 2015-2016, The Linux Foundation. All rights reserved.
>> + *
>> + * This program is free software; you can redistribute it and/or modify it
>> + * under the terms of the GNU Lesser General Public License version 2.1 and
>> + * only version 2.1 as published by the Free Software Foundation.
>> + *
>> + * This program is distributed in the hope that it will be useful, but 
>> WITHOUT
>> + * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
>> + * FITNESS FOR A PARTICULAR PURPOSE. See the GNU Lesser General Public 
>> License
>> + * for more details.
>> + */
>> +#include "libcflat.h"
>> +#include "asm/barrier.h"
>> +#include "asm/processor.h"
>> +
>> +#define PMU_PMCR_N_SHIFT   11
>> +#define PMU_PMCR_N_MASK0x1f
>> +#define PMU_PMCR_ID_SHIFT  16
>> +#define PMU_PMCR_ID_MASK   0xff
>> +#define PMU_PMCR_IMP_SHIFT 24
>> +#define PMU_PMCR_IMP_MASK  0xff
>> +
>> +#if defined(__arm__)
>> +DEFINE_GET_SYSREG32(pmcr, 0, c9, c12, 0)
>> +#elif defined(__aarch64__)
>> +DEFINE_GET_SYSREG32(pmcr, el0)
>> +#endif
>> +
>> +/*
>> + * As a simple sanity check on the PMCR_EL0, ensure the implementer field 
>> isn't
>> + * null. Also print out a couple other interesting fields for diagnostic
>> + * purposes. For example, as of fall 2016, QEMU TCG mode doesn't implement
>> + * event counters and therefore reports zero event counters, but hopefully
>> + * support for at least the instructions event will be added in the future 
>> and
>> + * the reported number of event counters will become nonzero.
>> + */
>> +static bool check_pmcr(void)
>> +{
>> +uint32_t pmcr;
> 
> So based on my comments from the previous patch, pmcr should be
> 'unsigned int'

I don't think so. At least here as a _variable_ type uint32_t is
probably the right one, as the ARMv8 ARM explicitly says that PMCR is a
32-bit register, for both bitnesses. I find it only natural to express
it here accordingly.
I believe this is a different (though related) discussion from the
return type of the accessor functions.

Cheers,
Andre.

>> +
>> +pmcr = get_pmcr();
>> +
>> +report_info("PMU implementer/ID code/counters: 0x%x(\"%c\")/0x%x/%d",
>> +(pmcr >> PMU_PMCR_IMP_SHIFT) & PMU_PMCR_IMP_MASK,
>> +((pmcr >> PMU_PMCR_IMP_SHIFT) & PMU_PMCR_IMP_MASK) ? : ' ',
>> +(pmcr >> PMU_PMCR_ID_SHIFT) & PMU_PMCR_ID_MASK,
>> +(pmcr >> PMU_PMCR_N_SHIFT) & PMU_PMCR_N_MASK);
>> +
>> +return ((pmcr >> PMU_PMCR_IMP_SHIFT) & PMU_PMCR_IMP_MASK) != 0;
>> +}
>> +
>> +int main(void)
>> +{
>> +report_prefix_push("pmu");
>> +
>> +report("Control register", check_pmcr());
>> +
>> +return report_summary();
>> +}
>> diff --git a/arm/unittests.cfg b/arm/unittests.cfg
>> index ae32a42..816f494 100644
>> --- a/arm/unittests.cfg
>> +++ b/arm/unittests.cfg
>> @@ -58,3 +58,8 @@ groups = selftest
>>  [pci-test]
>>  file = pci-test.flat
>>  groups = pci
>> +
>> +# Test PMU support
>> +[pmu]
>> +file = pmu.flat
>> +groups = pmu
>> -- 
>> 1.8.3.1
>>
>>
> 
> drew 
> 

Re: [Qemu-devel] Linux kernel polling for QEMU

[Stefan Hajnoczi]

On Wed, Nov 30, 2016 at 07:41:11PM +0200, Avi Kivity wrote:
> On 11/29/2016 12:45 PM, Stefan Hajnoczi wrote:
> > On Mon, Nov 28, 2016 at 04:41:13PM +0100, Paolo Bonzini wrote:
> > > On 28/11/2016 16:29, Stefan Hajnoczi wrote:
> > > > Thanks for sharing the link.  I'll let you know before embarking on an
> > > > effort to make epoll support busy_loop.
> > > > 
> > > > At the moment I'm still evaluating whether the good results we've gotten
> > > > from polling in QEMU userspace are preserved when polling is shifted to
> > > > the kernel.
> > > > 
> > > > FWIW I've prototyped ioctl(EVENTFD_SET_POLL_INFO) but haven't had a
> > > > chance to test it yet:
> > > > https://github.com/stefanha/linux/commit/133e8f1da8eb5364cd5c5f7162decbc79175cd13
> > > This would add a system call every time the main loop processes a vring,
> > > wouldn't it?
> > Yes, this is a problem and is the reason I haven't finished implementing
> > a test using QEMU yet.
> > 
> > My proposed eventfd polling mechanism doesn't work well with descriptor
> > ring indices because the polling info needs to be updated each event
> > loop iteration with the last seen ring index.
> > 
> > This can be solved by making struct eventfd_poll_info.value take a
> > userspace memory address.  The value to compare against is fetched each
> > polling iteration, avoiding the need for ioctl calls.
> > 
> 
> Maybe we could do the same for sockets?  When data is available on a socket
> (or when it becomes writable), write to a user memory location.
> 
> I, too, have an interest in polling; in my situation most of the polling
> happens in userspace.

You are trying to improve on the latency of non-blocking
ppoll(2)/epoll_wait(2) call?

Stefan


signature.asc
Description: PGP signature

Re: [Qemu-devel] [PATCH v4 1/1] crypto: add virtio-crypto driver

[Stefan Hajnoczi]

On Thu, Dec 01, 2016 at 02:27:19AM +, Gonglei (Arei) wrote:
> > On Tue, Nov 29, 2016 at 08:48:14PM +0800, Gonglei wrote:
> > > diff --git a/drivers/crypto/virtio/virtio_crypto_algs.c
> > b/drivers/crypto/virtio/virtio_crypto_algs.c
> > > new file mode 100644
> > > index 000..08b077f
> > > --- /dev/null
> > > +++ b/drivers/crypto/virtio/virtio_crypto_algs.c
> > > @@ -0,0 +1,518 @@
> > > + /* Algorithms supported by virtio crypto device
> > > +  *
> > > +  * Authors: Gonglei 
> > > +  *
> > > +  * Copyright 2016 HUAWEI TECHNOLOGIES CO., LTD.
> > > +  *
> > > +  * This program is free software; you can redistribute it and/or modify
> > > +  * it under the terms of the GNU General Public License as published by
> > > +  * the Free Software Foundation; either version 2 of the License, or
> > > +  * (at your option) any later version.
> > > +  *
> > > +  * This program is distributed in the hope that it will be useful,
> > > +  * but WITHOUT ANY WARRANTY; without even the implied warranty of
> > > +  * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> > > +  * GNU General Public License for more details.
> > > +  *
> > > +  * You should have received a copy of the GNU General Public License
> > > +  * along with this program; if not, see .
> > > +  */
> > > +
> > > +#include 
> > > +#include 
> > > +#include 
> > > +#include 
> > > +#include 
> > > +
> > > +#include 
> > > +#include "virtio_crypto_common.h"
> > > +
> > > +static DEFINE_MUTEX(algs_lock);
> > 
> > Did you run checkpatch.pl?  I think it encourages you to document what
> > the lock protects.
> > 
> Sure. Basically I run checkpatch.py each time. :)
> 
> # ./scripts/checkpatch.pl 0001-crypto-add-virtio-crypto-driver.patch 
> total: 0 errors, 0 warnings, 1873 lines checked
> 
> 0001-crypto-add-virtio-crypto-driver.patch has no obvious style problems and 
> is ready for submission.

Looks like a bug in checkpatch.pl:

# check for spinlock_t definitions without a comment.
if ($line =~ /^.\s*(struct\s+mutex|spinlock_t)\s+\S+;/ ||
$line =~ /^.\s*(DEFINE_MUTEX)\s*\(/) {
my $which = $1;
if (!ctx_has_comment($first_line, $linenr)) {
CHK("UNCOMMENTED_DEFINITION",
"$1 definition without comment\n" . $herecurr);
}
}

Since your mutex definition has the 'static' keyword in front of it
checkpatch.pl misses it!

Andy: Is this checkpatch.pl behavior intentional?

Stefan


signature.asc
Description: PGP signature

Re: [Qemu-devel] Support for using TCG frontend as a library

[Liviu Ionescu]

> On 1 Dec 2016, at 10:50, Paolo Bonzini  wrote:
> 
>> But why only linux-user and not full system emulation too?
> 
> It would simplify the library.  The front-end and helpers have some 
> differences
> between usermode and softmmu, and the latter is much more intertwined with
> the rest of the QEMU infrastructure (MMU indices, limits on multi-page
> translations, etc.)

hmmm... isn't it possible to split somehow the QEMU infrastructure from the ARM 
TCG?

I am also very interested in simplifying GNU ARM Eclipse QEMU, for Cortex-M 
emulation most of the features required to support Linux are only a 
complication of little use.


regards,

Liviu

Re: [Qemu-devel] [PATCH v4 1/1] crypto: add virtio-crypto driver

[Stefan Hajnoczi]

On Thu, Dec 01, 2016 at 02:27:19AM +, Gonglei (Arei) wrote:
> > On Tue, Nov 29, 2016 at 08:48:14PM +0800, Gonglei wrote:
> > > +static int virtio_crypto_alg_ablkcipher_init_session(
> > > + struct virtio_crypto_ablkcipher_ctx *ctx,
> > > + uint32_t alg, const uint8_t *key,
> > > + unsigned int keylen,
> > > + int encrypt)
> > > +{
> > > + struct scatterlist outhdr, key_sg, inhdr, *sgs[3];
> > > + unsigned int tmp;
> > > + struct virtio_crypto *vcrypto = ctx->vcrypto;
> > > + int op = encrypt ? VIRTIO_CRYPTO_OP_ENCRYPT :
> > VIRTIO_CRYPTO_OP_DECRYPT;
> > > + int err;
> > > + unsigned int num_out = 0, num_in = 0;
> > > +
> > > + /*
> > > +  * Avoid to do DMA from the stack, switch to using
> > > +  * dynamically-allocated for the key
> > > +  */
> > > + uint8_t *cipher_key = kmalloc(keylen, GFP_ATOMIC);
> > > +
> > > + if (!cipher_key)
> > > + return -ENOMEM;
> > > +
> > > + memcpy(cipher_key, key, keylen);
> > 
> > Are there any rules on handling key material in the kernel?  This buffer
> > is just kfreed later.  Do you need to zero it out before freeing it?
> > 
> Good questions. For kernel crypto core, each cipher request should be freed
> by skcipher_request_free(): zeroize and free request data structure.
> 
> I need to use kzfree() for key as well. I'll also check other stuffs. Thanks. 
> 
> > > +
> > > + spin_lock(&vcrypto->ctrl_lock);
> > 
> > The QAT accelerator driver doesn't spin while talking to the device in
> > virtio_crypto_alg_ablkcipher_init_session().  I didn't find any other
> > driver examples in the kernel tree, but this function seems like a
> > weakness in the virtio-crypto device.
> > 
> The control queues of virtio-net and virtio-console are also be locked
> Please see:
>  __send_control_msg() in virtio_console.c and virtio-net's control queue
> protected by rtnl lock.
> 
> I didn't want to protect session creations but the virtqueue's operations
> like what other virtio devices do.
> 
> > While QEMU is servicing the create session command this vcpu is blocked.
> > The QEMU global mutex is held so no other vcpu can enter QEMU and the
> > QMP monitor is also blocked.
> > 
> > This is a scalability and performance problem.  Can you look at how QAT
> > avoids this synchronous session setup?
> 
> For QAT driver, the session creation is synchronous as well because it's a
> plain software operation which can be completed ASAP.

I'm mentioning the vmexit and wait for request completion in a spinlock
because the same type of issue has been a performance bottleneck with
virtio guest driver in the past.

If there is a way to avoid spinning then that would be preferred.  It's
basically a known anti-pattern for virtio guest drivers.

Could you initialize the session on the host side when the first
asynchronous data is submitted for encryption/decryption instead of
during init_session()?

Stefan


signature.asc
Description: PGP signature

Re: [Qemu-devel] Linux kernel polling for QEMU

[Avi Kivity]

On 12/01/2016 01:45 PM, Stefan Hajnoczi wrote:

On Wed, Nov 30, 2016 at 07:41:11PM +0200, Avi Kivity wrote:

On 11/29/2016 12:45 PM, Stefan Hajnoczi wrote:

On Mon, Nov 28, 2016 at 04:41:13PM +0100, Paolo Bonzini wrote:

On 28/11/2016 16:29, Stefan Hajnoczi wrote:

Thanks for sharing the link.  I'll let you know before embarking on an
effort to make epoll support busy_loop.

At the moment I'm still evaluating whether the good results we've gotten
from polling in QEMU userspace are preserved when polling is shifted to
the kernel.

FWIW I've prototyped ioctl(EVENTFD_SET_POLL_INFO) but haven't had a
chance to test it yet:
https://github.com/stefanha/linux/commit/133e8f1da8eb5364cd5c5f7162decbc79175cd13

This would add a system call every time the main loop processes a vring,
wouldn't it?

Yes, this is a problem and is the reason I haven't finished implementing
a test using QEMU yet.

My proposed eventfd polling mechanism doesn't work well with descriptor
ring indices because the polling info needs to be updated each event
loop iteration with the last seen ring index.

This can be solved by making struct eventfd_poll_info.value take a
userspace memory address.  The value to compare against is fetched each
polling iteration, avoiding the need for ioctl calls.


Maybe we could do the same for sockets?  When data is available on a socket
(or when it becomes writable), write to a user memory location.

I, too, have an interest in polling; in my situation most of the polling
happens in userspace.

You are trying to improve on the latency of non-blocking
ppoll(2)/epoll_wait(2) call?



Yes, but the concern is for throughput, not latency.


My main loop looks like

   execute some tasks
   poll from many sources

Since epoll_wait(..., 0) has non-trivial costs, I have to limit the 
polling rate, and even so it shows up in the profile.  If the cost were 
lower, I could poll at a higher frequency, resulting in lower worst-case 
latencies for high-priority tasks.

Re: [Qemu-devel] [kvm-unit-tests PATCH v13 2/4] arm: Add PMU test

[Peter Maydell]

On 1 December 2016 at 11:28, Andre Przywara  wrote:
> I don't think so. At least here as a _variable_ type uint32_t is
> probably the right one, as the ARMv8 ARM explicitly says that PMCR is a
> 32-bit register, for both bitnesses.

For 64-bit ARM this is strictly speaking just shorthand for "64-bit
register with the top 32-bit being RES0". It is in theory possible that
a future architecture extension might define uses for those RES0
bits.

thanks
-- PMM

Re: [Qemu-devel] [kvm-unit-tests PATCH v13 2/4] arm: Add PMU test

[Andre Przywara]

Hi,

On 01/12/16 12:02, Peter Maydell wrote:
> On 1 December 2016 at 11:28, Andre Przywara  wrote:
>> I don't think so. At least here as a _variable_ type uint32_t is
>> probably the right one, as the ARMv8 ARM explicitly says that PMCR is a
>> 32-bit register, for both bitnesses.
> 
> For 64-bit ARM this is strictly speaking just shorthand for "64-bit
> register with the top 32-bit being RES0". It is in theory possible that
> a future architecture extension might define uses for those RES0
> bits.

I trade: "in theory possible that a future architecture extension might"
(that's four speculative terms, right?) against:

ARMv8 ARM, D7.4.7  PMCR_EL0, Performance Monitors Control Register:
Attributes
PMCR_EL0 is a 32-bit register.

If this ever gets extended, we would need extra code to deal with the
new bits, so we would need to touch the code anyway. And again, it's
just a local variable, not an interface.

Cheers,
Andre.

P.S. We really should save this discussion for a Friday afternoon ;-)

Re: [Qemu-devel] [PATCH v4 1/1] crypto: add virtio-crypto driver

[Gonglei (Arei)]

>
> Subject: Re: [PATCH v4 1/1] crypto: add virtio-crypto driver
> 
> On Thu, Dec 01, 2016 at 02:27:19AM +, Gonglei (Arei) wrote:
> > > On Tue, Nov 29, 2016 at 08:48:14PM +0800, Gonglei wrote:
> > > > +static int virtio_crypto_alg_ablkcipher_init_session(
> > > > +   struct virtio_crypto_ablkcipher_ctx *ctx,
> > > > +   uint32_t alg, const uint8_t *key,
> > > > +   unsigned int keylen,
> > > > +   int encrypt)
> > > > +{
> > > > +   struct scatterlist outhdr, key_sg, inhdr, *sgs[3];
> > > > +   unsigned int tmp;
> > > > +   struct virtio_crypto *vcrypto = ctx->vcrypto;
> > > > +   int op = encrypt ? VIRTIO_CRYPTO_OP_ENCRYPT :
> > > VIRTIO_CRYPTO_OP_DECRYPT;
> > > > +   int err;
> > > > +   unsigned int num_out = 0, num_in = 0;
> > > > +
> > > > +   /*
> > > > +* Avoid to do DMA from the stack, switch to using
> > > > +* dynamically-allocated for the key
> > > > +*/
> > > > +   uint8_t *cipher_key = kmalloc(keylen, GFP_ATOMIC);
> > > > +
> > > > +   if (!cipher_key)
> > > > +   return -ENOMEM;
> > > > +
> > > > +   memcpy(cipher_key, key, keylen);
> > >
> > > Are there any rules on handling key material in the kernel?  This buffer
> > > is just kfreed later.  Do you need to zero it out before freeing it?
> > >
> > Good questions. For kernel crypto core, each cipher request should be freed
> > by skcipher_request_free(): zeroize and free request data structure.
> >
> > I need to use kzfree() for key as well. I'll also check other stuffs. 
> > Thanks.
> >
> > > > +
> > > > +   spin_lock(&vcrypto->ctrl_lock);
> > >
> > > The QAT accelerator driver doesn't spin while talking to the device in
> > > virtio_crypto_alg_ablkcipher_init_session().  I didn't find any other
> > > driver examples in the kernel tree, but this function seems like a
> > > weakness in the virtio-crypto device.
> > >
> > The control queues of virtio-net and virtio-console are also be locked
> > Please see:
> >  __send_control_msg() in virtio_console.c and virtio-net's control queue
> > protected by rtnl lock.
> >
> > I didn't want to protect session creations but the virtqueue's operations
> > like what other virtio devices do.
> >
> > > While QEMU is servicing the create session command this vcpu is blocked.
> > > The QEMU global mutex is held so no other vcpu can enter QEMU and the
> > > QMP monitor is also blocked.
> > >
> > > This is a scalability and performance problem.  Can you look at how QAT
> > > avoids this synchronous session setup?
> >
> > For QAT driver, the session creation is synchronous as well because it's a
> > plain software operation which can be completed ASAP.
> 
> I'm mentioning the vmexit and wait for request completion in a spinlock
> because the same type of issue has been a performance bottleneck with
> virtio guest driver in the past.
> 
> If there is a way to avoid spinning then that would be preferred.  It's
> basically a known anti-pattern for virtio guest drivers.
> 
Oh, sorry for my misunderstanding. ;)

> Could you initialize the session on the host side when the first
> asynchronous data is submitted for encryption/decryption instead of
> during init_session()?
> 
I remember I discuss this problem with Alex two/three moths
ago. In some scenarios, its indeed a performance problem, such as each request 
has
different algorithms or keys in HTTP connections. It's performance will be 
better
if we just use one data virtqueue to pass session and data to the backend at 
one time.

But for the batch cipher operations with the same algorithm, the performance is 
poor,
Because we can't do batch operations for those requests. That's the great 
function
of session operations on the control virtqueue. Refer to the our clients 
requirements
and the existing QAT driver, the scenario is even more in NFV.

As your mention here, It's hard to do this IMO, because the backend can't know
the previous session belongs to which requests if we don't pass the session_id
to the backend.

Regards,
-Gonglei

Re: [Qemu-devel] [PATCH v2 1/6] arm: Uniquely name imx25 I2C buses.

[Cédric Le Goater]

On 12/01/2016 01:42 AM, Alastair D'Silva wrote:
> On Wed, 2016-11-30 at 09:18 +0100, Cédric Le Goater wrote:
>> On 11/30/2016 06:36 AM, Alastair D'Silva wrote:
>>> From: Alastair D'Silva 
>>>
>>> The imx25 chip provides 3 i2c buses, but they have all been named
>>> "i2c", which makes it difficult to predict which bus a device will
>>> be connected to when specified on the command line.
>>>
>>> This patch addresses the issue by naming the buses uniquely:
>>>   i2c.0 i2c.1 i2c.2
>>>
>>> Signed-off-by: Alastair D'Silva 
>>> ---
>>>  hw/arm/imx25_pdk.c | 4 +---
>>>  hw/i2c/imx_i2c.c   | 6 +-
>>>  2 files changed, 6 insertions(+), 4 deletions(-)
>>>
>>> diff --git a/hw/arm/imx25_pdk.c b/hw/arm/imx25_pdk.c
>>> index 025b608..c6f04d3 100644
>>> --- a/hw/arm/imx25_pdk.c
>>> +++ b/hw/arm/imx25_pdk.c
>>> @@ -138,9 +138,7 @@ static void imx25_pdk_init(MachineState
>>> *machine)
>>>   * We add it here (only on qtest usage) to be able to do a
>>> bit
>>>   * of simple qtest. See "make check" for details.
>>>   */
>>> -i2c_create_slave((I2CBus *)qdev_get_child_bus(DEVICE(&s-
 soc.i2c[0]),
>>> -  "i2c"),
>>> - "ds1338", 0x68);
>>> +i2c_create_slave(s->soc.i2c[0].bus, "ds1338", 0x68);
>>>  }
>>>  }
>>>  
>>> diff --git a/hw/i2c/imx_i2c.c b/hw/i2c/imx_i2c.c
>>> index 37e5a62..7be10fb 100644
>>> --- a/hw/i2c/imx_i2c.c
>>> +++ b/hw/i2c/imx_i2c.c
>>> @@ -305,12 +305,16 @@ static const VMStateDescription
>>> imx_i2c_vmstate = {
>>>  static void imx_i2c_realize(DeviceState *dev, Error **errp)
>>>  {
>>>  IMXI2CState *s = IMX_I2C(dev);
>>> +static int bus_count;
>>
>> hmm, the static is ugly :/ 
>>
>> Isn't there other ways to achieve this naming ? 
>>
>> Thanks,
>>
>> C.  
>>
> 
> I'm not seeing an obvious way around it. The busses are realized
> independently (so I can't implement what we do with the aspeed i2c
> busses), and it is named before fsl-imx25:fsl_imx25_realize() can apply
> specific properties to the bus.
> 
> If you have any suggestions, I'm all ears.

What about that ? 

@@ -310,7 +310,7 @@ static void imx_i2c_realize(DeviceState
   IMX_I2C_MEM_SIZE);
 sysbus_init_mmio(SYS_BUS_DEVICE(dev), &s->iomem);
 sysbus_init_irq(SYS_BUS_DEVICE(dev), &s->irq);
-s->bus = i2c_init_bus(DEVICE(dev), "i2c");
+s->bus = i2c_init_bus(DEVICE(dev), NULL);
 }
 
 static void imx_i2c_class_init(ObjectClass *klass, void *data)

Which should name automatically the I2C objects :

(qemu) info qom-tree 
/machine (imx25-pdk-machine)
  /peripheral (container)
  /soc (fsl,imx25)
  /peripheral-anon (container)
  /unattached (container)
/device[0] (arm926-arm-cpu)
  /unnamed-gpio-in[1] (irq)
  /unnamed-gpio-in[3] (irq)
  /unnamed-gpio-in[2] (irq)
  /unnamed-gpio-in[0] (irq)

/device[15] (imx.i2c)
  /imx.i2c[0] (qemu:memory-region)
  /i2c-bus.0 (i2c-bus)
/device[17] (imx.i2c)
  /imx.i2c[0] (qemu:memory-region)
  /i2c-bus.2 (i2c-bus)
/device[16] (imx.i2c)
  /imx.i2c[0] (qemu:memory-region)
  /i2c-bus.1 (i2c-bus)
   


Cheers,

C. 

Re: [Qemu-devel] [PATCH] monitor: fix object_del for command-line-created objects

[Dr. David Alan Gilbert]

* Daniel P. Berrange (berra...@redhat.com) wrote:
> On Wed, Nov 30, 2016 at 05:06:16PM -0600, Michael Roth wrote:
> > Currently objects specified on the command-line are only partially
> > cleaned up when 'object_del' is issued in either HMP or QMP: the
> > object itself is fully finalized, but the QemuOpts are not removed.
> > This results in the following behavior:
> > 
> >   x86_64-softmmu/qemu-system-x86_64 -monitor stdio \
> > -object memory-backend-ram,id=ram1,size=256M
> > 
> >   QEMU 2.7.91 monitor - type 'help' for more information
> >   (qemu) object_del ram1
> >   (qemu) object_del ram1
> >   object 'ram1' not found
> >   (qemu) object_add memory-backend-ram,id=ram1,size=256M
> >   Duplicate ID 'ram1' for object
> >   Try "help object_add" for more information
> > 
> > which can be an issue for use-cases like memory hotplug.
> > 
> > This happens on the HMP side because hmp_object_add() attempts to
> > create a temporary QemuOpts entry with ID 'ram1', which ends up
> > conflicting with the command-line-created entry, since it was never
> > cleaned up during the previous hmp_object_del() call.
> > 
> > We address this by adding checks in {qmp,hmp}_object_del to determine
> > whether an option group entry matching the object's ID is present,
> > and removing it if it is.
> > 
> > Note that qmp_object_add() never attempts to create a temporary
> > QemuOpts entry, so it does not encounter the duplicate ID error,
> > which is why this isn't generally visible in libvirt.
> > 
> > Cc: "Dr. David Alan Gilbert" 
> > Cc: Markus Armbruster 
> > Cc: Eric Blake 
> > Cc: Daniel Berrange 
> > Signed-off-by: Michael Roth 
> > ---
> >  hmp.c | 10 ++
> >  qmp.c | 10 ++
> >  2 files changed, 20 insertions(+)
> > 
> > diff --git a/hmp.c b/hmp.c
> > index b869617..99b8bf3 100644
> > --- a/hmp.c
> > +++ b/hmp.c
> > @@ -2072,6 +2072,16 @@ void hmp_object_del(Monitor *mon, const QDict *qdict)
> >  
> >  user_creatable_del(id, &err);
> >  hmp_handle_error(mon, &err);
> > +
> > +/* if object was defined on the command-line, remove its corresponding
> > + * option group entry
> > + */
> > +if (err == NULL) {
> > +QemuOptsList *opt_group = qemu_find_opts_err("object", &err);
> > +if (opt_group) {
> > +qemu_opts_del(qemu_opts_find(opt_group, id));
> > +}
> > +}
> >  }
> >  
> >  void hmp_info_memdev(Monitor *mon, const QDict *qdict)
> > diff --git a/qmp.c b/qmp.c
> > index 0028f0b..87c545d 100644
> > --- a/qmp.c
> > +++ b/qmp.c
> > @@ -686,6 +686,16 @@ void qmp_object_add(const char *type, const char *id,
> >  void qmp_object_del(const char *id, Error **errp)
> >  {
> >  user_creatable_del(id, errp);
> > +
> > +/* if object was defined on the command-line, remove its corresponding
> > + * option group entry
> > + */
> > +if (!(errp && *errp)) {
> > +QemuOptsList *opt_group = qemu_find_opts_err("object", errp);
> > +if (opt_group) {
> > +qemu_opts_del(qemu_opts_find(opt_group, id));
> > +}
> > +}
> >  }
> 
> I rather feel like this code ought to be in user_creatable_del(), since
> all code paths which call user_creatable_del() need to do deal with
> this scenario.

Yes that seems cleaner;  the cleanup that's being done is not the result
of either of the monitor's actions.

Dave

> Also I'd like to see a unit test added that exposes this problem and
> demonstrates the fix - could att it to tests/check-qom-proplist.c
> 
> Regards,
> Daniel
> -- 
> |: http://berrange.com  -o-http://www.flickr.com/photos/dberrange/ :|
> |: http://libvirt.org  -o- http://virt-manager.org :|
> |: http://entangle-photo.org   -o-http://search.cpan.org/~danberr/ :|
--
Dr. David Alan Gilbert / dgilb...@redhat.com / Manchester, UK

Re: [Qemu-devel] [kvm-unit-tests PATCH v13 2/4] arm: Add PMU test

[Peter Maydell]

On 1 December 2016 at 12:19, Andre Przywara  wrote:
> Hi,
>
> On 01/12/16 12:02, Peter Maydell wrote:
>> On 1 December 2016 at 11:28, Andre Przywara  wrote:
>>> I don't think so. At least here as a _variable_ type uint32_t is
>>> probably the right one, as the ARMv8 ARM explicitly says that PMCR is a
>>> 32-bit register, for both bitnesses.
>>
>> For 64-bit ARM this is strictly speaking just shorthand for "64-bit
>> register with the top 32-bit being RES0". It is in theory possible that
>> a future architecture extension might define uses for those RES0
>> bits.
>
> I trade: "in theory possible that a future architecture extension might"
> (that's four speculative terms, right?) against:
>
> ARMv8 ARM, D7.4.7  PMCR_EL0, Performance Monitors Control Register:
> Attributes
> PMCR_EL0 is a 32-bit register.

As I say, this just means "64 bit with 32 RES0 bits". See DDI0487A.k
C5.1.1 "System register width":

# In AArch64 state, each encoding in the System instruction space can
# provide access to a 64-bit register. An AArch64 System register is
# described as either a 32-bit register or a 64-bit register. For
# a 32-bit register, the upper bits, bits[63:32], are RES0.

(ie the register is 64-bits, it's just "described as" 32-bits for
convenience.)

thanks
-- PMM

Re: [Qemu-devel] [PATCH v4 1/1] crypto: add virtio-crypto driver

[Gonglei (Arei)]

> 
> On Thu, Dec 01, 2016 at 02:27:19AM +, Gonglei (Arei) wrote:
> > > On Tue, Nov 29, 2016 at 08:48:14PM +0800, Gonglei wrote:
> > > > diff --git a/drivers/crypto/virtio/virtio_crypto_algs.c
> > > b/drivers/crypto/virtio/virtio_crypto_algs.c
> > > > new file mode 100644
> > > > index 000..08b077f
> > > > --- /dev/null
> > > > +++ b/drivers/crypto/virtio/virtio_crypto_algs.c
> > > > @@ -0,0 +1,518 @@
> > > > + /* Algorithms supported by virtio crypto device
> > > > +  *
> > > > +  * Authors: Gonglei 
> > > > +  *
> > > > +  * Copyright 2016 HUAWEI TECHNOLOGIES CO., LTD.
> > > > +  *
> > > > +  * This program is free software; you can redistribute it and/or 
> > > > modify
> > > > +  * it under the terms of the GNU General Public License as published 
> > > > by
> > > > +  * the Free Software Foundation; either version 2 of the License, or
> > > > +  * (at your option) any later version.
> > > > +  *
> > > > +  * This program is distributed in the hope that it will be useful,
> > > > +  * but WITHOUT ANY WARRANTY; without even the implied warranty
> of
> > > > +  * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See
> the
> > > > +  * GNU General Public License for more details.
> > > > +  *
> > > > +  * You should have received a copy of the GNU General Public License
> > > > +  * along with this program; if not, see
> .
> > > > +  */
> > > > +
> > > > +#include 
> > > > +#include 
> > > > +#include 
> > > > +#include 
> > > > +#include 
> > > > +
> > > > +#include 
> > > > +#include "virtio_crypto_common.h"
> > > > +
> > > > +static DEFINE_MUTEX(algs_lock);
> > >
> > > Did you run checkpatch.pl?  I think it encourages you to document what
> > > the lock protects.
> > >
> > Sure. Basically I run checkpatch.py each time. :)
> >
> > # ./scripts/checkpatch.pl 0001-crypto-add-virtio-crypto-driver.patch
> > total: 0 errors, 0 warnings, 1873 lines checked
> >
> > 0001-crypto-add-virtio-crypto-driver.patch has no obvious style problems and
> is ready for submission.
> 
> Looks like a bug in checkpatch.pl:
> 
> # check for spinlock_t definitions without a comment.
> if ($line =~ /^.\s*(struct\s+mutex|spinlock_t)\s+\S+;/ ||
> $line =~ /^.\s*(DEFINE_MUTEX)\s*\(/) {
> my $which = $1;
> if (!ctx_has_comment($first_line, $linenr)) {
> CHK("UNCOMMENTED_DEFINITION",
> "$1 definition without comment\n" . $herecurr);
> }
> }
> 
> Since your mutex definition has the 'static' keyword in front of it
> checkpatch.pl misses it!
> 
Anyway I added the comments. Thanks :)


Regards,
-Gonglei

> Andy: Is this checkpatch.pl behavior intentional?
> 
> Stefan

Re: [Qemu-devel] Support for using TCG frontend as a library

[Peter Maydell]

On 1 December 2016 at 11:54, Liviu Ionescu  wrote:
>
>> On 1 Dec 2016, at 10:50, Paolo Bonzini  wrote:
>>
>>> But why only linux-user and not full system emulation too?
>>
>> It would simplify the library.  The front-end and helpers have some 
>> differences
>> between usermode and softmmu, and the latter is much more intertwined with
>> the rest of the QEMU infrastructure (MMU indices, limits on multi-page
>> translations, etc.)
>
> hmmm... isn't it possible to split somehow the QEMU infrastructure from the 
> ARM TCG?

Possible, certainly. Simple? That's a different question :-)

In general I would favour trying to clean up QEMU's code so
that it is less interdependent (which would make it I think
easier to maintain and test, as well as potentially easier
to use in other contexts); but I think we need to try to tackle
that gradually and doing the easier bits of disentangling first.

thanks
-- PMM

[Qemu-devel] [PATCH v5 0/1] virtio-crypto: add Linux driver

[Gonglei]

v5:
 - add comments for algs_lock and table_lock. [Stefan]
 - use kzfree instead of kfree for key material security. [Stefan]
 - drop unnecessary spin_lock for struct virtio_crypto_ablkcipher_ctx.
 - dynamically allocated memory for iv in order to avoid to do DMA from
   the stack memory in __virtio_crypto_ablkcipher_do_req().
 - add logs for error path in virtio_crypto_alg_validate_key().
 - add lock before calling virtio_break_device() in virtcrypto_update_status()

v4:
 - rework unknow status bit handler by calling virtio_break_device(). [Cornelia]
 - convert space to tab in Kconfig. [Stefan]
 - rename virtio_crypto.c to virtio_crypto_core.c and then make the
   moudle named virtio_crypto.ko for consistency. [Stefan]
 - don't call virtcrypto_dev_stop() on failure path. [Stefan]
 - don't add two empty lines. [Michael]
 - fix possible race by add spin_lock in 
virtio_crypto_alg_ablkcipher_init_session() [Michael and Halil]
 - drop virtcrypto_devmgr_get_first() calling in 
virtio_crypto_ablkcipher_setkey. [Michael]
 - drop superfluous assigned value for virtio_crypto_algs[i].cra_flags
   in virtio_crypto_algs_register(). [Stefan]
 - decrease virtio_crypto_active_devs if calling crypto_register_algs() failed. 
[Stefan]
 - fix some typos here and there. [Stefan]
 - fix missing table_lock usage in virtio_crypto_mgr.c. [Stefan]
 - drop confused comments in virtio_crypto_alg_ablkcipher_init_session()
   for virtqueue_kick(). [Halil]

v3:
 - set cpu affinity when data queues are not equal to the number of online 
cpus. [Michael]
 - add TODO comments for cpu hotplug (changing the relationship of binding 
virtqueue and cpu)
 - use __u32/64 in the config space since the virtio->get() doesn't support 
byte-swap yet. [Michael]
 - drop the whole patch 1 of v2 because the above reason.
 - add VERSION_1 check at the beginning of virtcrypto_probe()
 - s/-1/EPERM/g in virtcrypto_update_status(), don't change err to EFAULT then. 
[Michael]
 - add reset operation before delete the virtqueus. [Micheal]
 - drop an unnecessiry spin_lock calling in virtcrypto_freeze(), avoid possible 
dead lock. [Micheal]
 - redefine parameter alg's type in order to use a cast for it. [Michael]
 - pad all structures to have the same size in one union, and add a member to
   show the union's size in virtio_crypto.h. [Michael]
 - update MAINTAINER file to add virtio-crypto stuff to Michael's entry so that
   the corresponding patches can be CC'ed to Michael as well because the 
virtio-crypto
   doesn't lay in driver/virtio directory. 

The virtio crypto device is a virtual cryptography device
as well as a kind of virtual hardware accelerator for
virtual machines. The encryption anddecryption requests
are placed in the data queue and are ultimately handled by
thebackend crypto accelerators. The second queue is the
control queue used to create or destroy sessions for
symmetric algorithms and will control some advanced features
in the future. The virtio crypto device provides the following
cryptoservices: CIPHER, MAC, HASH, and AEAD.

For more information about virtio-crypto device, please see:
  http://qemu-project.org/Features/VirtioCrypto

For better reviewing, pls see below explaination.

The patch mainly includes five files:

 1) virtio_crypto.h is the header file for virtio-crypto device,
which is based on the virtio-crypto specification. 
 2) virtio_crypto_core.c is the entry of the driver module,
which is similar with other virtio devices, such as virtio-net,
virtio-input etc. 
 3) virtio_crypto_mgr.c is used to manage the virtio
crypto devices in the system. We support up to 32 virtio-crypto
devices currently. I use a global list to store the virtio crypto
devices which refer to Intel QAT driver. Meanwhile, the file
includs the functions of add/del/search/start/stop for virtio
crypto devices.
 4) virtio_crypto_common.h is a private header file for virtio
crypto driver, includes structure definations, and function declarations.
 5) virtio_crypto_algs.c is the realization of algs based on Linux Crypto 
Framwork,
which can register different crypto algorithms. Currently it's only support 
AES-CBC.
The Crypto guys can mainly focus on this file. 


v2:
 - stop doing DMA from the stack, CONFIG_VMAP_STACK=y [Salvatore]
 - convert __virtio32/64 to __le32/64 in virtio_crypto.h
 - remove VIRTIO_CRYPTO_S_STARTED based on the lastest virtio crypto spec.
 - introduces the little edian functions for VIRTIO_1 devices in patch 1.


Gonglei (1):
  crypto: add virtio-crypto driver

 MAINTAINERS  |   9 +
 drivers/crypto/Kconfig   |   2 +
 drivers/crypto/Makefile  |   1 +
 drivers/crypto/virtio/Kconfig|  10 +
 drivers/crypto/virtio/Makefile   |   5 +
 drivers/crypto/virtio/virtio_crypto_algs.c   | 537 +++
 drivers/crypto/virtio/virtio_crypto_common.h | 122 ++
 drivers/crypto/virtio/virtio_crypto_core.c   | 464 +++

[Qemu-devel] [PATCH v5 1/1] crypto: add virtio-crypto driver

[Gonglei]

This patch introduces virtio-crypto driver for Linux Kernel.

The virtio crypto device is a virtual cryptography device
as well as a kind of virtual hardware accelerator for
virtual machines. The encryption anddecryption requests
are placed in the data queue and are ultimately handled by
thebackend crypto accelerators. The second queue is the
control queue used to create or destroy sessions for
symmetric algorithms and will control some advanced features
in the future. The virtio crypto device provides the following
cryptoservices: CIPHER, MAC, HASH, and AEAD.

For more information about virtio-crypto device, please see:
  http://qemu-project.org/Features/VirtioCrypto

CC: Michael S. Tsirkin 
CC: Cornelia Huck 
CC: Stefan Hajnoczi 
CC: Herbert Xu 
CC: Halil Pasic 
CC: David S. Miller 
CC: Zeng Xin 
Signed-off-by: Gonglei 
---
 MAINTAINERS  |   9 +
 drivers/crypto/Kconfig   |   2 +
 drivers/crypto/Makefile  |   1 +
 drivers/crypto/virtio/Kconfig|  10 +
 drivers/crypto/virtio/Makefile   |   5 +
 drivers/crypto/virtio/virtio_crypto_algs.c   | 537 +++
 drivers/crypto/virtio/virtio_crypto_common.h | 122 ++
 drivers/crypto/virtio/virtio_crypto_core.c   | 464 +++
 drivers/crypto/virtio/virtio_crypto_mgr.c| 264 +
 include/uapi/linux/Kbuild|   1 +
 include/uapi/linux/virtio_crypto.h   | 450 ++
 include/uapi/linux/virtio_ids.h  |   1 +
 12 files changed, 1866 insertions(+)
 create mode 100644 drivers/crypto/virtio/Kconfig
 create mode 100644 drivers/crypto/virtio/Makefile
 create mode 100644 drivers/crypto/virtio/virtio_crypto_algs.c
 create mode 100644 drivers/crypto/virtio/virtio_crypto_common.h
 create mode 100644 drivers/crypto/virtio/virtio_crypto_core.c
 create mode 100644 drivers/crypto/virtio/virtio_crypto_mgr.c
 create mode 100644 include/uapi/linux/virtio_crypto.h

diff --git a/MAINTAINERS b/MAINTAINERS
index ad9b965..cccaaf0 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -12810,6 +12810,7 @@ F:  drivers/net/virtio_net.c
 F: drivers/block/virtio_blk.c
 F: include/linux/virtio_*.h
 F: include/uapi/linux/virtio_*.h
+F: drivers/crypto/virtio/
 
 VIRTIO DRIVERS FOR S390
 M: Christian Borntraeger 
@@ -12846,6 +12847,14 @@ S: Maintained
 F: drivers/virtio/virtio_input.c
 F: include/uapi/linux/virtio_input.h
 
+VIRTIO CRYPTO DRIVER
+M:  Gonglei 
+L:  virtualizat...@lists.linux-foundation.org
+L:  linux-cry...@vger.kernel.org
+S:  Maintained
+F:  drivers/crypto/virtio/
+F:  include/uapi/linux/virtio_crypto.h
+
 VIA RHINE NETWORK DRIVER
 S: Orphan
 F: drivers/net/ethernet/via/via-rhine.c
diff --git a/drivers/crypto/Kconfig b/drivers/crypto/Kconfig
index 4d2b81f..7956478 100644
--- a/drivers/crypto/Kconfig
+++ b/drivers/crypto/Kconfig
@@ -555,4 +555,6 @@ config CRYPTO_DEV_ROCKCHIP
 
 source "drivers/crypto/chelsio/Kconfig"
 
+source "drivers/crypto/virtio/Kconfig"
+
 endif # CRYPTO_HW
diff --git a/drivers/crypto/Makefile b/drivers/crypto/Makefile
index ad7250f..bc53cb8 100644
--- a/drivers/crypto/Makefile
+++ b/drivers/crypto/Makefile
@@ -32,3 +32,4 @@ obj-$(CONFIG_CRYPTO_DEV_VMX) += vmx/
 obj-$(CONFIG_CRYPTO_DEV_SUN4I_SS) += sunxi-ss/
 obj-$(CONFIG_CRYPTO_DEV_ROCKCHIP) += rockchip/
 obj-$(CONFIG_CRYPTO_DEV_CHELSIO) += chelsio/
+obj-$(CONFIG_CRYPTO_DEV_VIRTIO) += virtio/
diff --git a/drivers/crypto/virtio/Kconfig b/drivers/crypto/virtio/Kconfig
new file mode 100644
index 000..d80f733
--- /dev/null
+++ b/drivers/crypto/virtio/Kconfig
@@ -0,0 +1,10 @@
+config CRYPTO_DEV_VIRTIO
+   tristate "VirtIO crypto driver"
+   depends on VIRTIO
+   select CRYPTO_AEAD
+   select CRYPTO_AUTHENC
+   select CRYPTO_BLKCIPHER
+   default m
+   help
+ This driver provides support for virtio crypto device. If you
+ choose 'M' here, this module will be called virtio_crypto.
diff --git a/drivers/crypto/virtio/Makefile b/drivers/crypto/virtio/Makefile
new file mode 100644
index 000..dd342c9
--- /dev/null
+++ b/drivers/crypto/virtio/Makefile
@@ -0,0 +1,5 @@
+obj-$(CONFIG_CRYPTO_DEV_VIRTIO) += virtio_crypto.o
+virtio_crypto-objs := \
+   virtio_crypto_algs.o \
+   virtio_crypto_mgr.o \
+   virtio_crypto_core.o
diff --git a/drivers/crypto/virtio/virtio_crypto_algs.c 
b/drivers/crypto/virtio/virtio_crypto_algs.c
new file mode 100644
index 000..5100056
--- /dev/null
+++ b/drivers/crypto/virtio/virtio_crypto_algs.c
@@ -0,0 +1,537 @@
+ /* Algorithms supported by virtio crypto device
+  *
+  * Authors: Gonglei 
+  *
+  * Copyright 2016 HUAWEI TECHNOLOGIES CO., LTD.
+  *
+  * This program is free software; you can redistribute it and/or modify
+  * it under the terms of the GNU General Public License as published by
+  * the Free Software Foundation; either version 2 of the License, or
+  * (at your option) any later ve

Re: [Qemu-devel] [RFCv2 00/12] Clean up compatibility mode handling

[Greg Kurz]

On Wed, 16 Nov 2016 09:17:43 +1100
David Gibson  wrote:

> This series is a significant rework to how we handle CPU compatibility
> modes on ppc.
> 

David,

Please find below the results of the migration tests.

>  * Information about compatibility modes was previously open coded and
>scattered across a number of functions in both target-ppc and spapr
>code.  It's now brought together into a common table of
>compatibility modes.
> 
>  * There was significant conceptual confusion about what a
>compatibility mode means, and how it interacts with the machine
>type.  This cleans that up, clarifying that a compatibility mode
>(as an externally set option) only makes sense on machine types
>that don't permit the guest hypervisor privilege (i.e. 'pseries')
> 
>  * It was previously the user's (or management layer's) responsibility
>to determine compatibility of CPUs on either end for migration.
>This uses the compatibility modes to check that properly during an
>incoming migration.
> 
>  * Some ill-considered sanity checks broke migration from 2.6 to 2.7,
>due to some new instruction classes being added.  This should avoid
>a repeat of that problem for 2.8 (we may be able to backport a
>minimal subset to 2.7-stable to fix the existing problem).
> 
> Patches 1-3 are preliminary cleanups which could stand on their own.
> Patches 4-12 are the compatibility mode cleanup proper.
> 
> So far, this has been mimimally tested.  There are quite a few
> migration cases to check.  For example:
> 
> Basic:
> 
> 1) Boot guest with -cpu host
>   Should go into POWER8 compat mode after CAS
>   Previously would have been raw mode
> 
> 2) Boot guest with -machine pseries,max-cpu-compat=power7 -cpu host
>   Should go into POWER7 compat mode
> 
> 3) Boot guest with -cpu host,compat=power7
>   Should act as (2), but print a warning
> 
> 4) Boot guest via libvirt with power7 compat mode specified in XML
>   Should act as (3), (2) once we fix libvirt
> 
> 5) Hack guest to only advertise power7 compatibility, boot with -cpu host
>   Should go into POWER7 compat mode after CAS
> 
> 6) Hack guest to only advertise real PVRs
>   Should remain in POWER8 raw mode after CAS
> 
> 7) Hack guest to only advertise real PVRs
>Boot with -machine pseries,max-cpu-compat=power8
>   Should fail at CAS time
> 
> 8) Hack guest to only advertise power7 compatibility, boot with -cpu host
>Reboot to normal guest
>   Should go to power7 compat mode after CAS of boot 1
>   Should revert to raw mode on reboot
>   SHould go to power8 compat mode after CAS of boot 2
> 
> Migration:
> 

The QEMU command line used to test migration is as follows:

ppc64-softmmu/qemu-system-ppc64 \
-snapshot \
-nodefaults \
-no-shutdown \
-nographic \
-device virtio-blk-pci,drive=drive0 \
-drive file=/home/greg/images/fedora24-ppc64.qcow2,id=drive0,if=none \
-global virtio-blk-pci.disable-legacy=off \
-global virtio-blk-pci.disable-modern=on \
-device virtio-net,netdev=netdev0,mac=C0:FF:EE:00:00:66,id=net0 \
-netdev tap,id=netdev0,vhost=off,helper=/usr/libexec/qemu-bridge-helper 
\
-global virtio-net-pci.disable-legacy=off \
-global virtio-net-pci.disable-modern=on \
-m 4G \
-serial mon:stdio \
-trace spapr_cas_pvr

Note that virtio devices are explicitely configured to run in legacy
mode because I couldn't pass tests 15 and 16 otherwise, with various
issues including QEMU getting killed by OOM ! I'll focus on these
issues separately.

> 9) Boot guest with qemu-2.6 -machine pseries-2.6 -cpu host
>Migrate to qemu-2.8 -machine pseries-2.6 -cpu host
>   Should work, end up running in power8 raw mode
> 

== QEMU-2.6 ==

spapr_cas_pvr current=0, cpu_match=1, new=0, compat flags=6

== guest (source) ==

cpu : POWER8 (raw), altivec supported

== guest (target) ==

cpu : POWER8 (raw), altivec supported

> 10) Boot guest with qemu-2.7 -machine pseries-2.7 -cpu host
> Migrate to qemu-2.8 -machine pseries-2.7 -cpu host
>   Should work, end up running in power8 raw mode
> 

== QEMU-2.7 ==

spapr_cas_pvr current=0, cpu_match=1, new=0, compat flags=2006

== guest (source) ==

cpu : POWER8 (raw), altivec supported

== guest (target) ==

cpu : POWER8 (raw), altivec supported

> 11) Boot guest with qemu-2.7 -machine pseries-2.7 -cpu host,compat=power7
> Migrate to qemu-2.8 -machine pseries-2.7 -cpu host,compat=power7
>   Should work, be running in POWER7 compat after, but give warning like
>   (3)
> 

== QEMU-2.7 ==

spapr_cas_pvr current=f03, cpu_match=1, new=f03, compat 
flags=2006

== guest (source) ==

cpu : POWER7 (architected), altivec supported

== QEMU-2.8 ==

CPU 'compat' property is deprecated and has no effect; use max-cpu-compat 
machine property i

Re: [Qemu-devel] [kvm-unit-tests PATCH v13 1/4] arm: Define macros for accessing system registers

[Andrew Jones]

On Thu, Dec 01, 2016 at 11:11:55AM +, Andre Przywara wrote:
> Hi,
> 
> On 01/12/16 08:59, Andrew Jones wrote:
> > 
> > Should this be From: Andre?
> 
> No need from my side, this way all the bug reports are send to Wei ;-)
> 
> > On Wed, Nov 30, 2016 at 11:16:39PM -0600, Wei Huang wrote:
> >> This patch defines four macros to assist creating system register
> >> accessors under both ARMv7 and AArch64:
> >>* DEFINE_GET_SYSREG32(name, ...)
> >>* DEFINE_SET_SYSREG32(name, ...)
> >>* DEFINE_GET_SYSREG64(name, ...)
> >>* DEFINE_SET_SYSREG64(name, ...)
> >> These macros are translated to inline functions with consistent naming,
> >> get_##name() and set_##name(), which can be used by C code directly.
> >>
> >> Signed-off-by: Andre Przywara 
> >> Signed-off-by: Wei Huang 
> >> ---
> >>  lib/arm/asm/processor.h   | 37 -
> >>  lib/arm64/asm/processor.h | 35 ---
> >>  2 files changed, 60 insertions(+), 12 deletions(-)
> >>
> >> diff --git a/lib/arm/asm/processor.h b/lib/arm/asm/processor.h
> >> index f25e7ee..3ca6b42 100644
> >> --- a/lib/arm/asm/processor.h
> >> +++ b/lib/arm/asm/processor.h
> >> @@ -33,13 +33,40 @@ static inline unsigned long current_cpsr(void)
> >>  
> >>  #define current_mode() (current_cpsr() & MODE_MASK)
> >>  
> >> -static inline unsigned int get_mpidr(void)
> >> -{
> >> -  unsigned int mpidr;
> >> -  asm volatile("mrc p15, 0, %0, c0, c0, 5" : "=r" (mpidr));
> >> -  return mpidr;
> >> +#define DEFINE_GET_SYSREG32(name, opc1, crn, crm, opc2)   
> >> \
> >> +static inline uint32_t get_##name(void)   
> >> \
> >> +{ \
> >> +  uint32_t reg;   \
> >> +  asm volatile("mrc p15, " #opc1 ", %0, " #crn ", " #crm ", " \
> >> +   #opc2 : "=r" (reg));   \
> >> +  return reg; \
> >> +}
> >> +
> >> +#define DEFINE_SET_SYSREG32(name, opc1, crn, crm, opc2)   
> >> \
> >> +static inline void set_##name(uint32_t value) 
> >> \
> >> +{ \
> >> +  asm volatile("mcr p15, " #opc1 ", %0, " #crn ", " #crm ", " \
> >> +   #opc2 :: "r" (value)); \
> >^ nit: no space here, checkpatch would complain
> >> +}
> >> +
> >> +#define DEFINE_GET_SYSREG64(name, opc, crm)   
> >> \
> >> +static inline uint64_t get_##name(void)   
> >> \
> >> +{ \
> >> +  uint32_t lo, hi;\
> >> +  asm volatile("mrrc p15, " #opc ", %0, %1, " #crm\
> >> +   : "=r" (lo), "=r" (hi));   \
> >> +  return (uint64_t)hi << 32 | lo; \
> >> +}
> >> +
> >> +#define DEFINE_SET_SYSREG64(name, opc, crm)   
> >> \
> >> +static inline void set_##name(uint64_t value) 
> >> \
> >> +{ \
> >> +  asm volatile("mcrr p15, " #opc ", %0, %1, " #crm\
> >> +   :: "r" (value & 0x), "r" (value >> 32));   \
> >>  }
> >>  
> >> +DEFINE_GET_SYSREG32(mpidr, 0, c0, c0, 5)
> >> +
> >>  /* Only support Aff0 for now, up to 4 cpus */
> >>  #define mpidr_to_cpu(mpidr) ((int)((mpidr) & 0xff))
> >>  
> >> diff --git a/lib/arm64/asm/processor.h b/lib/arm64/asm/processor.h
> >> index 84d5c7c..dfa75eb 100644
> >> --- a/lib/arm64/asm/processor.h
> >> +++ b/lib/arm64/asm/processor.h
> >> @@ -66,14 +66,35 @@ static inline unsigned long current_level(void)
> >>return el & 0xc;
> >>  }
> >>  
> >> -#define DEFINE_GET_SYSREG32(reg)  \
> >> -static inline unsigned int get_##reg(void)\
> >> -{ \
> >> -  unsigned int reg;   \
> >> -  asm volatile("mrs %0, " #reg "_el1" : "=r" (reg));  \
> >> -  return reg; \
> >> +#define DEFINE_GET_SYSREG32(reg, el)  
> >> \
> >> +static inline uint32_t get_##reg(void)
> >> \
> >> +{ \
> >> +  uint32_t reg;   \
> >> +  asm volatile("mrs %0, " #reg "_" #el : "=r" (reg)); \
> >> +  return reg; \
> >>  }
> >> -DEFINE_GET_SYSREG32(mpidr)
> >> +
> >> +#define DEFINE_SET_SYSREG32(reg, el)

Re: [Qemu-devel] [PATCH v5 00/19] Cleanup of TCG tests

[Pranith Kumar]

Peter Maydell writes:

> On 1 December 2016 at 05:14, Pranith Kumar  wrote:
>> Hello,
>>
>> This patch series cleans up the tcg tests in tests/tcg folder.
>
>>  linux-user/mmap.c   |  27 +++---
>>  linux-user/syscall.c|   2 +-
>
> These aren't test code -- it would probably be better not
> to mix actual bug fixes up in a series that's mostly trying
> to fix up test code.

OK, I will send these in a separate series.

>
> I'd still like to see what the plan is for having this
> actually work given that you don't know whether there's a
> cross-toolchain available. That's the fundamental reason
> why these tests have been left to bitrot.

The current idea is to call these tests explicitly with the cross
compiler passed as an argument. We can, at the very least, download the cross
compilers and enable the tests in travis.

Thanks,
-- 
Pranith

Re: [Qemu-devel] Support for using TCG frontend as a library

[Liviu Ionescu]

> On 1 Dec 2016, at 14:38, Peter Maydell  wrote:
> 
> ... clean up QEMU's code so
> that it is less interdependent ...

that's a good idea anyway, but this does not address the current issue.

if I'd have a separate library with ARM TCG, for Cortex-M emulation I'd 
probably write a simple memory management routine, to address flash, ram & 
peripherals and with an equally simple variant of the peripheral implementation 
I'd be done. no need to handle MMU, no need to worry about VM, KVM, 
save/restore objects, monitor, etc (actually no need for the complicated 
objects implementation at all).


regards,

Liviu

Re: [Qemu-devel] [PULL 0/5] virtio, vhost, pc: fixes

[Stefan Hajnoczi]

On Thu, Dec 01, 2016 at 05:58:40AM +0200, Michael S. Tsirkin wrote:
> Comments on patches included:
> 
> - a spec update seems important for 2.8 as incorrect
> spec makes people implement backends incorrectly.
> - undefined behaviour fix seems important too -
> who knows what would compiler optimizers come up with
> 
> Others are imho clearly uncontroversial.
> 
> 
> The following changes since commit 1cd56fd2e14f67ead2f0458b4ae052f19865c41c:
> 
>   Update version for v2.8.0-rc2 release (2016-11-29 22:26:25 +)
> 
> are available in the git repository at:
> 
>   git://git.kernel.org/pub/scm/virt/kvm/mst/qemu.git tags/for_upstream
> 
> for you to fetch changes up to 9730280d54634caa5d63f0d8fcd85da8311d2ebf:
> 
>   virtio-crypto: fix uninitialized variables (2016-11-30 04:22:18 +0200)
> 
> 
> virtio, vhost, pc: fixes
> 
> Minor fixes since 2.8.0-rc2.
> 
> Signed-off-by: Michael S. Tsirkin 
> 
> 
> Gonglei (1):
>   virtio-crypto: fix uninitialized variables
> 
> Laszlo Ersek (2):
>   loader: fix handling of custom address spaces when adding ROM blobs
>   loader: fix undefined behavior in rom_order_compare()
> 
> Peter Xu (1):
>   intel_iommu: fix incorrect device invalidate
> 
> Wei Wang (1):
>   spec/vhost-user: fix the VHOST_USER prefix
> 
>  docs/specs/vhost-user.txt | 20 ++--
>  hw/lm32/lm32_hwsetup.h|  2 +-
>  include/hw/loader.h   |  6 +++---
>  hw/arm/virt-acpi-build.c  |  2 +-
>  hw/core/loader.c  |  6 --
>  hw/i386/acpi-build.c  |  2 +-
>  hw/i386/intel_iommu.c |  1 +
>  hw/virtio/virtio-crypto.c |  2 +-
>  8 files changed, 22 insertions(+), 19 deletions(-)
> 

Thanks, applied to my staging tree:
https://github.com/stefanha/qemu/commits/staging

Stefan


signature.asc
Description: PGP signature

Re: [Qemu-devel] [PULL 0/1] ppc-for-2.8 queue 20161201

[Stefan Hajnoczi]

On Thu, Dec 01, 2016 at 03:44:40PM +1100, David Gibson wrote:
> The following changes since commit 1cd56fd2e14f67ead2f0458b4ae052f19865c41c:
> 
>   Update version for v2.8.0-rc2 release (2016-11-29 22:26:25 +)
> 
> are available in the git repository at:
> 
>   git://github.com/dgibson/qemu.git tags/ppc-for-2.8-20161201
> 
> for you to fetch changes up to 5c0139a8c2f01e068c96d456ecf12b0eeb707660:
> 
>   spapr: fix default DRC state for coldplugged LMBs (2016-12-01 13:41:00 
> +1100)
> 
> 
> ppc patch queue 2016-12-01
> 
> Just a single migration / hotplug fix in this set.  I believe it's
> important enough to go in this late in the 2.8 release process.
> 
> 
> Michael Roth (1):
>   spapr: fix default DRC state for coldplugged LMBs
> 
>  hw/ppc/spapr.c | 5 +
>  1 file changed, 5 insertions(+)

Thanks, applied to my staging tree:
https://github.com/stefanha/qemu/commits/staging

Stefan


signature.asc
Description: PGP signature

Re: [Qemu-devel] [kvm-unit-tests PATCH v13 4/4] arm: pmu: Add CPI checking

[Andrew Jones]

On Thu, Dec 01, 2016 at 10:19:13AM +, Andre Przywara wrote:
> Hi Drew,
> 
> actually unrelated to this actual patch, but since you mentioned it:
> 
> > As we work out how best to handle tcg-only tests in order to get Alex
> > Bennee's MTTCG tests merged, we'll probably revisit this file,
> 
> So when I was experimenting with kvmtool, I realized that some tests
> would need to be QEMU only. Also I was tempted to try some tests either
> on bare metal machines or in a Fast Model.
> So I wonder if we should have some constraints or tags on the tests, so
> that a certain backend can filter on this and skip if it's not capable?

So far we've been using unittests.cfg flags for filtering, but we could
also teach configure how to set up the build for only certain tests, i.e.
new config options and makefile targets could take use further. The
unittests.cfg file could be split into multiple cfg files as well,
teaching run_tests.sh how to select the right one.

> 
> Just wanted to mention this so that we can use this refactoring
> opportunity to come up with something more generic than just a boolean
> TGC vs. KVM.
> Maybe we should introduce the notion of a "test backend"? That could be
> QEMU/KVM and TCG for now, but later extended to cover kvmtool and
>

So the $TEST_DIR/run (e.g. arm/run) script is currently qemu focused,
and is learning how to deal with both KVM and TCG. We haven't been
trying to keep qemu knowledge in that one file, but we could probably
do it, i.e. rename it to run-qemu and make sure all common script
files are kvm userspace agnostic. I don't think that should be too
difficult. We'll likely need more build config options for this though
too, as load addresses, etc. may change.

> probably other hypervisors like Xen as well.

Also doable once we isolate the hypervisor userspace specifics from
everything else. Same goes for getting tests to run on bare-metal,
launched from the grub prompt or UEFI. But, eventually people will
be confused with the project's name *kvm*-unit-tests :-)

Thanks,
drew

Re: [Qemu-devel] [PATCH 1/3] timer: fix misleading comment in timer.h

[Stefan Hajnoczi]

On Wed, Nov 30, 2016 at 11:30:38PM -0500, Yaowei Bai wrote:
> It's timer to expire, not clock.
> 
> Signed-off-by: Yaowei Bai 
> ---
>  include/qemu/timer.h | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)

For the whole series:

Reviewed-by: Stefan Hajnoczi 

PS: I suggest sending a cover letter "[PATCH 0/3]" in the future.  This
makes it easy for reviewers to indicate they have reviewed the whole
series.  Without a cover letter it's ambiguous whether my single
Reviewed-by: applies to just this patch or to the whole series - and
patch management tools will probably get it wrong too.


signature.asc
Description: PGP signature

[Qemu-devel] [PATCH v5 00/10] tcg mips64 and mips r6 improvements

[Jin Guojie]

Changes in v5:
  * Update against master(v2.8.0-rc2)
  * Fix a bug: 64-bit big-endian guests hang on mips64 little-endian
  hosts, and vice versa. This bug was first introduced in v2 patch,
  due to obvious misuse of ret/arg registers in tcg_out_bswap64().

tcg_out_opc_reg(s, OPC_DSBH, ret, 0, arg);
  - tcg_out_opc_reg(s, OPC_DSHD, ret, 0, arg);
  + tcg_out_opc_reg(s, OPC_DSHD, ret, 0, ret);

  * Fix a style problem: checkpatch.pl forbids 'extern' to be used in .c.

  ERROR: externs should be avoided in .c files
  #28: FILE: tcg/mips/tcg-target.inc.c:39:
  +extern int link_error(void);

  Simply comment the type identifier to pass the check.

  * Tested successfully on following machines:
  
| HOST| qemu-system | Debian ISO  |
|-|
| mips 32 le  |i386 |i386 |
| mips 32 le  |x86_64   |i386 |
| mips 32 le  |x86_64   |amd64|
| mips 64 le  |i386 |i386 |
| mips 64 le  |x86_64   |i386 |
| mips 64 le  |x86_64   |amd64|
| mips 64 le  |  mips 64 be |  mips 64 be |
|-|
| mips 32 be  |i386 | i386|
| mips 32 be  |x86_64   | i386|
| mips 32 be  |x86_64   | amd64   |
| mips 64 be  |i386 | i386|
| mips 64 be  |x86_64   | i386|
| mips 64 be  |x86_64   | amd64   |
| mips n32 be |386  | i386|
| mips n32 be |x86_64   | i386|
| mips n32 be |x86_64   | amd64   |

(No plan to test MIPS R6 in this patch.)

  Summary of changes from v4:

  | tcg-mips: Support 64-bit opcodes   | Fix tcg_out_bswap64() |
  | tcg-mips: Adjust qemu_ld/st for mips64 | Fix a style problem   |


Changes in v4:
  * tcg_out_qemu_ld_slow_path: always sign-extend 32-bit loads.
Provide a better solution than patch11 in v3.
Fix the blocking bug when emulating i386 kernel on mips64el.
  * Redefine LO_OFF/HI_OFF as v2.
On mips64 host, they are defined as link_error, to ensure that
all paths that lead to the use of the symbol are eliminated by
the compiler.

Changes in v3:
  * Update against master(v2.8.0-rc1)
  * Tested on Loongson as mips32r2(el) and mips64r2(el) hosts.
Loongson only implements little-endian mips32/mips64 ISA.
  * Fully work for 32-bit and 64-bit guests.
Fix two bugs???segmentation fault on mips64el with 32-bit guests,
  blocking when emulating i386 kernel on mips64el.
  * Fix some minor style problems.
  * PATCH v2 12~16 are not examined due to the lack of R6 machine. 

Jin Guojie (10):
  tcg-mips: Move bswap code to a subroutine
  tcg-mips: Add mips64 opcodes
  tcg-mips: Support 64-bit opcodes
  tcg-mips: Add bswap32u and bswap64
  tcg-mips: Adjust move functions for mips64
  tcg-mips: Adjust load/store functions for mips64
  tcg-mips: Adjust prologue for mips64
  tcg-mips: Add tcg unwind info
  tcg-mips: Adjust calling conventions for mips64
  tcg-mips: Adjust qemu_ld/st for mips64

Cc: Aurelien Jarno 
Cc: James Hogan 
Tested-by: YunQiang Su 
Signed-off-by: Richard Henderson 
Signed-off-by: Jin Guojie 

 tcg/mips/tcg-target.h |   60 ++-
 tcg/mips/tcg-target.inc.c | 1170 +++--
 2 files changed, 977 insertions(+), 253 deletions(-)

-- 
2.1.0

[Qemu-devel] [PATCH v5 06/10] tcg-mips: Adjust load/store functions for mips64

[Jin Guojie]

tcg_out_ldst: using a generic ALIAS_PADD to avoid ifdefs
tcg_out_ld: generates LD or LW
tcg_out_st: generates SD or SW

Cc: Aurelien Jarno 
Cc: James Hogan 
Signed-off-by: Richard Henderson 
Signed-off-by: Jin Guojie 
---
 tcg/mips/tcg-target.inc.c | 14 +++---
 1 file changed, 11 insertions(+), 3 deletions(-)

diff --git a/tcg/mips/tcg-target.inc.c b/tcg/mips/tcg-target.inc.c
index 18368f0..5cc8df3 100644
--- a/tcg/mips/tcg-target.inc.c
+++ b/tcg/mips/tcg-target.inc.c
@@ -697,7 +697,7 @@ static void tcg_out_ldst(TCGContext *s, MIPSInsn opc, 
TCGReg data,
 if (ofs != lo) {
 tcg_out_movi(s, TCG_TYPE_PTR, TCG_TMP0, ofs - lo);
 if (addr != TCG_REG_ZERO) {
-tcg_out_opc_reg(s, OPC_ADDU, TCG_TMP0, TCG_TMP0, addr);
+tcg_out_opc_reg(s, ALIAS_PADD, TCG_TMP0, TCG_TMP0, addr);
 }
 addr = TCG_TMP0;
 }
@@ -707,13 +707,21 @@ static void tcg_out_ldst(TCGContext *s, MIPSInsn opc, 
TCGReg data,
 static inline void tcg_out_ld(TCGContext *s, TCGType type, TCGReg arg,
   TCGReg arg1, intptr_t arg2)
 {
-tcg_out_ldst(s, OPC_LW, arg, arg1, arg2);
+MIPSInsn opc = OPC_LD;
+if (TCG_TARGET_REG_BITS == 32 || type == TCG_TYPE_I32) {
+opc = OPC_LW;
+}
+tcg_out_ldst(s, opc, arg, arg1, arg2);
 }
 
 static inline void tcg_out_st(TCGContext *s, TCGType type, TCGReg arg,
   TCGReg arg1, intptr_t arg2)
 {
-tcg_out_ldst(s, OPC_SW, arg, arg1, arg2);
+MIPSInsn opc = OPC_SD;
+if (TCG_TARGET_REG_BITS == 32 || type == TCG_TYPE_I32) {
+opc = OPC_SW;
+}
+tcg_out_ldst(s, opc, arg, arg1, arg2);
 }
 
 static inline bool tcg_out_sti(TCGContext *s, TCGType type, TCGArg val,
-- 
2.1.0

[Qemu-devel] [PATCH v5 03/10] tcg-mips: Support 64-bit opcodes

[Jin Guojie]

Bulk patch adding 64-bit opcodes into tcg_out_op.  Note that
mips64 is as yet neither complete nor enabled.

Cc: Aurelien Jarno 
Cc: James Hogan 
Signed-off-by: Richard Henderson 
Signed-off-by: Jin Guojie 
---
 tcg/mips/tcg-target.h |  41 ++
 tcg/mips/tcg-target.inc.c | 322 --
 2 files changed, 353 insertions(+), 10 deletions(-)

diff --git a/tcg/mips/tcg-target.h b/tcg/mips/tcg-target.h
index a6871fb..4b7d3ae 100644
--- a/tcg/mips/tcg-target.h
+++ b/tcg/mips/tcg-target.h
@@ -27,6 +27,7 @@
 #ifndef MIPS_TCG_TARGET_H
 #define MIPS_TCG_TARGET_H
 
+#define TCG_TARGET_REG_BITS 32
 #define TCG_TARGET_INSN_UNIT_SIZE 4
 #define TCG_TARGET_TLB_DISPLACEMENT_BITS 16
 #define TCG_TARGET_NB_REGS 32
@@ -119,6 +120,29 @@ extern bool use_mips32r2_instructions;
 #define TCG_TARGET_HAS_mulsh_i321
 #define TCG_TARGET_HAS_bswap32_i32  1
 
+#if TCG_TARGET_REG_BITS == 64
+#define TCG_TARGET_HAS_add2_i32 0
+#define TCG_TARGET_HAS_sub2_i32 0
+#define TCG_TARGET_HAS_extrl_i64_i321
+#define TCG_TARGET_HAS_extrh_i64_i321
+#define TCG_TARGET_HAS_div_i64  1
+#define TCG_TARGET_HAS_rem_i64  1
+#define TCG_TARGET_HAS_not_i64  1
+#define TCG_TARGET_HAS_nor_i64  1
+#define TCG_TARGET_HAS_andc_i64 0
+#define TCG_TARGET_HAS_orc_i64  0
+#define TCG_TARGET_HAS_eqv_i64  0
+#define TCG_TARGET_HAS_nand_i64 0
+#define TCG_TARGET_HAS_add2_i64 0
+#define TCG_TARGET_HAS_sub2_i64 0
+#define TCG_TARGET_HAS_mulu2_i64(!use_mips32r6_instructions)
+#define TCG_TARGET_HAS_muls2_i64(!use_mips32r6_instructions)
+#define TCG_TARGET_HAS_muluh_i641
+#define TCG_TARGET_HAS_mulsh_i641
+#define TCG_TARGET_HAS_ext32s_i64   1
+#define TCG_TARGET_HAS_ext32u_i64   1
+#endif
+
 /* optional instructions detected at runtime */
 #define TCG_TARGET_HAS_movcond_i32  use_movnz_instructions
 #define TCG_TARGET_HAS_bswap16_i32  use_mips32r2_instructions
@@ -127,11 +151,28 @@ extern bool use_mips32r2_instructions;
 #define TCG_TARGET_HAS_ext16s_i32   use_mips32r2_instructions
 #define TCG_TARGET_HAS_rot_i32  use_mips32r2_instructions
 
+#if TCG_TARGET_REG_BITS == 64
+#define TCG_TARGET_HAS_movcond_i64  use_movnz_instructions
+#define TCG_TARGET_HAS_bswap16_i64  use_mips32r2_instructions
+#define TCG_TARGET_HAS_bswap32_i64  use_mips32r2_instructions
+#define TCG_TARGET_HAS_bswap64_i64  use_mips32r2_instructions
+#define TCG_TARGET_HAS_deposit_i64  use_mips32r2_instructions
+#define TCG_TARGET_HAS_ext8s_i64use_mips32r2_instructions
+#define TCG_TARGET_HAS_ext16s_i64   use_mips32r2_instructions
+#define TCG_TARGET_HAS_rot_i64  use_mips32r2_instructions
+#endif
+
 /* optional instructions automatically implemented */
 #define TCG_TARGET_HAS_neg_i32  0 /* sub  rd, zero, rt   */
 #define TCG_TARGET_HAS_ext8u_i320 /* andi rt, rs, 0xff   */
 #define TCG_TARGET_HAS_ext16u_i32   0 /* andi rt, rs, 0x */
 
+#if TCG_TARGET_REG_BITS == 64
+#define TCG_TARGET_HAS_neg_i64  0 /* sub  rd, zero, rt   */
+#define TCG_TARGET_HAS_ext8u_i640 /* andi rt, rs, 0xff   */
+#define TCG_TARGET_HAS_ext16u_i64   0 /* andi rt, rs, 0x */
+#endif
+
 #ifdef __OpenBSD__
 #include 
 #else
diff --git a/tcg/mips/tcg-target.inc.c b/tcg/mips/tcg-target.inc.c
index fb84ea5..2d91d0c 100644
--- a/tcg/mips/tcg-target.inc.c
+++ b/tcg/mips/tcg-target.inc.c
@@ -437,6 +437,21 @@ static inline void tcg_out_opc_bf(TCGContext *s, MIPSInsn 
opc, TCGReg rt,
 tcg_out32(s, inst);
 }
 
+static inline void tcg_out_opc_bf64(TCGContext *s, MIPSInsn opc, MIPSInsn opm,
+MIPSInsn oph, TCGReg rt, TCGReg rs,
+int msb, int lsb)
+{
+if (lsb >= 32) {
+opc = oph;
+msb -= 32;
+lsb -= 32;
+} else if (msb >= 32) {
+opc = opm;
+msb -= 32;
+}
+tcg_out_opc_bf(s, opc, rt, rs, msb, lsb);
+}
+
 /*
  * Type branch
  */
@@ -467,6 +482,18 @@ static inline void tcg_out_opc_sa(TCGContext *s, MIPSInsn 
opc,
 
 }
 
+static void tcg_out_opc_sa64(TCGContext *s, MIPSInsn opc1, MIPSInsn opc2,
+ TCGReg rd, TCGReg rt, TCGArg sa)
+{
+int32_t inst;
+
+inst = (sa & 32 ? opc2 : opc1);
+inst |= (rt & 0x1F) << 16;
+inst |= (rd & 0x1F) << 11;
+inst |= (sa & 0x1F) <<  6;
+tcg_out32(s, inst);
+}
+
 /*
  * Type jump.
  * Returns true if the branch was in range and the insn was emitted.
@@ -495,6 +522,21 @@ static inline void tcg_out_nop(TCGContext *s)
 tcg_out32(s, 0);
 }
 
+static inline void tcg_out_dsll(TCGContext *s, TCGReg rd, TCGReg rt, TCGArg sa)
+{
+tcg_out_opc_sa64(s, OPC_DSLL, OPC_DSLL32, rd, rt, sa);
+}
+
+static inline void tcg_out_dsrl(TCGContext *s, TCGReg rd, TCGReg rt, TCGArg sa)
+{
+tcg_out_opc_sa64(s, OPC_DSRL, OPC_DSRL32, rd, rt, sa);
+}
+
+static inline 

[Qemu-devel] [PATCH v5 04/10] tcg-mips: Add bswap32u and bswap64

[Jin Guojie]

Without the mips32r2 instructions to perform swapping, bswap is quite large,
dominating the size of each reverse-endian qemu_ld/qemu_st operation.

Create two subroutines in the prologue block.  The subroutines require extra
reserved registers (TCG_TMP[2, 3]).  Using these within qemu_ld means that
we need not place additional restrictions on the qemu_ld outputs.

Cc: Aurelien Jarno 
Cc: James Hogan 
Signed-off-by: Richard Henderson 
Signed-off-by: Jin Guojie 
---
 tcg/mips/tcg-target.inc.c | 102 --
 1 file changed, 99 insertions(+), 3 deletions(-)

diff --git a/tcg/mips/tcg-target.inc.c b/tcg/mips/tcg-target.inc.c
index 2d91d0c..ec139cd 100644
--- a/tcg/mips/tcg-target.inc.c
+++ b/tcg/mips/tcg-target.inc.c
@@ -125,6 +125,8 @@ static const TCGReg tcg_target_call_oarg_regs[2] = {
 
 static tcg_insn_unit *tb_ret_addr;
 static tcg_insn_unit *bswap32_addr;
+static tcg_insn_unit *bswap32u_addr;
+static tcg_insn_unit *bswap64_addr;
 
 static inline uint32_t reloc_pc16_val(tcg_insn_unit *pc, tcg_insn_unit *target)
 {
@@ -622,7 +624,10 @@ static void tcg_out_bswap32u(TCGContext *s, TCGReg ret, 
TCGReg arg)
 tcg_out_opc_reg(s, OPC_DSHD, ret, 0, ret);
 tcg_out_dsrl(s, ret, ret, 32);
 } else {
-abort();
+tcg_out_bswap_subr(s, bswap32u_addr);
+/* delay slot -- never omit the insn, like tcg_out_mov might.  */
+tcg_out_opc_reg(s, OPC_OR, TCG_TMP0, arg, TCG_REG_ZERO);
+tcg_out_mov(s, TCG_TYPE_I32, ret, TCG_TMP3);
 }
 }
 
@@ -632,7 +637,10 @@ static void tcg_out_bswap64(TCGContext *s, TCGReg ret, 
TCGReg arg)
 tcg_out_opc_reg(s, OPC_DSBH, ret, 0, arg);
 tcg_out_opc_reg(s, OPC_DSHD, ret, 0, ret);
 } else {
-abort();
+tcg_out_bswap_subr(s, bswap64_addr);
+/* delay slot -- never omit the insn, like tcg_out_mov might.  */
+tcg_out_opc_reg(s, OPC_OR, TCG_TMP0, arg, TCG_REG_ZERO);
+tcg_out_mov(s, TCG_TYPE_I32, ret, TCG_TMP3);
 }
 }
 
@@ -2279,7 +2287,7 @@ static void tcg_target_qemu_prologue(TCGContext *s)
 return;
 }
 
-/* Bswap subroutine: Input in TCG_TMP0, output in TCG_TMP3;
+/* Bswap subroutines: Input in TCG_TMP0, output in TCG_TMP3;
clobbers TCG_TMP1, TCG_TMP2.  */
 
 /*
@@ -2305,6 +2313,94 @@ static void tcg_target_qemu_prologue(TCGContext *s)
 tcg_out_opc_reg(s, OPC_JR, 0, TCG_REG_RA, 0);
 /* t3 = dcba -- delay slot */
 tcg_out_opc_reg(s, OPC_OR, TCG_TMP3, TCG_TMP3, TCG_TMP1);
+
+if (TCG_TARGET_REG_BITS == 32) {
+return;
+}
+
+/*
+ * bswap32u -- unsigned 32-bit swap.  a0 = abcd.
+ */
+bswap32u_addr = align_code_ptr(s);
+/* t1 = ()000d */
+tcg_out_opc_imm(s, OPC_ANDI, TCG_TMP1, TCG_TMP0, 0xff);
+/* t3 = 000a */
+tcg_out_opc_sa(s, OPC_SRL, TCG_TMP3, TCG_TMP0, 24);
+/* t1 = ()d000 */
+tcg_out_dsll(s, TCG_TMP1, TCG_TMP1, 24);
+/* t2 = 00c0 */
+tcg_out_opc_imm(s, OPC_ANDI, TCG_TMP2, TCG_TMP0, 0xff00);
+/* t3 = d00a */
+tcg_out_opc_reg(s, OPC_OR, TCG_TMP3, TCG_TMP3, TCG_TMP1);
+/* t1 = 0abc */
+tcg_out_opc_sa(s, OPC_SRL, TCG_TMP1, TCG_TMP0, 8);
+/* t2 = 0c00 */
+tcg_out_opc_sa(s, OPC_SLL, TCG_TMP2, TCG_TMP2, 8);
+/* t1 = 00b0 */
+tcg_out_opc_imm(s, OPC_ANDI, TCG_TMP1, TCG_TMP1, 0xff00);
+/* t3 = dc0a */
+tcg_out_opc_reg(s, OPC_OR, TCG_TMP3, TCG_TMP3, TCG_TMP2);
+tcg_out_opc_reg(s, OPC_JR, 0, TCG_REG_RA, 0);
+/* t3 = dcba -- delay slot */
+tcg_out_opc_reg(s, OPC_OR, TCG_TMP3, TCG_TMP3, TCG_TMP1);
+
+/*
+ * bswap64 -- 64-bit swap.  a0 = abcdefgh
+ */
+bswap64_addr = align_code_ptr(s);
+/* t3 = h000 */
+tcg_out_dsll(s, TCG_TMP3, TCG_TMP0, 56);
+/* t1 = 000a */
+tcg_out_dsrl(s, TCG_TMP1, TCG_TMP0, 56);
+
+/* t2 = 00g0 */
+tcg_out_opc_imm(s, OPC_ANDI, TCG_TMP2, TCG_TMP0, 0xff00);
+/* t3 = h00a */
+tcg_out_opc_reg(s, OPC_OR, TCG_TMP3, TCG_TMP3, TCG_TMP1);
+/* t1 = 0abc */
+tcg_out_dsrl(s, TCG_TMP1, TCG_TMP0, 40);
+/* t2 = 0g00 */
+tcg_out_dsll(s, TCG_TMP2, TCG_TMP2, 40);
+/* t1 = 00b0 */
+tcg_out_opc_imm(s, OPC_ANDI, TCG_TMP1, TCG_TMP1, 0xff00);
+
+/* t3 = hg0a */
+tcg_out_opc_reg(s, OPC_OR, TCG_TMP3, TCG_TMP3, TCG_TMP2);
+/* t2 = abcd */
+tcg_out_dsrl(s, TCG_TMP2, TCG_TMP0, 32);
+/* t3 = hgba */
+tcg_out_opc_reg(s, OPC_OR, TCG_TMP3, TCG_TMP3, TCG_TMP1);
+
+/* t1 = 00c0 */
+tcg_out_opc_imm(s, OPC_ANDI, TCG_TMP1, TCG_TMP2, 0xff00);
+/* t2 = 000d */
+tcg_out_opc_imm(s, OPC_ANDI, TCG_TMP2, TCG_TMP2, 0x00ff);
+/* t1 = 0c00 */
+tcg_out_dsll(s, TCG_TMP1, TCG_TMP1, 8);
+/* t2 = d000 */
+tcg_out_dsll(s, TCG_TMP2, TCG_TMP2, 24);
+
+/* t3 = hg000cba */
+tcg_out_opc_reg(s, OPC_OR, TCG_TMP3, TCG_TMP3, TCG_TMP1);
+/* t1 = 00abcdef */
+tcg_out_dsrl(s, TCG_TMP1, TCG_TMP0, 16);
+/* t3 = hg00dcba */
+tcg_

[Qemu-devel] [PATCH v5 07/10] tcg-mips: Adjust prologue for mips64

[Jin Guojie]

Take stack frame parameters out from the function body.

Cc: Aurelien Jarno 
Cc: James Hogan 
Signed-off-by: Richard Henderson 
Signed-off-by: Jin Guojie 
---
 tcg/mips/tcg-target.inc.c | 54 ++-
 1 file changed, 25 insertions(+), 29 deletions(-)

diff --git a/tcg/mips/tcg-target.inc.c b/tcg/mips/tcg-target.inc.c
index 5cc8df3..9e24662 100644
--- a/tcg/mips/tcg-target.inc.c
+++ b/tcg/mips/tcg-target.inc.c
@@ -734,16 +734,6 @@ static inline bool tcg_out_sti(TCGContext *s, TCGType 
type, TCGArg val,
 return false;
 }
 
-static inline void tcg_out_addi(TCGContext *s, TCGReg reg, TCGArg val)
-{
-if (val == (int16_t)val) {
-tcg_out_opc_imm(s, OPC_ADDIU, reg, reg, val);
-} else {
-tcg_out_movi(s, TCG_TYPE_PTR, TCG_TMP0, val);
-tcg_out_opc_reg(s, OPC_ADDU, reg, reg, TCG_TMP0);
-}
-}
-
 static void tcg_out_addsub2(TCGContext *s, TCGReg rl, TCGReg rh, TCGReg al,
 TCGReg ah, TCGArg bl, TCGArg bh, bool cbl,
 bool cbh, bool is_sub)
@@ -2270,42 +2260,48 @@ static tcg_insn_unit *align_code_ptr(TCGContext *s)
 return s->code_ptr;
 }
 
+/* Stack frame parameters.  */
+#define REG_SIZE   (TCG_TARGET_REG_BITS / 8)
+#define SAVE_SIZE  ((int)ARRAY_SIZE(tcg_target_callee_save_regs) * REG_SIZE)
+#define TEMP_SIZE  (CPU_TEMP_BUF_NLONGS * (int)sizeof(long))
+
+#define FRAME_SIZE ((TCG_STATIC_CALL_ARGS_SIZE + TEMP_SIZE + SAVE_SIZE \
+ + TCG_TARGET_STACK_ALIGN - 1) \
+& -TCG_TARGET_STACK_ALIGN)
+#define SAVE_OFS   (TCG_STATIC_CALL_ARGS_SIZE + TEMP_SIZE)
+
+/* We're expecting to be able to use an immediate for frame allocation.  */
+QEMU_BUILD_BUG_ON(FRAME_SIZE > 0x7fff);
+
 /* Generate global QEMU prologue and epilogue code */
 static void tcg_target_qemu_prologue(TCGContext *s)
 {
-int i, frame_size;
+int i;
 
-/* reserve some stack space, also for TCG temps. */
-frame_size = ARRAY_SIZE(tcg_target_callee_save_regs) * 4
- + TCG_STATIC_CALL_ARGS_SIZE
- + CPU_TEMP_BUF_NLONGS * sizeof(long);
-frame_size = (frame_size + TCG_TARGET_STACK_ALIGN - 1) &
- ~(TCG_TARGET_STACK_ALIGN - 1);
-tcg_set_frame(s, TCG_REG_SP, ARRAY_SIZE(tcg_target_callee_save_regs) * 4
-  + TCG_STATIC_CALL_ARGS_SIZE,
-  CPU_TEMP_BUF_NLONGS * sizeof(long));
+tcg_set_frame(s, TCG_REG_SP, TCG_STATIC_CALL_ARGS_SIZE, TEMP_SIZE);
 
 /* TB prologue */
-tcg_out_addi(s, TCG_REG_SP, -frame_size);
-for(i = 0 ; i < ARRAY_SIZE(tcg_target_callee_save_regs) ; i++) {
-tcg_out_st(s, TCG_TYPE_I32, tcg_target_callee_save_regs[i],
-   TCG_REG_SP, TCG_STATIC_CALL_ARGS_SIZE + i * 4);
+tcg_out_opc_imm(s, ALIAS_PADDI, TCG_REG_SP, TCG_REG_SP, -FRAME_SIZE);
+for (i = 0; i < ARRAY_SIZE(tcg_target_callee_save_regs); i++) {
+tcg_out_st(s, TCG_TYPE_REG, tcg_target_callee_save_regs[i],
+   TCG_REG_SP, SAVE_OFS + i * REG_SIZE);
 }
 
 /* Call generated code */
 tcg_out_opc_reg(s, OPC_JR, 0, tcg_target_call_iarg_regs[1], 0);
+/* delay slot */
 tcg_out_mov(s, TCG_TYPE_PTR, TCG_AREG0, tcg_target_call_iarg_regs[0]);
-tb_ret_addr = s->code_ptr;
 
 /* TB epilogue */
-for(i = 0 ; i < ARRAY_SIZE(tcg_target_callee_save_regs) ; i++) {
-tcg_out_ld(s, TCG_TYPE_I32, tcg_target_callee_save_regs[i],
-   TCG_REG_SP, TCG_STATIC_CALL_ARGS_SIZE + i * 4);
+tb_ret_addr = s->code_ptr;
+for (i = 0; i < ARRAY_SIZE(tcg_target_callee_save_regs); i++) {
+tcg_out_ld(s, TCG_TYPE_REG, tcg_target_callee_save_regs[i],
+   TCG_REG_SP, SAVE_OFS + i * REG_SIZE);
 }
 
 tcg_out_opc_reg(s, OPC_JR, 0, TCG_REG_RA, 0);
 /* delay slot */
-tcg_out_addi(s, TCG_REG_SP, frame_size);
+tcg_out_opc_imm(s, ALIAS_PADDI, TCG_REG_SP, TCG_REG_SP, FRAME_SIZE);
 
 if (use_mips32r2_instructions) {
 return;
-- 
2.1.0

[Qemu-devel] [PATCH v5 02/10] tcg-mips: Add mips64 opcodes

[Jin Guojie]

Since the mips manual tables are in octal, reorg all of the opcodes
into that format for clarity.  Note that the 64-bit opcodes are as
yet unused.

Cc: Aurelien Jarno 
Cc: James Hogan 
Signed-off-by: Richard Henderson 
Signed-off-by: Jin Guojie 
---
 tcg/mips/tcg-target.inc.c | 193 --
 1 file changed, 118 insertions(+), 75 deletions(-)

diff --git a/tcg/mips/tcg-target.inc.c b/tcg/mips/tcg-target.inc.c
index 2b116ea..fb84ea5 100644
--- a/tcg/mips/tcg-target.inc.c
+++ b/tcg/mips/tcg-target.inc.c
@@ -254,81 +254,118 @@ static inline int tcg_target_const_match(tcg_target_long 
val, TCGType type,
 
 /* instruction opcodes */
 typedef enum {
-OPC_J= 0x02 << 26,
-OPC_JAL  = 0x03 << 26,
-OPC_BEQ  = 0x04 << 26,
-OPC_BNE  = 0x05 << 26,
-OPC_BLEZ = 0x06 << 26,
-OPC_BGTZ = 0x07 << 26,
-OPC_ADDIU= 0x09 << 26,
-OPC_SLTI = 0x0A << 26,
-OPC_SLTIU= 0x0B << 26,
-OPC_ANDI = 0x0C << 26,
-OPC_ORI  = 0x0D << 26,
-OPC_XORI = 0x0E << 26,
-OPC_LUI  = 0x0F << 26,
-OPC_LB   = 0x20 << 26,
-OPC_LH   = 0x21 << 26,
-OPC_LW   = 0x23 << 26,
-OPC_LBU  = 0x24 << 26,
-OPC_LHU  = 0x25 << 26,
-OPC_LWU  = 0x27 << 26,
-OPC_SB   = 0x28 << 26,
-OPC_SH   = 0x29 << 26,
-OPC_SW   = 0x2B << 26,
-
-OPC_SPECIAL  = 0x00 << 26,
-OPC_SLL  = OPC_SPECIAL | 0x00,
-OPC_SRL  = OPC_SPECIAL | 0x02,
-OPC_ROTR = OPC_SPECIAL | (0x01 << 21) | 0x02,
-OPC_SRA  = OPC_SPECIAL | 0x03,
-OPC_SLLV = OPC_SPECIAL | 0x04,
-OPC_SRLV = OPC_SPECIAL | 0x06,
-OPC_ROTRV= OPC_SPECIAL | (0x01 <<  6) | 0x06,
-OPC_SRAV = OPC_SPECIAL | 0x07,
-OPC_JR_R5= OPC_SPECIAL | 0x08,
-OPC_JALR = OPC_SPECIAL | 0x09,
-OPC_MOVZ = OPC_SPECIAL | 0x0A,
-OPC_MOVN = OPC_SPECIAL | 0x0B,
-OPC_SYNC = OPC_SPECIAL | 0x0F,
-OPC_MFHI = OPC_SPECIAL | 0x10,
-OPC_MFLO = OPC_SPECIAL | 0x12,
-OPC_MULT = OPC_SPECIAL | 0x18,
-OPC_MUL_R6   = OPC_SPECIAL | (0x02 <<  6) | 0x18,
-OPC_MUH  = OPC_SPECIAL | (0x03 <<  6) | 0x18,
-OPC_MULTU= OPC_SPECIAL | 0x19,
-OPC_MULU = OPC_SPECIAL | (0x02 <<  6) | 0x19,
-OPC_MUHU = OPC_SPECIAL | (0x03 <<  6) | 0x19,
-OPC_DIV  = OPC_SPECIAL | 0x1A,
-OPC_DIV_R6   = OPC_SPECIAL | (0x02 <<  6) | 0x1A,
-OPC_MOD  = OPC_SPECIAL | (0x03 <<  6) | 0x1A,
-OPC_DIVU = OPC_SPECIAL | 0x1B,
-OPC_DIVU_R6  = OPC_SPECIAL | (0x02 <<  6) | 0x1B,
-OPC_MODU = OPC_SPECIAL | (0x03 <<  6) | 0x1B,
-OPC_ADDU = OPC_SPECIAL | 0x21,
-OPC_SUBU = OPC_SPECIAL | 0x23,
-OPC_AND  = OPC_SPECIAL | 0x24,
-OPC_OR   = OPC_SPECIAL | 0x25,
-OPC_XOR  = OPC_SPECIAL | 0x26,
-OPC_NOR  = OPC_SPECIAL | 0x27,
-OPC_SLT  = OPC_SPECIAL | 0x2A,
-OPC_SLTU = OPC_SPECIAL | 0x2B,
-OPC_SELEQZ   = OPC_SPECIAL | 0x35,
-OPC_SELNEZ   = OPC_SPECIAL | 0x37,
-
-OPC_REGIMM   = 0x01 << 26,
-OPC_BLTZ = OPC_REGIMM | (0x00 << 16),
-OPC_BGEZ = OPC_REGIMM | (0x01 << 16),
-
-OPC_SPECIAL2 = 0x1c << 26,
-OPC_MUL_R5   = OPC_SPECIAL2 | 0x002,
-
-OPC_SPECIAL3 = 0x1f << 26,
-OPC_EXT  = OPC_SPECIAL3 | 0x000,
-OPC_INS  = OPC_SPECIAL3 | 0x004,
-OPC_WSBH = OPC_SPECIAL3 | 0x0a0,
-OPC_SEB  = OPC_SPECIAL3 | 0x420,
-OPC_SEH  = OPC_SPECIAL3 | 0x620,
+OPC_J= 002 << 26,
+OPC_JAL  = 003 << 26,
+OPC_BEQ  = 004 << 26,
+OPC_BNE  = 005 << 26,
+OPC_BLEZ = 006 << 26,
+OPC_BGTZ = 007 << 26,
+OPC_ADDIU= 011 << 26,
+OPC_SLTI = 012 << 26,
+OPC_SLTIU= 013 << 26,
+OPC_ANDI = 014 << 26,
+OPC_ORI  = 015 << 26,
+OPC_XORI = 016 << 26,
+OPC_LUI  = 017 << 26,
+OPC_DADDIU   = 031 << 26,
+OPC_LB   = 040 << 26,
+OPC_LH   = 041 << 26,
+OPC_LW   = 043 << 26,
+OPC_LBU  = 044 << 26,
+OPC_LHU  = 045 << 26,
+OPC_LWU  = 047 << 26,
+OPC_SB   = 050 << 26,
+OPC_SH   = 051 << 26,
+OPC_SW   = 053 << 26,
+OPC_LD   = 067 << 26,
+OPC_SD   = 077 << 26,
+
+OPC_SPECIAL  = 000 << 26,
+OPC_SLL  = OPC_SPECIAL | 000,
+OPC_SRL  = OPC_SPECIAL | 002,
+OPC_ROTR = OPC_SPECIAL | 002 | (1 << 21),
+OPC_SRA  = OPC_SPECIAL | 003,
+OPC_SLLV = OPC_SPECIAL | 004,
+OPC_SRLV = OPC_SPECIAL | 006,
+OPC_ROTRV= OPC_SPECIAL | 006 | 0100,
+OPC_SRAV = OPC_SPECIAL | 007,
+OPC_JR_R5= OPC_SPECIAL | 010,
+OPC_JALR = OPC_SPECIAL | 011,
+OPC_MOVZ = OPC_SPECIAL | 012,
+OPC_MOVN = OPC_SPECIAL | 013,
+OPC_SYNC = OPC_SPECIAL | 017,
+OPC_MFHI = OPC_SPECIAL | 020,
+OPC_MFLO = OPC_SPECIAL | 022,
+OPC_DSLLV= OPC_SPECIAL | 024,
+OPC_DSRLV= OPC_SPECIAL | 026,
+   

[Qemu-devel] [PATCH v5 08/10] tcg-mips: Add tcg unwind info

[Jin Guojie]

Cc: Aurelien Jarno 
Cc: James Hogan 
Signed-off-by: Richard Henderson 
Signed-off-by: Jin Guojie 
---
 tcg/mips/tcg-target.inc.c | 44 
 1 file changed, 44 insertions(+)

diff --git a/tcg/mips/tcg-target.inc.c b/tcg/mips/tcg-target.inc.c
index 9e24662..b7e2586 100644
--- a/tcg/mips/tcg-target.inc.c
+++ b/tcg/mips/tcg-target.inc.c
@@ -2465,3 +2465,47 @@ void tb_set_jmp_target1(uintptr_t jmp_addr, uintptr_t 
addr)
 atomic_set((uint32_t *)jmp_addr, deposit32(OPC_J, 0, 26, addr >> 2));
 flush_icache_range(jmp_addr, jmp_addr + 4);
 }
+
+typedef struct {
+DebugFrameHeader h;
+uint8_t fde_def_cfa[4];
+uint8_t fde_reg_ofs[ARRAY_SIZE(tcg_target_callee_save_regs) * 2];
+} DebugFrame;
+
+#define ELF_HOST_MACHINE EM_MIPS
+/* GDB doesn't appear to require proper setting of ELF_HOST_FLAGS,
+   which is good because they're really quite complicated for MIPS.  */
+
+static const DebugFrame debug_frame = {
+.h.cie.len = sizeof(DebugFrameCIE) - 4, /* length after .len member */
+.h.cie.id = -1,
+.h.cie.version = 1,
+.h.cie.code_align = 1,
+.h.cie.data_align = -(TCG_TARGET_REG_BITS / 8) & 0x7f, /* sleb128 */
+.h.cie.return_column = TCG_REG_RA,
+
+/* Total FDE size does not include the "len" member.  */
+.h.fde.len = sizeof(DebugFrame) - offsetof(DebugFrame, h.fde.cie_offset),
+
+.fde_def_cfa = {
+12, TCG_REG_SP, /* DW_CFA_def_cfa sp, ... */
+(FRAME_SIZE & 0x7f) | 0x80, /* ... uleb128 FRAME_SIZE */
+(FRAME_SIZE >> 7)
+},
+.fde_reg_ofs = {
+0x80 + 16, 9,   /* DW_CFA_offset, s0, -72 */
+0x80 + 17, 8,   /* DW_CFA_offset, s2, -64 */
+0x80 + 18, 7,   /* DW_CFA_offset, s3, -56 */
+0x80 + 19, 6,   /* DW_CFA_offset, s4, -48 */
+0x80 + 20, 5,   /* DW_CFA_offset, s5, -40 */
+0x80 + 21, 4,   /* DW_CFA_offset, s6, -32 */
+0x80 + 22, 3,   /* DW_CFA_offset, s7, -24 */
+0x80 + 30, 2,   /* DW_CFA_offset, s8, -16 */
+0x80 + 31, 1,   /* DW_CFA_offset, ra,  -8 */
+}
+};
+
+void tcg_register_jit(void *buf, size_t buf_size)
+{
+tcg_register_jit_int(buf, buf_size, &debug_frame, sizeof(debug_frame));
+}
-- 
2.1.0

[Qemu-devel] [PATCH v5 09/10] tcg-mips: Adjust calling conventions for mips64

[Jin Guojie]

Cc: Aurelien Jarno 
Cc: James Hogan 
Signed-off-by: Richard Henderson 
Signed-off-by: Jin Guojie 
---
 tcg/mips/tcg-target.h | 19 +++
 tcg/mips/tcg-target.inc.c | 21 +++--
 2 files changed, 30 insertions(+), 10 deletions(-)

diff --git a/tcg/mips/tcg-target.h b/tcg/mips/tcg-target.h
index 4b7d3ae..d352c97 100644
--- a/tcg/mips/tcg-target.h
+++ b/tcg/mips/tcg-target.h
@@ -27,7 +27,14 @@
 #ifndef MIPS_TCG_TARGET_H
 #define MIPS_TCG_TARGET_H
 
-#define TCG_TARGET_REG_BITS 32
+#if _MIPS_SIM == _ABIO32
+# define TCG_TARGET_REG_BITS 32
+#elif _MIPS_SIM == _ABIN32 || _MIPS_SIM == _ABI64
+# define TCG_TARGET_REG_BITS 64
+#else
+# error "Unknown ABI"
+#endif
+
 #define TCG_TARGET_INSN_UNIT_SIZE 4
 #define TCG_TARGET_TLB_DISPLACEMENT_BITS 16
 #define TCG_TARGET_NB_REGS 32
@@ -71,9 +78,13 @@ typedef enum {
 } TCGReg;
 
 /* used for function call generation */
-#define TCG_TARGET_STACK_ALIGN 8
-#define TCG_TARGET_CALL_STACK_OFFSET 16
-#define TCG_TARGET_CALL_ALIGN_ARGS 1
+#define TCG_TARGET_STACK_ALIGN16
+#if _MIPS_SIM == _ABIO32
+# define TCG_TARGET_CALL_STACK_OFFSET 16
+#else
+# define TCG_TARGET_CALL_STACK_OFFSET 0
+#endif
+#define TCG_TARGET_CALL_ALIGN_ARGS1
 
 /* MOVN/MOVZ instructions detection */
 #if (defined(__mips_isa_rev) && (__mips_isa_rev >= 1)) || \
diff --git a/tcg/mips/tcg-target.inc.c b/tcg/mips/tcg-target.inc.c
index b7e2586..7282a4a 100644
--- a/tcg/mips/tcg-target.inc.c
+++ b/tcg/mips/tcg-target.inc.c
@@ -91,10 +91,6 @@ static const int tcg_target_reg_alloc_order[] = {
 TCG_REG_S8,
 
 /* Call clobbered registers.  */
-TCG_REG_T0,
-TCG_REG_T1,
-TCG_REG_T2,
-TCG_REG_T3,
 TCG_REG_T4,
 TCG_REG_T5,
 TCG_REG_T6,
@@ -105,17 +101,27 @@ static const int tcg_target_reg_alloc_order[] = {
 TCG_REG_V0,
 
 /* Argument registers, opposite order of allocation.  */
+TCG_REG_T3,
+TCG_REG_T2,
+TCG_REG_T1,
+TCG_REG_T0,
 TCG_REG_A3,
 TCG_REG_A2,
 TCG_REG_A1,
 TCG_REG_A0,
 };
 
-static const TCGReg tcg_target_call_iarg_regs[4] = {
+static const TCGReg tcg_target_call_iarg_regs[] = {
 TCG_REG_A0,
 TCG_REG_A1,
 TCG_REG_A2,
-TCG_REG_A3
+TCG_REG_A3,
+#if _MIPS_SIM == _ABIN32 || _MIPS_SIM == _ABI64
+TCG_REG_T0,
+TCG_REG_T1,
+TCG_REG_T2,
+TCG_REG_T3,
+#endif
 };
 
 static const TCGReg tcg_target_call_oarg_regs[2] = {
@@ -2427,6 +2433,9 @@ static void tcg_target_init(TCGContext *s)
 {
 tcg_target_detect_isa();
 tcg_regset_set(tcg_target_available_regs[TCG_TYPE_I32], 0x);
+if (TCG_TARGET_REG_BITS == 64) {
+tcg_regset_set(tcg_target_available_regs[TCG_TYPE_I64], 0x);
+}
 tcg_regset_set(tcg_target_call_clobber_regs,
(1 << TCG_REG_V0) |
(1 << TCG_REG_V1) |
-- 
2.1.0

[Qemu-devel] [PATCH v5 01/10] tcg-mips: Move bswap code to a subroutine

[Jin Guojie]

Without the mips32r2 instructions to perform swapping, bswap is quite large,
dominating the size of each reverse-endian qemu_ld/qemu_st operation.

Create a subroutine in the prologue block.  The subroutine requires extra
reserved registers (TCG_TMP[2, 3]).  Using these within qemu_ld means that
we need not place additional restrictions on the qemu_ld outputs.

Cc: Aurelien Jarno 
Cc: James Hogan 
Signed-off-by: Richard Henderson 
Signed-off-by: Jin Guojie 
---
 tcg/mips/tcg-target.h |   2 +-
 tcg/mips/tcg-target.inc.c | 207 ++
 2 files changed, 139 insertions(+), 70 deletions(-)

diff --git a/tcg/mips/tcg-target.h b/tcg/mips/tcg-target.h
index 3aeac87..a6871fb 100644
--- a/tcg/mips/tcg-target.h
+++ b/tcg/mips/tcg-target.h
@@ -117,11 +117,11 @@ extern bool use_mips32r2_instructions;
 #define TCG_TARGET_HAS_muls2_i32(!use_mips32r6_instructions)
 #define TCG_TARGET_HAS_muluh_i321
 #define TCG_TARGET_HAS_mulsh_i321
+#define TCG_TARGET_HAS_bswap32_i32  1
 
 /* optional instructions detected at runtime */
 #define TCG_TARGET_HAS_movcond_i32  use_movnz_instructions
 #define TCG_TARGET_HAS_bswap16_i32  use_mips32r2_instructions
-#define TCG_TARGET_HAS_bswap32_i32  use_mips32r2_instructions
 #define TCG_TARGET_HAS_deposit_i32  use_mips32r2_instructions
 #define TCG_TARGET_HAS_ext8s_i32use_mips32r2_instructions
 #define TCG_TARGET_HAS_ext16s_i32   use_mips32r2_instructions
diff --git a/tcg/mips/tcg-target.inc.c b/tcg/mips/tcg-target.inc.c
index abce602..2b116ea 100644
--- a/tcg/mips/tcg-target.inc.c
+++ b/tcg/mips/tcg-target.inc.c
@@ -74,6 +74,8 @@ static const char * const 
tcg_target_reg_names[TCG_TARGET_NB_REGS] = {
 
 #define TCG_TMP0  TCG_REG_AT
 #define TCG_TMP1  TCG_REG_T9
+#define TCG_TMP2  TCG_REG_T8
+#define TCG_TMP3  TCG_REG_T7
 
 /* check if we really need so many registers :P */
 static const int tcg_target_reg_alloc_order[] = {
@@ -122,6 +124,7 @@ static const TCGReg tcg_target_call_oarg_regs[2] = {
 };
 
 static tcg_insn_unit *tb_ret_addr;
+static tcg_insn_unit *bswap32_addr;
 
 static inline uint32_t reloc_pc16_val(tcg_insn_unit *pc, tcg_insn_unit *target)
 {
@@ -177,12 +180,7 @@ static int target_parse_constraint(TCGArgConstraint *ct, 
const char **pct_str)
 ct->ct |= TCG_CT_REG;
 tcg_regset_set(ct->u.regs, 0x);
 break;
-case 'L': /* qemu_ld output arg constraint */
-ct->ct |= TCG_CT_REG;
-tcg_regset_set(ct->u.regs, 0x);
-tcg_regset_reset_reg(ct->u.regs, TCG_REG_V0);
-break;
-case 'l': /* qemu_ld input arg constraint */
+case 'L': /* qemu_ld input arg constraint */
 ct->ct |= TCG_CT_REG;
 tcg_regset_set(ct->u.regs, 0x);
 tcg_regset_reset_reg(ct->u.regs, TCG_REG_A0);
@@ -513,29 +511,22 @@ static inline void tcg_out_bswap16s(TCGContext *s, TCGReg 
ret, TCGReg arg)
 }
 }
 
-static inline void tcg_out_bswap32(TCGContext *s, TCGReg ret, TCGReg arg)
+static void tcg_out_bswap_subr(TCGContext *s, tcg_insn_unit *sub)
+{
+bool ok = tcg_out_opc_jmp(s, OPC_JAL, sub);
+tcg_debug_assert(ok);
+}
+
+static void tcg_out_bswap32(TCGContext *s, TCGReg ret, TCGReg arg)
 {
 if (use_mips32r2_instructions) {
 tcg_out_opc_reg(s, OPC_WSBH, ret, 0, arg);
 tcg_out_opc_sa(s, OPC_ROTR, ret, ret, 16);
 } else {
-/* ret and arg must be different and can't be register at */
-if (ret == arg || ret == TCG_TMP0 || arg == TCG_TMP0) {
-tcg_abort();
-}
-
-tcg_out_opc_sa(s, OPC_SLL, ret, arg, 24);
-
-tcg_out_opc_sa(s, OPC_SRL, TCG_TMP0, arg, 24);
-tcg_out_opc_reg(s, OPC_OR, ret, ret, TCG_TMP0);
-
-tcg_out_opc_imm(s, OPC_ANDI, TCG_TMP0, arg, 0xff00);
-tcg_out_opc_sa(s, OPC_SLL, TCG_TMP0, TCG_TMP0, 8);
-tcg_out_opc_reg(s, OPC_OR, ret, ret, TCG_TMP0);
-
-tcg_out_opc_sa(s, OPC_SRL, TCG_TMP0, arg, 8);
-tcg_out_opc_imm(s, OPC_ANDI, TCG_TMP0, TCG_TMP0, 0xff00);
-tcg_out_opc_reg(s, OPC_OR, ret, ret, TCG_TMP0);
+tcg_out_bswap_subr(s, bswap32_addr);
+/* delay slot -- never omit the insn, like tcg_out_mov might.  */
+tcg_out_opc_reg(s, OPC_OR, TCG_TMP0, arg, TCG_REG_ZERO);
+tcg_out_mov(s, TCG_TYPE_I32, ret, TCG_TMP3);
 }
 }
 
@@ -1044,7 +1035,7 @@ static int tcg_out_call_iarg_reg2(TCGContext *s, int i, 
TCGReg al, TCGReg ah)
 }
 
 /* Perform the tlb comparison operation.  The complete host address is
-   placed in BASE.  Clobbers AT, T0, A0.  */
+   placed in BASE.  Clobbers TMP0, TMP1, A0.  */
 static void tcg_out_tlb_load(TCGContext *s, TCGReg base, TCGReg addrl,
  TCGReg addrh, TCGMemOpIdx oi,
  tcg_insn_unit *label_ptr[2], bool is_load)
@@ -1227,46 +1218,72 @@ static void tcg_out_qemu_st_slow_path(TCGContext *s, 
TCGLabelQemuLdst *l)
 }
 #endif
 
-static void tcg_out_qemu_ld_direct(TCGContext *s

[Qemu-devel] [PATCH v5 05/10] tcg-mips: Adjust move functions for mips64

[Jin Guojie]

tcg_out_mov: using OPC_OR as most mips assemblers do;
tcg_out_movi: extended to 64-bit immediate.

Cc: Aurelien Jarno 
Cc: James Hogan 
Signed-off-by: Richard Henderson 
Signed-off-by: Jin Guojie 
---
 tcg/mips/tcg-target.inc.c | 34 +-
 1 file changed, 25 insertions(+), 9 deletions(-)

diff --git a/tcg/mips/tcg-target.inc.c b/tcg/mips/tcg-target.inc.c
index ec139cd..18368f0 100644
--- a/tcg/mips/tcg-target.inc.c
+++ b/tcg/mips/tcg-target.inc.c
@@ -544,23 +544,39 @@ static inline void tcg_out_mov(TCGContext *s, TCGType 
type,
 {
 /* Simple reg-reg move, optimising out the 'do nothing' case */
 if (ret != arg) {
-tcg_out_opc_reg(s, OPC_ADDU, ret, arg, TCG_REG_ZERO);
+tcg_out_opc_reg(s, OPC_OR, ret, arg, TCG_REG_ZERO);
 }
 }
 
-static inline void tcg_out_movi(TCGContext *s, TCGType type,
-TCGReg reg, tcg_target_long arg)
+static void tcg_out_movi(TCGContext *s, TCGType type,
+ TCGReg ret, tcg_target_long arg)
 {
+if (TCG_TARGET_REG_BITS == 64 && type == TCG_TYPE_I32) {
+arg = (int32_t)arg;
+}
 if (arg == (int16_t)arg) {
-tcg_out_opc_imm(s, OPC_ADDIU, reg, TCG_REG_ZERO, arg);
-} else if (arg == (uint16_t)arg) {
-tcg_out_opc_imm(s, OPC_ORI, reg, TCG_REG_ZERO, arg);
+tcg_out_opc_imm(s, OPC_ADDIU, ret, TCG_REG_ZERO, arg);
+return;
+}
+if (arg == (uint16_t)arg) {
+tcg_out_opc_imm(s, OPC_ORI, ret, TCG_REG_ZERO, arg);
+return;
+}
+if (TCG_TARGET_REG_BITS == 32 || arg == (int32_t)arg) {
+tcg_out_opc_imm(s, OPC_LUI, ret, TCG_REG_ZERO, arg >> 16);
 } else {
-tcg_out_opc_imm(s, OPC_LUI, reg, TCG_REG_ZERO, arg >> 16);
-if (arg & 0x) {
-tcg_out_opc_imm(s, OPC_ORI, reg, reg, arg & 0x);
+tcg_out_movi(s, TCG_TYPE_I32, ret, arg >> 31 >> 1);
+if (arg & 0xull) {
+tcg_out_dsll(s, ret, ret, 16);
+tcg_out_opc_imm(s, OPC_ORI, ret, ret, arg >> 16);
+tcg_out_dsll(s, ret, ret, 16);
+} else {
+tcg_out_dsll(s, ret, ret, 32);
 }
 }
+if (arg & 0x) {
+tcg_out_opc_imm(s, OPC_ORI, ret, ret, arg & 0x);
+}
 }
 
 static inline void tcg_out_bswap16(TCGContext *s, TCGReg ret, TCGReg arg)
-- 
2.1.0

[Qemu-devel] [PATCH v5 10/10] tcg-mips: Adjust qemu_ld/st for mips64

[Jin Guojie]

Cc: Aurelien Jarno 
Cc: James Hogan 
Signed-off-by: Richard Henderson 
Signed-off-by: Jin Guojie 
---
 tcg/mips/tcg-target.inc.c | 203 +-
 1 file changed, 146 insertions(+), 57 deletions(-)

diff --git a/tcg/mips/tcg-target.inc.c b/tcg/mips/tcg-target.inc.c
index 7282a4a..0e34037 100644
--- a/tcg/mips/tcg-target.inc.c
+++ b/tcg/mips/tcg-target.inc.c
@@ -32,8 +32,16 @@
 # define MIPS_BE  0
 #endif
 
-#define LO_OFF(MIPS_BE * 4)
-#define HI_OFF(4 - LO_OFF)
+#if TCG_TARGET_REG_BITS == 32
+# define LO_OFF  (MIPS_BE * 4)
+# define HI_OFF  (4 - LO_OFF)
+#else
+/* To assert at compile-time that these values were never used
+   for TCG_TARGET_REGS == 64 */
+/* extern */ int link_error(void);
+# define LO_OFF  link_error()
+# define HI_OFF  link_error()
+#endif
 
 #ifdef CONFIG_DEBUG_TCG
 static const char * const tcg_target_reg_names[TCG_TARGET_NB_REGS] = {
@@ -193,7 +201,7 @@ static int target_parse_constraint(TCGArgConstraint *ct, 
const char **pct_str)
 tcg_regset_set(ct->u.regs, 0x);
 tcg_regset_reset_reg(ct->u.regs, TCG_REG_A0);
 #if defined(CONFIG_SOFTMMU)
-if (TARGET_LONG_BITS == 64) {
+if (TCG_TARGET_REG_BITS < TARGET_LONG_BITS) {
 tcg_regset_reset_reg(ct->u.regs, TCG_REG_A2);
 }
 #endif
@@ -203,11 +211,11 @@ static int target_parse_constraint(TCGArgConstraint *ct, 
const char **pct_str)
 tcg_regset_set(ct->u.regs, 0x);
 tcg_regset_reset_reg(ct->u.regs, TCG_REG_A0);
 #if defined(CONFIG_SOFTMMU)
-if (TARGET_LONG_BITS == 32) {
-tcg_regset_reset_reg(ct->u.regs, TCG_REG_A1);
-} else {
+if (TCG_TARGET_REG_BITS < TARGET_LONG_BITS) {
 tcg_regset_reset_reg(ct->u.regs, TCG_REG_A2);
 tcg_regset_reset_reg(ct->u.regs, TCG_REG_A3);
+} else {
+tcg_regset_reset_reg(ct->u.regs, TCG_REG_A1);
 }
 #endif
 break;
@@ -1104,6 +1112,10 @@ static void * const qemu_ld_helpers[16] = {
 [MO_BESW] = helper_be_ldsw_mmu,
 [MO_BEUL] = helper_be_ldul_mmu,
 [MO_BEQ]  = helper_be_ldq_mmu,
+#if TCG_TARGET_REG_BITS == 64
+[MO_LESL] = helper_le_ldsl_mmu,
+[MO_BESL] = helper_be_ldsl_mmu,
+#endif
 };
 
 static void * const qemu_st_helpers[16] = {
@@ -1131,6 +1143,9 @@ static int tcg_out_call_iarg_reg(TCGContext *s, int i, 
TCGReg arg)
 if (i < ARRAY_SIZE(tcg_target_call_iarg_regs)) {
 tcg_out_mov(s, TCG_TYPE_REG, tcg_target_call_iarg_regs[i], arg);
 } else {
+/* For N32 and N64, the initial offset is different.  But there
+   we also have 8 argument register so we don't run out here.  */
+tcg_debug_assert(TCG_TARGET_REG_BITS == 32);
 tcg_out_st(s, TCG_TYPE_REG, arg, TCG_REG_SP, 4 * i);
 }
 return i + 1;
@@ -1172,6 +1187,7 @@ static int tcg_out_call_iarg_imm(TCGContext *s, int i, 
TCGArg arg)
 
 static int tcg_out_call_iarg_reg2(TCGContext *s, int i, TCGReg al, TCGReg ah)
 {
+tcg_debug_assert(TCG_TARGET_REG_BITS == 32);
 i = (i + 1) & ~1;
 i = tcg_out_call_iarg_reg(s, i, (MIPS_BE ? ah : al));
 i = tcg_out_call_iarg_reg(s, i, (MIPS_BE ? al : ah));
@@ -1179,7 +1195,7 @@ static int tcg_out_call_iarg_reg2(TCGContext *s, int i, 
TCGReg al, TCGReg ah)
 }
 
 /* Perform the tlb comparison operation.  The complete host address is
-   placed in BASE.  Clobbers TMP0, TMP1, A0.  */
+   placed in BASE.  Clobbers TMP0, TMP1, TMP2, A0.  */
 static void tcg_out_tlb_load(TCGContext *s, TCGReg base, TCGReg addrl,
  TCGReg addrh, TCGMemOpIdx oi,
  tcg_insn_unit *label_ptr[2], bool is_load)
@@ -1187,6 +1203,7 @@ static void tcg_out_tlb_load(TCGContext *s, TCGReg base, 
TCGReg addrl,
 TCGMemOp opc = get_memop(oi);
 unsigned s_bits = opc & MO_SIZE;
 unsigned a_bits = get_alignment_bits(opc);
+target_ulong mask;
 int mem_index = get_mmuidx(oi);
 int cmp_off
 = (is_load
@@ -1194,11 +1211,11 @@ static void tcg_out_tlb_load(TCGContext *s, TCGReg 
base, TCGReg addrl,
: offsetof(CPUArchState, tlb_table[mem_index][0].addr_write));
 int add_off = offsetof(CPUArchState, tlb_table[mem_index][0].addend);
 
-tcg_out_opc_sa(s, OPC_SRL, TCG_REG_A0, addrl,
+tcg_out_opc_sa(s, ALIAS_TSRL, TCG_REG_A0, addrl,
TARGET_PAGE_BITS - CPU_TLB_ENTRY_BITS);
 tcg_out_opc_imm(s, OPC_ANDI, TCG_REG_A0, TCG_REG_A0,
 (CPU_TLB_SIZE - 1) << CPU_TLB_ENTRY_BITS);
-tcg_out_opc_reg(s, OPC_ADDU, TCG_REG_A0, TCG_REG_A0, TCG_AREG0);
+tcg_out_opc_reg(s, ALIAS_PADD, TCG_REG_A0, TCG_REG_A0, TCG_AREG0);
 
 /* Compensate for very large offsets.  */
 if (add_off >= 0x8000) {
@@ -1208,51 +1225,63 @@ static void tcg_out_tlb_load(TCGContext *s, TCGReg 
base, TCGReg addrl,
 QEMU_BUILD_BUG_ON(offsetof(CPUArchState,
tlb_table[NB_MMU_MODES - 1][1])
   > 0x7ff0 + 0x7fff

Re: [Qemu-devel] [PATCH] qemu-timer: check active_timers outside lock/event

[Stefan Hajnoczi]

On Thu, Dec 01, 2016 at 10:03:43AM +0100, Paolo Bonzini wrote:
> This avoids taking the active_timers_lock or resetting/setting the
> timers_done_ev if there are no active timers.  This removes a small
> (2-3%) source of overhead for dataplane.  The list is then checked
> again inside the lock, or a NULL pointer could be dereferenced.
> 
> Signed-off-by: Paolo Bonzini 
> ---
>  qemu-timer.c | 20 
>  1 file changed, 16 insertions(+), 4 deletions(-)

Reviewed-by: Stefan Hajnoczi 


signature.asc
Description: PGP signature

Re: [Qemu-devel] [PATCH] migration: re-active images when migration fails to complete

[Kevin Wolf]

Forwarding to qemu-block so I won't forget to have a look.

Am 19.11.2016 um 12:43 hat zhanghailiang geschrieben:
> commit fe904ea8242cbae2d7e69c052c754b8f5f1ba1d6 fixed a case
> which migration aborted QEMU because it didn't regain the control
> of images while some errors happened.
> 
> Actually, we have another case in that error path to abort QEMU
> because of the same reason:
> migration_thread()
> migration_completion()
>bdrv_inactivate_all() > inactivate images
>qemu_savevm_state_complete_precopy()
>socket_writev_buffer() > error because destination 
> fails
>  qemu_fflush() ---> set error on migration stream
>qemu_mutex_unlock_iothread() --> unlock
> qmp_migrate_cancel() -> user cancelled migration
> migrate_set_state() --> set migrate CANCELLING
> migration_completion() -> go on to fail_invalidate
> if (s->state == MIGRATION_STATUS_ACTIVE) -> Jump this branch
> migration_thread() ---> break migration loop
>   vm_start() -> restart guest with inactive
> images
> We failed to regain the control of images because we only regain it
> while the migration state is "active", but here users cancelled the migration
> when they found some errors happened (for example, libvirtd daemon is shutdown
> in destination unexpectedly).
> 
> Signed-off-by: zhanghailiang 
> ---
>  migration/migration.c | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
> 
> diff --git a/migration/migration.c b/migration/migration.c
> index f498ab8..0c1ee6d 100644
> --- a/migration/migration.c
> +++ b/migration/migration.c
> @@ -1752,7 +1752,8 @@ fail_invalidate:
>  /* If not doing postcopy, vm_start() will be called: let's regain
>   * control on images.
>   */
> -if (s->state == MIGRATION_STATUS_ACTIVE) {
> +if (s->state == MIGRATION_STATUS_ACTIVE ||
> +s->state == MIGRATION_STATUS_CANCELLING) {
>  Error *local_err = NULL;
>  
>  bdrv_invalidate_cache_all(&local_err);
> -- 
> 1.8.3.1
> 
> 
> 

Re: [Qemu-devel] Linux kernel polling for QEMU

[Paolo Bonzini]

> > > Maybe we could do the same for sockets?  When data is available on a
> > > socket (or when it becomes writable), write to a user memory location.
> > >
> > > I, too, have an interest in polling; in my situation most of the polling
> > > happens in userspace.
> >
> > You are trying to improve on the latency of non-blocking
> > ppoll(2)/epoll_wait(2) call?
> 
> Yes, but the concern is for throughput, not latency.
> 
> My main loop looks like
> 
> execute some tasks
> poll from many sources
> 
> Since epoll_wait(..., 0) has non-trivial costs, I have to limit the
> polling rate, and even so it shows up in the profile.  If the cost were
> lower, I could poll at a higher frequency, resulting in lower worst-case
> latencies for high-priority tasks.

IMHO, the ideal model wouldn't enter the kernel at all unless you _want_
to go to sleep.

Paolo

Re: [Qemu-devel] Support for using TCG frontend as a library

[Peter Maydell]

On 1 December 2016 at 13:33, Liviu Ionescu  wrote:
>> On 1 Dec 2016, at 14:38, Peter Maydell  wrote:
>>
>> ... clean up QEMU's code so
>> that it is less interdependent ...
>
> that's a good idea anyway, but this does not address the current issue.
>
> if I'd have a separate library with ARM TCG, for Cortex-M emulation
> I'd probably write a simple memory management routine, to address
> flash, ram & peripherals and with an equally simple variant of the
> peripheral implementation I'd be done. no need to handle MMU,
> no need to worry about VM, KVM, save/restore objects, monitor,
> etc (actually no need for the complicated objects implementation at all).

The advantage of the 'MMU' layer for M profile is that it is the
path to having a working MPU (which we don't implement quite yet
but it would be nice to some day). The system emulation also pretty
much assumes our softmmu layer as the way to handle fast path
(memory) versus slowpath (device emulation, watchpoints, etc).

The advantage of save/restore is that users can do snapshotting, which
is a really useful debug technique.
You could throw away all our implementations of devices and
backends and so on, but then you'd have to reimplement them all
yourself (including things like network device backends), which
is a fair bit of work.

thanks
-- PMM

Re: [Qemu-devel] [PATCH v4 00/10] tcg mips64 and mips r6 improvements

[YunQiang Su]

On Thu, Dec 1, 2016 at 4:30 AM, Richard Henderson  wrote:
> On 11/30/2016 10:39 AM, Jin Guojie wrote:
>> Yesterday I  successfully got in touch with a Debian developer from imgtec. 
>> Welcome Su Yunqiang.
>> V4 patch can be tested on mips64 be hosts now.
>> The following guests on a mips64
>> big-endian host is OK:
>>   - Debian i386 with qemu-system-i386
>>   - Debian i386 with qemu-system-x86_64
>
> Excellent.
>
> Yunqiang, for the record is this mips64 or mips64r2?  If mips64r2, it might be

Jin gave me his new patch set. I tested it on R2.
All of the bellow work well.

(HOST)  (qemu-system)   (Debian ISO)
64eb  -> i386  ->   i386
64eb  -> x86_64 ->   i386
64eb  -> x86_64 ->   amd64
n32eb-> i386  ->   i386
n32eb-> x86_64 ->   i386
n32eb-> x86_64 ->   amd64
32eb  -> i386  ->   i386
32eb  -> x86_64 ->   i386
32eb  -> x86_64 ->   amd64

> helpful to re-test with use_mips32r2_instructions forced to 0 in
> tcg_target_detect_isa, since there are different paths selected based on that.

I will test for non-r2 today with these paris.

>
>> However, Debian amd64 with qemu-system-x86_64 fails to boot kernel.
>> A 'rep movsq' instruction is wrongly emulated.
>> I will fix this bug within one or two days.
>
> Excellent, thanks.
>
>> But even Su cannot provide an R6 machine.
>
> Ok, I guess we will just have to drop the R6 patches for now, until imgtec is
> able to provide feedback on them.
>
>
> r~



-- 
YunQiang Su

Re: [Qemu-devel] [PATCH 2/3] Add a new qmp command to start/stop replication

[Eric Blake]

On 12/01/2016 12:06 AM, Zhang Chen wrote:
> We can call this qmp command to start/stop replication outside of qemu.
> Like Xen colo need this function.
> 
> Signed-off-by: Zhang Chen 
> Signed-off-by: Wen Congyang 
> ---

> +++ b/qapi-schema.json
> @@ -4676,6 +4676,24 @@
>  { 'command': 'xen-load-devices-state', 'data': {'filename': 'str'} }
>  
>  ##
> +# @xen-set-replication
> +#
> +# Enable or disable replication
> +#
> +# @enable: true to enable, false to disable.
> +#
> +# @primary: true for primary or false for secondary
> +#
> +# @failover: true to do failover, false to stop

Missing an #optional marker, as well as the default value.

> +#
> +# Returns: nothing
> +#
> +# Since: 2.8

You've missed 2.8.  This must be 2.9.

> +##
> +{ 'command': 'xen-set-replication',
> +  'data': { 'enable': 'bool', 'primary': 'bool', '*failover' : 'bool' } }
> +
> +##
>  # @GICCapability:
>  #
>  # The struct describes capability for a specific GIC (Generic
> 

-- 
Eric Blake   eblake redhat com+1-919-301-3266
Libvirt virtualization library http://libvirt.org



signature.asc
Description: OpenPGP digital signature

Re: [Qemu-devel] [PATCH 3/3] Add a new qmp command to do checkpoint, get replication error

[Eric Blake]

On 12/01/2016 12:06 AM, Zhang Chen wrote:
> We can call this qmp command to do checkpoint outside of qemu.
> Like Xen colo need this function.
> 
> Signed-off-by: Zhang Chen 
> Signed-off-by: Wen Congyang 
> ---
>  docs/qmp-commands.txt | 24 

> +++ b/qapi-schema.json
> @@ -4694,6 +4694,28 @@
>'data': { 'enable': 'bool', 'primary': 'bool', '*failover' : 'bool' } }
>  
>  ##
> +# @xen-get-replication-error
> +#
> +# Get replicatin error that occurs when the vm is running

s/replicatin/replication/

> +#
> +# Returns: nothing
> +#
> +# Since: 2.8

You've missed 2.8.

> +##
> +{ 'command': 'xen-get-replication-error' }
> +
> +##
> +# @xen-do-checkpoint
> +#
> +# Do checkpoint
> +#
> +# Returns: nothing
> +#
> +# Since: 2.8

Again, should be 2.9

> +##
> +{ 'command': 'xen-do-checkpoint' }
> +
> +##
>  # @GICCapability:
>  #
>  # The struct describes capability for a specific GIC (Generic
> 

-- 
Eric Blake   eblake redhat com+1-919-301-3266
Libvirt virtualization library http://libvirt.org



signature.asc
Description: OpenPGP digital signature

Re: [Qemu-devel] [PATCH for-2.8] docs: Fix description of the sentence

[Eric Blake]

On 12/01/2016 12:55 AM, Zhang Chen wrote:
> Say it in another way to make it easier to understand.
> 
> Signed-off-by: Zhang Chen 
> Signed-off-by: Eric Blake 

I guess that's because I suggested the replacement text to use, even
though I didn't write the patch.

At any rate, since this is doc-only, it's safe for inclusion in 2.8, if
the maintainer wants to send a last-minute pull request (but if it
misses the release, that's okay too)

> Signed-off-by: Stefan Weil 
> ---
>  docs/colo-proxy.txt | 4 +++-
>  1 file changed, 3 insertions(+), 1 deletion(-)
> 
> diff --git a/docs/colo-proxy.txt b/docs/colo-proxy.txt
> index 76767cb..c4941de 100644
> --- a/docs/colo-proxy.txt
> +++ b/docs/colo-proxy.txt
> @@ -158,7 +158,9 @@ secondary.
>  
>  == Usage ==
>  
> -Here, we use demo ip and port discribe more clearly.
> +Here is an example using demonstration IP and port addresses to more
> +clearly describe the usage.
> +
>  Primary(ip:3.3.3.3):
>  -netdev 
> tap,id=hn0,vhost=off,script=/etc/qemu-ifup,downscript=/etc/qemu-ifdown
>  -device e1000,id=e0,netdev=hn0,mac=52:a4:00:12:78:66
> 

-- 
Eric Blake   eblake redhat com+1-919-301-3266
Libvirt virtualization library http://libvirt.org



signature.asc
Description: OpenPGP digital signature

Re: [Qemu-devel] [PATCH 1/3] Migration: Don't load vmdesc when xen is enabled

[Eric Blake]

On 12/01/2016 12:06 AM, Zhang Chen wrote:
> Xen need't this.

Huh? Did you mean:

Xen doesn't need this.

> 
> Signed-off-by: Zhang Chen 
> Signed-off-by: Wen Congyang 
> ---
>  migration/savevm.c | 4 
>  1 file changed, 4 insertions(+)
> 
> diff --git a/migration/savevm.c b/migration/savevm.c
> index 0363372..bec6c7e 100644
> --- a/migration/savevm.c
> +++ b/migration/savevm.c
> @@ -1973,6 +1973,10 @@ int qemu_loadvm_state(QEMUFile *f)
>  ret = qemu_file_get_error(f);
>  }
>  
> +if (xen_enabled()) {
> +return ret;
> +}
> +
>  /*
>   * Try to read in the VMDESC section as well, so that dumping tools that
>   * intercept our migration stream have the chance to see it.
> 

-- 
Eric Blake   eblake redhat com+1-919-301-3266
Libvirt virtualization library http://libvirt.org



signature.asc
Description: OpenPGP digital signature

[Qemu-devel] [Bug 1626972] Re: QEMU memfd_create fallback mechanism change for security drivers

[James Page]

This bug was fixed in the package qemu - 1:2.6.1+dfsg-0ubuntu7~cloud0
---

 qemu (1:2.6.1+dfsg-0ubuntu7~cloud0) xenial-ocata; urgency=medium
 .
   * New update for the Ubuntu Cloud Archive.
 .
 qemu (1:2.6.1+dfsg-0ubuntu7) zesty; urgency=medium
 .
   [ Rafael David Tinoco ]
   * Fixed wrong migration blocker when vhost is used (LP: #1626972)
 - d/p/vhost_migration-blocker-only-if-shared-log-is-used.patch


** Changed in: cloud-archive
   Status: Fix Committed => Fix Released

-- 
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1626972

Title:
  QEMU memfd_create fallback mechanism change for security drivers

Status in Ubuntu Cloud Archive:
  Fix Released
Status in QEMU:
  Fix Committed
Status in qemu package in Ubuntu:
  Fix Released
Status in qemu source package in Xenial:
  Fix Committed
Status in qemu source package in Yakkety:
  In Progress
Status in qemu source package in Zesty:
  Fix Released

Bug description:
  [Impact]

   * Updated QEMU (from UCA) live migration doesn't work with 3.13 kernels.
   * QEMU code checks if it can create /tmp/memfd-XXX files wrongly.
   * Apparmor will block access to /tmp/ and QEMU will fail migrating.

  [Test Case]

   * Install 2 Ubuntu Trusty (3.13) + UCA Mitaka + apparmor rules.
   * Try to live-migration from one to another. 
   * Apparmor will block creation of /tmp/memfd-XXX files.

  [Regression Potential]

   Pros:
   * Exhaustively tested this.
   * Worked with upstream on this fix. 
   * I'm implementing new vhost log mechanism for upstream.
   * One line change to a blocker that is already broken.

   Cons:
   * To break live migration in other circumstances. 

  [Other Info]

   * Christian Ehrhardt has been following this.

  ORIGINAL DESCRIPTION:

  When libvirt starts using apparmor, and creating apparmor profiles for
  every virtual machine created in the compute nodes, mitaka qemu (2.5 -
  and upstream also) uses a fallback mechanism for creating shared
  memory for live-migrations. This fall back mechanism, on kernels 3.13
  - that don't have memfd_create() system-call, try to create files on
  /tmp/ directory and fails.. causing live-migration not to work.

  Trusty with kernel 3.13 + Mitaka with qemu 2.5 + apparmor capability =
  can't live migrate.

  From qemu 2.5, logic is on :

  void *qemu_memfd_alloc(const char *name, size_t size, unsigned int seals, int 
*fd)
  {
  if (memfd_create)... ### only works with HWE kernels

  else ### 3.13 kernels, gets blocked by apparmor
     tmpdir = g_get_tmp_dir
     ...
     mfd = mkstemp(fname)
  }

  And you can see the errors:

  From the host trying to send the virtual machine:

  2016-08-15 16:36:26.160 1974 ERROR nova.virt.libvirt.driver 
[req-0cac612b-8d53-4610-b773-d07ad6bacb91 691a581cfa7046278380ce82b1c38ddd 
133ebc3585c041aebaead8c062cd6511 - - -] [instance: 
2afa1131-bc8c-43d2-9c4a-962c1bf7723e] Migration operation has aborted
  2016-08-15 16:36:26.248 1974 ERROR nova.virt.libvirt.driver 
[req-0cac612b-8d53-4610-b773-d07ad6bacb91 691a581cfa7046278380ce82b1c38ddd 
133ebc3585c041aebaead8c062cd6511 - - -] [instance: 
2afa1131-bc8c-43d2-9c4a-962c1bf7723e] Live Migration failure: internal error: 
unable to execute QEMU command 'migrate': Migration disabled: failed to 
allocate shared memory

  From the host trying to receive the virtual machine:

  Aug 15 16:36:19 tkcompute01 kernel: [ 1194.356794] type=1400 
audit(1471289779.791:72): apparmor="STATUS" operation="profile_load" 
profile="unconfined" name="libvirt-2afa1131-bc8c-43d2-9c4a-962c1bf7723e" 
pid=12565 comm="apparmor_parser"
  Aug 15 16:36:19 tkcompute01 kernel: [ 1194.357048] type=1400 
audit(1471289779.791:73): apparmor="STATUS" operation="profile_load" 
profile="unconfined" name="qemu_bridge_helper" pid=12565 comm="apparmor_parser"
  Aug 15 16:36:20 tkcompute01 kernel: [ 1194.877027] type=1400 
audit(1471289780.311:74): apparmor="STATUS" operation="profile_replace" 
profile="unconfined" name="libvirt-2afa1131-bc8c-43d2-9c4a-962c1bf7723e" 
pid=12613 comm="apparmor_parser"
  Aug 15 16:36:20 tkcompute01 kernel: [ 1194.904407] type=1400 
audit(1471289780.343:75): apparmor="STATUS" operation="profile_replace" 
profile="unconfined" name="qemu_bridge_helper" pid=12613 comm="apparmor_parser"
  Aug 15 16:36:20 tkcompute01 kernel: [ 1194.973064] type=1400 
audit(1471289780.407:76): apparmor="DENIED" operation="mknod" 
profile="libvirt-2afa1131-bc8c-43d2-9c4a-962c1bf7723e" name="/tmp/memfd-tNpKSj" 
pid=12625 comm="qemu-system-x86" requested_mask="c" denied_mask="c" fsuid=107 
ouid=107
  Aug 15 16:36:20 tkcompute01 kernel: [ 1194.979871] type=1400 
audit(1471289780.411:77): apparmor="DENIED" operation="open" 
profile="libvirt-2afa1131-bc8c-43d2-9c4a-962c1bf7723e" name="/tmp/" pid=12625 
comm="qemu-system-x86" requested_mask="r" denied_mask="r" fsuid=107 ouid=0
  Aug 15 16:36:20 tkcompute01 kernel: [ 1194.979881] type=140

Re: [Qemu-devel] [PATCH 1/3] timer: fix misleading comment in timer.h

[Paolo Bonzini]

On 01/12/2016 14:50, Stefan Hajnoczi wrote:
> On Wed, Nov 30, 2016 at 11:30:38PM -0500, Yaowei Bai wrote:
>> It's timer to expire, not clock.
>>
>> Signed-off-by: Yaowei Bai 
>> ---
>>  include/qemu/timer.h | 2 +-
>>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> For the whole series:
> 
> Reviewed-by: Stefan Hajnoczi 
> 
> PS: I suggest sending a cover letter "[PATCH 0/3]" in the future.  This
> makes it easy for reviewers to indicate they have reviewed the whole
> series.  Without a cover letter it's ambiguous whether my single
> Reviewed-by: applies to just this patch or to the whole series - and
> patch management tools will probably get it wrong too.
> 

I've queued the series for QEMU 2.9.  This kind of patch can probably be
sent to qemu-triv...@nongnu.org, which will simplify their inclusion.

Of course, this is not meant to diminish your contribution!  "Trivial"
patches are important and good comments will also help the next person
studying QEMU's source code.

Thanks,

Paolo

Re: [Qemu-devel] [kvm-unit-tests PATCH v13 1/4] arm: Define macros for accessing system registers

[Wei Huang]

On 12/01/2016 02:59 AM, Andrew Jones wrote:
> 
> Should this be From: Andre?
> 
> On Wed, Nov 30, 2016 at 11:16:39PM -0600, Wei Huang wrote:
>> This patch defines four macros to assist creating system register
>> accessors under both ARMv7 and AArch64:
>>* DEFINE_GET_SYSREG32(name, ...)
>>* DEFINE_SET_SYSREG32(name, ...)
>>* DEFINE_GET_SYSREG64(name, ...)
>>* DEFINE_SET_SYSREG64(name, ...)
>> These macros are translated to inline functions with consistent naming,
>> get_##name() and set_##name(), which can be used by C code directly.
>>
>> Signed-off-by: Andre Przywara 
>> Signed-off-by: Wei Huang 
>> ---
>>  lib/arm/asm/processor.h   | 37 -
>>  lib/arm64/asm/processor.h | 35 ---
>>  2 files changed, 60 insertions(+), 12 deletions(-)
>>
>> diff --git a/lib/arm/asm/processor.h b/lib/arm/asm/processor.h
>> index f25e7ee..3ca6b42 100644
>> --- a/lib/arm/asm/processor.h
>> +++ b/lib/arm/asm/processor.h
>> @@ -33,13 +33,40 @@ static inline unsigned long current_cpsr(void)
>>  
>>  #define current_mode() (current_cpsr() & MODE_MASK)
>>  
>> -static inline unsigned int get_mpidr(void)
>> -{
>> -unsigned int mpidr;
>> -asm volatile("mrc p15, 0, %0, c0, c0, 5" : "=r" (mpidr));
>> -return mpidr;
>> +#define DEFINE_GET_SYSREG32(name, opc1, crn, crm, opc2) 
>> \
>> +static inline uint32_t get_##name(void) 
>> \
>> +{   \
>> +uint32_t reg;   \
>> +asm volatile("mrc p15, " #opc1 ", %0, " #crn ", " #crm ", " \
>> + #opc2 : "=r" (reg));   \
>> +return reg; \
>> +}
>> +
>> +#define DEFINE_SET_SYSREG32(name, opc1, crn, crm, opc2) 
>> \
>> +static inline void set_##name(uint32_t value)   
>> \
>> +{   \
>> +asm volatile("mcr p15, " #opc1 ", %0, " #crn ", " #crm ", " \
>> + #opc2 :: "r" (value)); \
>^ nit: no space here, checkpatch would complain

Which checkpatch script you are using? I didn't find one in
kvm-unit-tests. I tried kernel's checkpatch script, but it didn't
complain anything against this patch.

>> +}
>> +

Re: [Qemu-devel] [PATCH v4 00/10] tcg mips64 and mips r6 improvements

[James Hogan]

On Wed, Nov 30, 2016 at 12:30:19PM -0800, Richard Henderson wrote:
> On 11/30/2016 10:39 AM, Jin Guojie wrote:
> > But even Su cannot provide an R6 machine.
> 
> Ok, I guess we will just have to drop the R6 patches for now, until imgtec is
> able to provide feedback on them.

It booted a mips64r6 guest on P6600 (mips64r6), but its a 30MHz FPGA so
it took forever and wouldn't let me login to the guest as it'd hit the
60 second timeout.

Cheers
James


signature.asc
Description: Digital signature

Re: [Qemu-devel] [PATCH 06/10] aio-posix: remove walking_handlers, protecting AioHandler list with list_lock

[Paolo Bonzini]

On 30/11/2016 14:36, Paolo Bonzini wrote:
> 
> 
> On 30/11/2016 14:31, Stefan Hajnoczi wrote:
>> On Tue, Nov 29, 2016 at 12:47:03PM +0100, Paolo Bonzini wrote:
>>> @@ -272,22 +275,32 @@ bool aio_prepare(AioContext *ctx)
>>>  bool aio_pending(AioContext *ctx)
>>>  {
>>>  AioHandler *node;
>>> +bool result = false;
>>>  
>>> -QLIST_FOREACH(node, &ctx->aio_handlers, node) {
>>> +/*
>>> + * We have to walk very carefully in case aio_set_fd_handler is
>>> + * called while we're walking.
>>> + */
>>> +qemu_lockcnt_inc(&ctx->list_lock);
>>> +
>>> +QLIST_FOREACH_RCU(node, &ctx->aio_handlers, node) {
>>>  int revents;
>>>  
>>>  revents = node->pfd.revents & node->pfd.events;
>>>  if (revents & (G_IO_IN | G_IO_HUP | G_IO_ERR) && node->io_read &&
>>>  aio_node_check(ctx, node->is_external)) {
>>> -return true;
>>> +result = true;
>>> +break;
>>>  }
>>>  if (revents & (G_IO_OUT | G_IO_ERR) && node->io_write &&
>>>  aio_node_check(ctx, node->is_external)) {
>>> -return true;
>>> +result = true;
>>> +break;
>>>  }
>>>  }
>>> +qemu_lockcnt_dec(&ctx->list_lock);
>>>  
>>> -return false;
>>> +return result;
>>>  }
>>>  
>>>  bool aio_dispatch(AioContext *ctx)
>>> @@ -308,13 +321,12 @@ bool aio_dispatch(AioContext *ctx)
>>>   * We have to walk very carefully in case aio_set_fd_handler is
>>>   * called while we're walking.
>>>   */
>>> -ctx->walking_handlers++;
>>> +qemu_lockcnt_inc(&ctx->list_lock);
>>>  
>>> -QLIST_FOREACH_SAFE(node, &ctx->aio_handlers, node, tmp) {
>>> +QLIST_FOREACH_SAFE_RCU(node, &ctx->aio_handlers, node, tmp) {
>>>  int revents;
>>>  
>>> -revents = node->pfd.revents & node->pfd.events;
>>> -node->pfd.revents = 0;
>>> +revents = atomic_xchg(&node->pfd.revents, 0) & node->pfd.events;
>>
>> Why is node->pfd.revents accessed with atomic_*() here and in aio_poll()
>> but not in aio_pending()?
> 
> It could use atomic_read there, indeed.

Actually, thanks to the (already committed) patches that limit aio_poll
to the I/O thread, these atomic accesses are not needed anymore.

Paolo

Re: [Qemu-devel] [PATCH v7 0/5] IOMMU: intel_iommu support map and unmap notifications

[Alex Williamson]

On Wed, 30 Nov 2016 17:23:59 +0800
Peter Xu  wrote:

> On Mon, Nov 28, 2016 at 05:51:50PM +0200, Aviv B.D wrote:
> > * intel_iommu's replay op is not implemented yet (May come in different 
> > patch 
> >   set).
> >   The replay function is required for hotplug vfio device and to move 
> > devices 
> >   between existing domains.  
> 
> I am thinking about this replay thing recently and now I start to
> doubt whether the whole vt-d vIOMMU framework suites this...
> 
> Generally speaking, current work is throwing away the IOMMU "domain"
> layer here. We maintain the mapping only per device, and we don't care
> too much about which domain it belongs. This seems problematic.
> 
> A simplest wrong case for this is (let's assume cache-mode is
> enabled): if we have two assigned devices A and B, both belong to the
> same domain 1. Meanwhile, in domain 1 assume we have one mapping which
> is the first page (iova range 0-0xfff). Then, if guest wants to
> invalidate the page, it'll notify VT-d vIOMMU with an invalidation
> message. If we do this invalidation per-device, we'll need to UNMAP
> the region twice - once for A, once for B (if we have more devices, we
> will unmap more times), and we can never know we have done duplicated
> work since we don't keep domain info, so we don't know they are using
> the same address space. The first unmap will work, and then we'll
> possibly get some errors on the rest of dma unmap failures.
> 
> Looks like we just cannot live without knowing this domain layer.
> Because the address space is binded to the domain. If we want to sync
> the address space (here to setup a correct shadow page table), we need
> to do it per-domain.
> 
> What I can think of as a solution is that we introduce this "domain"
> layer - like a memory region per domain. When invalidation happens,
> it's per-domain, not per-device any more (actually I guess that's what
> current vt-d iommu driver in kernel is doing, we just ignored it - we
> fetch the devices that matches the domain ID). We can/need to maintain
> something different, like sid <-> domain mappings (we can do this as
> long as we are notified when context entries changed), per-domain
> mappings (just like per-device mappings that we are trying to build in
> this series, but what we really need is IMHO per domain one), etc.
> When device switches domain, we switch the IOMMU memory region
> accordingly.
> 
> Does this make any sense? Comments are greatly welcomed (especially
> from AlexW and DavidG).

It's been a bit since I've looked at VT-d emulation, but I certainly
remember that it's way more convoluted than I expected.  It seems like
a domain should create an AddressSpace and any devices assigned to that
domain should make use of that single address space, but IIRC VT-d
creates an address space per device, ie. per context entry.

Re: [Qemu-devel] [kvm-unit-tests PATCH v13 1/4] arm: Define macros for accessing system registers

[Andrew Jones]

On Thu, Dec 01, 2016 at 09:27:59AM -0600, Wei Huang wrote:
> 
> 
> On 12/01/2016 02:59 AM, Andrew Jones wrote:
> > 
> > Should this be From: Andre?
> > 
> > On Wed, Nov 30, 2016 at 11:16:39PM -0600, Wei Huang wrote:
> >> This patch defines four macros to assist creating system register
> >> accessors under both ARMv7 and AArch64:
> >>* DEFINE_GET_SYSREG32(name, ...)
> >>* DEFINE_SET_SYSREG32(name, ...)
> >>* DEFINE_GET_SYSREG64(name, ...)
> >>* DEFINE_SET_SYSREG64(name, ...)
> >> These macros are translated to inline functions with consistent naming,
> >> get_##name() and set_##name(), which can be used by C code directly.
> >>
> >> Signed-off-by: Andre Przywara 
> >> Signed-off-by: Wei Huang 
> >> ---
> >>  lib/arm/asm/processor.h   | 37 -
> >>  lib/arm64/asm/processor.h | 35 ---
> >>  2 files changed, 60 insertions(+), 12 deletions(-)
> >>
> >> diff --git a/lib/arm/asm/processor.h b/lib/arm/asm/processor.h
> >> index f25e7ee..3ca6b42 100644
> >> --- a/lib/arm/asm/processor.h
> >> +++ b/lib/arm/asm/processor.h
> >> @@ -33,13 +33,40 @@ static inline unsigned long current_cpsr(void)
> >>  
> >>  #define current_mode() (current_cpsr() & MODE_MASK)
> >>  
> >> -static inline unsigned int get_mpidr(void)
> >> -{
> >> -  unsigned int mpidr;
> >> -  asm volatile("mrc p15, 0, %0, c0, c0, 5" : "=r" (mpidr));
> >> -  return mpidr;
> >> +#define DEFINE_GET_SYSREG32(name, opc1, crn, crm, opc2)   
> >> \
> >> +static inline uint32_t get_##name(void)   
> >> \
> >> +{ \
> >> +  uint32_t reg;   \
> >> +  asm volatile("mrc p15, " #opc1 ", %0, " #crn ", " #crm ", " \
> >> +   #opc2 : "=r" (reg));   \
> >> +  return reg; \
> >> +}
> >> +
> >> +#define DEFINE_SET_SYSREG32(name, opc1, crn, crm, opc2)   
> >> \
> >> +static inline void set_##name(uint32_t value) 
> >> \
> >> +{ \
> >> +  asm volatile("mcr p15, " #opc1 ", %0, " #crn ", " #crm ", " \
> >> +   #opc2 :: "r" (value)); \
> >^ nit: no space here, checkpatch would complain
> 
> Which checkpatch script you are using? I didn't find one in
> kvm-unit-tests. I tried kernel's checkpatch script, but it didn't
> complain anything against this patch.

I use the kernel's, and it, at least used to, complains about no
spaces between the ':' in asms. If it doesn't complain now, then
it doesn't matter. Actually, it didn't really matter before :-)

Thanks,
drew
> 
> >> +}
> >> +
> 
> 
> 

Re: [Qemu-devel] [PATCH v5 00/10] tcg mips64 and mips r6 improvements

[Richard Henderson]

On 12/01/2016 05:51 AM, Jin Guojie wrote:
> Changes in v5:
>   * Update against master(v2.8.0-rc2)
>   * Fix a bug: 64-bit big-endian guests hang on mips64 little-endian
>   hosts, and vice versa. This bug was first introduced in v2 patch,
>   due to obvious misuse of ret/arg registers in tcg_out_bswap64().
> 
> tcg_out_opc_reg(s, OPC_DSBH, ret, 0, arg);
>   - tcg_out_opc_reg(s, OPC_DSHD, ret, 0, arg);
>   + tcg_out_opc_reg(s, OPC_DSHD, ret, 0, ret);

Oops.  Thanks.

>   * Fix a style problem: checkpatch.pl forbids 'extern' to be used in .c.
> 
>   ERROR: externs should be avoided in .c files
>   #28: FILE: tcg/mips/tcg-target.inc.c:39:
>   +extern int link_error(void);

Hmph.  This is checkpatch not being helpful, but your change is fine.


I've looked at a diff between your current patch and the last update I had to
my branch.  This probably includes code that post-dates the v2 that you started
with.  There are two things I'd like to point out:


 @@ -1233,7 +1235,8 @@ static void tcg_out_tlb_load(TCGContext *s, TCGReg base,
TCGReg addrl,
  if (a_bits < s_bits) {
  a_bits = s_bits;
  }
 -mask = (target_ulong)TARGET_PAGE_MASK | ((1 << a_bits) - 1);
 +
 +mask = TARGET_PAGE_MASK | ((1 << a_bits) - 1);


You need the target_ulong cast here for mips64.
See patch ebb90a005da67147245cd38fb04a965a87a961b7.


  if (TCG_TARGET_REG_BITS > TARGET_LONG_BITS) {
 -tcg_out_ext32u(s, base, addrl);
 -addrl = base;
 +tcg_out_ext32u(s, TCG_TMP0, TCG_TMP0);
  }

Why did you make this change?  It is definitely wrong.

We should be zero-extending the guest address, not the address that we just
loaded from CMP_OFF.  This is because we need to add an unsigned 32-bit
quantity to the full 64-bit host pointer that we load from ADD_OFF.

Did you notice a compare problem between TMP1 and TMP0 below?  If so, I believe
that a partial solution is the TARGET_PAGE_MASK change above.  I guess we also
need to do

  tcg_out_ldst(s, (TARGET_LONG_BITS == 64 ? OPC_LD
   TCG_TARGET_REG_BITS == 64 : OPC_LWU : OPC_LW),
   TCG_TMP0, TCG_REG_A0, cmp_off);

in the else section of the tlb comparator load above, since mask will be 32-bit
unsigned for TARGET_LONG_BITS == 32, and we need an unsigned quantity to
compare that against.


r~


PS: Ignoring N32 for now.  But as a note to ourselves for future: What is the
proper combination of zero/sign-extend vs ADDU/DADDU for 32/64-bit guests and
an N32 host?  What we have now is technically illegal, with zero-extend + ADDU.
 But I can imagine several valid scenarios.

Re: [Qemu-devel] [PATCH v4 00/10] tcg mips64 and mips r6 improvements

[Richard Henderson]

On 12/01/2016 07:32 AM, James Hogan wrote:
> On Wed, Nov 30, 2016 at 12:30:19PM -0800, Richard Henderson wrote:
>> On 11/30/2016 10:39 AM, Jin Guojie wrote:
>>> But even Su cannot provide an R6 machine.
>>
>> Ok, I guess we will just have to drop the R6 patches for now, until imgtec is
>> able to provide feedback on them.
> 
> It booted a mips64r6 guest on P6600 (mips64r6), but its a 30MHz FPGA so
> it took forever and wouldn't let me login to the guest as it'd hit the
> 60 second timeout.

Thanks, good to know.


r~

Re: [Qemu-devel] [PATCH for-2.8] monitor: fix object_del for command-line-created objects

[Michael Roth]

Quoting Eric Blake (2016-11-30 20:33:56)
> On 11/30/2016 05:06 PM, Michael Roth wrote:
> > Currently objects specified on the command-line are only partially
> > cleaned up when 'object_del' is issued in either HMP or QMP: the
> > object itself is fully finalized, but the QemuOpts are not removed.
> > This results in the following behavior:
> > 
> >   x86_64-softmmu/qemu-system-x86_64 -monitor stdio \
> > -object memory-backend-ram,id=ram1,size=256M
> > 
> >   QEMU 2.7.91 monitor - type 'help' for more information
> >   (qemu) object_del ram1
> >   (qemu) object_del ram1
> >   object 'ram1' not found
> >   (qemu) object_add memory-backend-ram,id=ram1,size=256M
> >   Duplicate ID 'ram1' for object
> >   Try "help object_add" for more information
> > 
> > which can be an issue for use-cases like memory hotplug.
> 
> Nice analysis.
> 
> > 
> > This happens on the HMP side because hmp_object_add() attempts to
> > create a temporary QemuOpts entry with ID 'ram1', which ends up
> > conflicting with the command-line-created entry, since it was never
> > cleaned up during the previous hmp_object_del() call.
> > 
> > We address this by adding checks in {qmp,hmp}_object_del to determine
> > whether an option group entry matching the object's ID is present,
> > and removing it if it is.
> > 
> > Note that qmp_object_add() never attempts to create a temporary
> > QemuOpts entry, so it does not encounter the duplicate ID error,
> > which is why this isn't generally visible in libvirt.
> 
> Phew. Yeah, libvirt avoiding HMP where possible saves a lot of hassles.
> 
> > +++ b/hmp.c
> > @@ -2072,6 +2072,16 @@ void hmp_object_del(Monitor *mon, const QDict *qdict)
> >  
> >  user_creatable_del(id, &err);
> >  hmp_handle_error(mon, &err);
> > +
> > +/* if object was defined on the command-line, remove its corresponding
> > + * option group entry
> > + */
> > +if (err == NULL) {
> > +QemuOptsList *opt_group = qemu_find_opts_err("object", &err);
> > +if (opt_group) {
> > +qemu_opts_del(qemu_opts_find(opt_group, id));
> > +}
> > +}
> 
> This one looks okay.
> 
> >  }
> >  
> >  void hmp_info_memdev(Monitor *mon, const QDict *qdict)
> > diff --git a/qmp.c b/qmp.c
> > index 0028f0b..87c545d 100644
> > --- a/qmp.c
> > +++ b/qmp.c
> > @@ -686,6 +686,16 @@ void qmp_object_add(const char *type, const char *id,
> >  void qmp_object_del(const char *id, Error **errp)
> >  {
> >  user_creatable_del(id, errp);
> > +
> > +/* if object was defined on the command-line, remove its corresponding
> > + * option group entry
> > + */
> > +if (!(errp && *errp)) {
> 
> But this is wrong. Please spin a v2 that uses a local Error object, then
> use error_propagate(err, errp). Making anything conditional on whether
> an error occurred requires a local object, since the caller can pass in
> NULL, but you want your cleanup to happen even when the caller doesn't
> care about errors.

Ugh, I should know better by now. Thanks for the catch, will make sure
this is done properly in v2.

> 
> > +QemuOptsList *opt_group = qemu_find_opts_err("object", errp);
> > +if (opt_group) {
> > +qemu_opts_del(qemu_opts_find(opt_group, id));
> > +}
> > +}
> >  }
> >  
> >  MemoryDeviceInfoList *qmp_query_memory_devices(Error **errp)
> > 
> 
> -- 
> Eric Blake   eblake redhat com+1-919-301-3266
> Libvirt virtualization library http://libvirt.org
> 

Re: [Qemu-devel] [PATCH] monitor: fix object_del for command-line-created objects

[Michael Roth]

Quoting Dr. David Alan Gilbert (2016-12-01 06:34:10)
> * Daniel P. Berrange (berra...@redhat.com) wrote:
> > On Wed, Nov 30, 2016 at 05:06:16PM -0600, Michael Roth wrote:
> > > Currently objects specified on the command-line are only partially
> > > cleaned up when 'object_del' is issued in either HMP or QMP: the
> > > object itself is fully finalized, but the QemuOpts are not removed.
> > > This results in the following behavior:
> > > 
> > >   x86_64-softmmu/qemu-system-x86_64 -monitor stdio \
> > > -object memory-backend-ram,id=ram1,size=256M
> > > 
> > >   QEMU 2.7.91 monitor - type 'help' for more information
> > >   (qemu) object_del ram1
> > >   (qemu) object_del ram1
> > >   object 'ram1' not found
> > >   (qemu) object_add memory-backend-ram,id=ram1,size=256M
> > >   Duplicate ID 'ram1' for object
> > >   Try "help object_add" for more information
> > > 
> > > which can be an issue for use-cases like memory hotplug.
> > > 
> > > This happens on the HMP side because hmp_object_add() attempts to
> > > create a temporary QemuOpts entry with ID 'ram1', which ends up
> > > conflicting with the command-line-created entry, since it was never
> > > cleaned up during the previous hmp_object_del() call.
> > > 
> > > We address this by adding checks in {qmp,hmp}_object_del to determine
> > > whether an option group entry matching the object's ID is present,
> > > and removing it if it is.
> > > 
> > > Note that qmp_object_add() never attempts to create a temporary
> > > QemuOpts entry, so it does not encounter the duplicate ID error,
> > > which is why this isn't generally visible in libvirt.
> > > 
> > > Cc: "Dr. David Alan Gilbert" 
> > > Cc: Markus Armbruster 
> > > Cc: Eric Blake 
> > > Cc: Daniel Berrange 
> > > Signed-off-by: Michael Roth 
> > > ---
> > >  hmp.c | 10 ++
> > >  qmp.c | 10 ++
> > >  2 files changed, 20 insertions(+)
> > > 
> > > diff --git a/hmp.c b/hmp.c
> > > index b869617..99b8bf3 100644
> > > --- a/hmp.c
> > > +++ b/hmp.c
> > > @@ -2072,6 +2072,16 @@ void hmp_object_del(Monitor *mon, const QDict 
> > > *qdict)
> > >  
> > >  user_creatable_del(id, &err);
> > >  hmp_handle_error(mon, &err);
> > > +
> > > +/* if object was defined on the command-line, remove its 
> > > corresponding
> > > + * option group entry
> > > + */
> > > +if (err == NULL) {
> > > +QemuOptsList *opt_group = qemu_find_opts_err("object", &err);
> > > +if (opt_group) {
> > > +qemu_opts_del(qemu_opts_find(opt_group, id));
> > > +}
> > > +}
> > >  }
> > >  
> > >  void hmp_info_memdev(Monitor *mon, const QDict *qdict)
> > > diff --git a/qmp.c b/qmp.c
> > > index 0028f0b..87c545d 100644
> > > --- a/qmp.c
> > > +++ b/qmp.c
> > > @@ -686,6 +686,16 @@ void qmp_object_add(const char *type, const char *id,
> > >  void qmp_object_del(const char *id, Error **errp)
> > >  {
> > >  user_creatable_del(id, errp);
> > > +
> > > +/* if object was defined on the command-line, remove its 
> > > corresponding
> > > + * option group entry
> > > + */
> > > +if (!(errp && *errp)) {
> > > +QemuOptsList *opt_group = qemu_find_opts_err("object", errp);
> > > +if (opt_group) {
> > > +qemu_opts_del(qemu_opts_find(opt_group, id));
> > > +}
> > > +}
> > >  }
> > 
> > I rather feel like this code ought to be in user_creatable_del(), since
> > all code paths which call user_creatable_del() need to do deal with
> > this scenario.
> 
> Yes that seems cleaner;  the cleanup that's being done is not the result
> of either of the monitor's actions.

It was also for similar reasons that I was hesitant to put it in
user_creatable_del() :) Putting it higher up in the stack somehow felt
less icky, but given that they both violate encapsulation somewhat I
suppose it does makes sense to take the more practical/safer route and
put it in a common path. Will take this approach for v2.

> 
> Dave
> 
> > Also I'd like to see a unit test added that exposes this problem and
> > demonstrates the fix - could att it to tests/check-qom-proplist.c
> > 
> > Regards,
> > Daniel
> > -- 
> > |: http://berrange.com  -o-http://www.flickr.com/photos/dberrange/ 
> > :|
> > |: http://libvirt.org  -o- http://virt-manager.org 
> > :|
> > |: http://entangle-photo.org   -o-http://search.cpan.org/~danberr/ 
> > :|
> --
> Dr. David Alan Gilbert / dgilb...@redhat.com / Manchester, UK
> 

[Qemu-devel] [PATCH v4 0/7] q35: add negotiable broadcast SMI

[Laszlo Ersek]

* This is version 4 of the series; the last version was at
  .

  This version is practically a rewrite from scratch, seeking to address
  the v3 feedback. Here's what the individual patches do:

  - Patch #1 rebases and extends Michael's "writeable fw_cfg blobs"
patch from Feb/March 2016. The changes relative to the original
patch are documented in the commit message (the code changes are
minimal).

  - Patches #2 and #3 turn the FW_CFG_FILE_SLOTS constant into a device
property, and expose the desired number of fw_cfg file slots to
board code. This is meant to address a concern raised by Paolo in
the v2 review
,
namely that we're about to run out of FW_CFG_FILE_SLOTS.

  - Patch #4 introduces the "pc-q35-2.9" and "pc-i440fx-2.9" machine
types, which are allowed to take advantage of the new default for
fw_cfg file slots (0x20 rather than 0x10).

  - Patch #5 introduces SMI feature negotiation via fw_cfg, with the
following new files:

- etc/smi/host-features
- etc/smi/guest-features
- etc/smi/features-ok

This is supposed to follow Michael's recommendation re: imitating
virtio
.

The guest-features file is freely writeable by the guest (no write
callbacks in fw_cfg), and the feature validation & lockdown occurs
when the guest selects the features-ok file (for reading).

Board code is allowed to choose the host feature bitmap to
advertise.

This patch doesn't add any specific SMI features yet.

  - Patch #6 adds the ICH9_LPC_SMI_F_BROADCAST feature.

  - Patch #7 introduces the PCMachineClass.get_smi_host_features method,
and implements it for "pc-q35-2.9" and later. The idea is to tie the
SMI host features to machine types, and let the machine types
calculate their host features with code (i.e., not just a constant).

In this patch, the "pc-q35-2.9" machine type exposes the
ICH9_LPC_SMI_F_BROADCAST feature iff (smp_cpus == max_cpus), that
is, when VCPU hotplug is not possible. (Also from Paolo's v3
feedback, in
.)

* I've written the OVMF side patches too and tested them together
  (including gdb / debug messages for "white box" testing).

* Note that this version depends on the following PULL req from Michael:

  [Qemu-devel] [PULL 0/5] virtio, vhost, pc: fixes
  http://lists.nongnu.org/archive/html/qemu-devel/2016-11/msg05503.html

  In particular on the following patch:
  "loader: fix handling of custom address spaces when adding ROM blobs"

Cc: "Gabriel L. Somlo" 
Cc: "Michael S. Tsirkin" 
Cc: Eduardo Habkost 
Cc: Gerd Hoffmann 
Cc: Igor Mammedov 
Cc: Michael Walle 
Cc: Paolo Bonzini 
Cc: Peter Maydell 
Cc: Shannon Zhao 
Cc: qemu-...@nongnu.org

Thanks
Laszlo

Laszlo Ersek (6):
  fw-cfg: turn FW_CFG_FILE_SLOTS into a device property
  fw-cfg: expose "file_slots" parameter in fw_cfg_init_io_dma()
  hw/i386/pc: introduce 2.9 machine types with 0x20 fw_cfg file slots
  hw/isa/lpc_ich9: add SMI feature negotiation via fw_cfg
  hw/isa/lpc_ich9: add broadcast SMI feature
  hw/i386/pc_q35: advertise broadcast SMI if VCPU hotplug is turned off

Michael S. Tsirkin (1):
  fw-cfg: support writeable blobs

 docs/specs/fw_cfg.txt  |  36 +---
 hw/lm32/lm32_hwsetup.h |   2 +-
 include/hw/compat.h|  11 
 include/hw/i386/ich9.h |  15 -
 include/hw/i386/pc.h   |   4 ++
 include/hw/loader.h|   7 ++-
 include/hw/nvram/fw_cfg.h  |   5 +-
 include/hw/nvram/fw_cfg_keys.h |   7 ++-
 hw/arm/virt-acpi-build.c   |   2 +-
 hw/core/loader.c   |  18 +++---
 hw/i386/acpi-build.c   |   4 +-
 hw/i386/pc.c   |   3 +-
 hw/i386/pc_piix.c  |  16 +-
 hw/i386/pc_q35.c   |  37 -
 hw/isa/lpc_ich9.c  |  92 +-
 hw/nvram/fw_cfg.c  | 123 +++--
 16 files changed, 326 insertions(+), 56 deletions(-)

-- 
2.9.2

[Qemu-devel] [PATCH v4 4/7] hw/i386/pc: introduce 2.9 machine types with 0x20 fw_cfg file slots

[Laszlo Ersek]

Add "file_slots" compat properties for 2.8 and earlier machine types.

Cc: "Michael S. Tsirkin" 
Cc: Eduardo Habkost 
Cc: Gerd Hoffmann 
Cc: Igor Mammedov 
Cc: Paolo Bonzini 
Signed-off-by: Laszlo Ersek 
---
 include/hw/compat.h| 11 +++
 include/hw/i386/pc.h   |  3 +++
 include/hw/nvram/fw_cfg_keys.h |  6 --
 hw/i386/pc.c   |  2 +-
 hw/i386/pc_piix.c  | 16 +---
 hw/i386/pc_q35.c   | 13 +++--
 hw/nvram/fw_cfg.c  |  2 --
 7 files changed, 43 insertions(+), 10 deletions(-)

diff --git a/include/hw/compat.h b/include/hw/compat.h
index 0f06e113bee2..4eca87dc9c85 100644
--- a/include/hw/compat.h
+++ b/include/hw/compat.h
@@ -1,8 +1,19 @@
 #ifndef HW_COMPAT_H
 #define HW_COMPAT_H
 
+#define HW_COMPAT_2_8 \
+{\
+.driver   = "fw_cfg_mem",\
+.property = "file_slots",\
+.value= stringify(0x10),\
+},{\
+.driver   = "fw_cfg_io",\
+.property = "file_slots",\
+.value= stringify(0x10),\
+},
+
 #define HW_COMPAT_2_7 \
 {\
 .driver   = "virtio-pci",\
 .property = "page-per-vq",\
 .value= "on",\
diff --git a/include/hw/i386/pc.h b/include/hw/i386/pc.h
index 4b7413055989..430735e501dd 100644
--- a/include/hw/i386/pc.h
+++ b/include/hw/i386/pc.h
@@ -365,11 +365,14 @@ void pc_madt_cpu_entry(AcpiDeviceIf *adev, int uid,
 
 int e820_add_entry(uint64_t, uint64_t, uint32_t);
 int e820_get_num_entries(void);
 bool e820_get_entry(int, uint32_t, uint64_t *, uint64_t *);
 
+#define PC_COMPAT_2_9 \
+
 #define PC_COMPAT_2_8 \
+HW_COMPAT_2_8 \
 
 #define PC_COMPAT_2_7 \
 HW_COMPAT_2_7 \
 {\
 .driver   = TYPE_X86_CPU,\
diff --git a/include/hw/nvram/fw_cfg_keys.h b/include/hw/nvram/fw_cfg_keys.h
index 627589793671..335a0df79f23 100644
--- a/include/hw/nvram/fw_cfg_keys.h
+++ b/include/hw/nvram/fw_cfg_keys.h
@@ -26,12 +26,14 @@
 #define FW_CFG_SETUP_ADDR   0x16
 #define FW_CFG_SETUP_SIZE   0x17
 #define FW_CFG_SETUP_DATA   0x18
 #define FW_CFG_FILE_DIR 0x19
 
-#define FW_CFG_FILE_FIRST   0x20
-#define FW_CFG_FILE_SLOTS_TRAD  0x10
+#define FW_CFG_FILE_FIRST   0x20 /* never change this */
+#define FW_CFG_FILE_SLOTS_TRAD  0x10 /* never change this */
+#define FW_CFG_FILE_SLOTS_DFLT  0x20 /* update HW_COMPAT_xxx in sync */
+
 
 #define FW_CFG_WRITE_CHANNEL0x4000
 #define FW_CFG_ARCH_LOCAL   0x8000
 #define FW_CFG_ENTRY_MASK   (~(FW_CFG_WRITE_CHANNEL | FW_CFG_ARCH_LOCAL))
 
diff --git a/hw/i386/pc.c b/hw/i386/pc.c
index 5d929d8fc887..af51e8372db5 100644
--- a/hw/i386/pc.c
+++ b/hw/i386/pc.c
@@ -742,11 +742,11 @@ static FWCfgState *bochs_bios_init(AddressSpace *as, 
PCMachineState *pcms)
 FWCfgState *fw_cfg;
 uint64_t *numa_fw_cfg;
 int i, j;
 
 fw_cfg = fw_cfg_init_io_dma(FW_CFG_IO_BASE, FW_CFG_IO_BASE + 4, as,
-FW_CFG_FILE_SLOTS_TRAD);
+FW_CFG_FILE_SLOTS_DFLT);
 fw_cfg_add_i16(fw_cfg, FW_CFG_NB_CPUS, pcms->boot_cpus);
 
 /* FW_CFG_MAX_CPUS is a bit confusing/problematic on x86:
  *
  * For machine types prior to 1.8, SeaBIOS needs FW_CFG_MAX_CPUS for
diff --git a/hw/i386/pc_piix.c b/hw/i386/pc_piix.c
index a54a468c0ab3..2b67cf85371a 100644
--- a/hw/i386/pc_piix.c
+++ b/hw/i386/pc_piix.c
@@ -435,26 +435,36 @@ static void pc_i440fx_machine_options(MachineClass *m)
 m->hot_add_cpu = pc_hot_add_cpu;
 m->default_machine_opts = "firmware=bios-256k.bin";
 m->default_display = "std";
 }
 
-static void pc_i440fx_2_8_machine_options(MachineClass *m)
+static void pc_i440fx_2_9_machine_options(MachineClass *m)
 {
 pc_i440fx_machine_options(m);
 m->alias = "pc";
 m->is_default = 1;
 }
 
+DEFINE_I440FX_MACHINE(v2_9, "pc-i440fx-2.9", NULL,
+  pc_i440fx_2_9_machine_options);
+
+
+static void pc_i440fx_2_8_machine_options(MachineClass *m)
+{
+pc_i440fx_2_9_machine_options(m);
+m->alias = NULL;
+m->is_default = 0;
+SET_MACHINE_COMPAT(m, PC_COMPAT_2_8);
+}
+
 DEFINE_I440FX_MACHINE(v2_8, "pc-i440fx-2.8", NULL,
   pc_i440fx_2_8_machine_options);
 
 
 static void pc_i440fx_2_7_machine_options(MachineClass *m)
 {
 pc_i440fx_2_8_machine_options(m);
-m->is_default = 0;
-m->alias = NULL;
 SET_MACHINE_COMPAT(m, PC_COMPAT_2_7);
 }
 
 DEFINE_I440FX_MACHINE(v2_7, "pc-i440fx-2.7", NULL,
   pc_i440fx_2_7_machine_options);
diff --git a/hw/i386/pc_q35.c b/hw/i386/pc_q35.c
index b40d19ee00da..7fa40e7cbe0e 100644
--- a/hw/i386/pc_q35.c
+++ b/hw/i386/pc_q35.c
@@ -292,23 +292,32 @@ static void pc_q35_machine_options(MachineClass *m)
 m->no_floppy = 1;
 m->has_dynamic_sysbus = true;
 m->max_cpus = 288;
 }
 
-static void pc_q35_2_8_machine_options(MachineClass *m)
+static void pc_q35_2_9_machine_options(MachineClass *m)
 {
 pc_q35_machine_options(m);
 m->alias = "q35";
 }
 
+DEFINE_Q35_MACHINE(v2_9

[Qemu-devel] [PATCH v4 3/7] fw-cfg: expose "file_slots" parameter in fw_cfg_init_io_dma()

[Laszlo Ersek]

Accordingly, generalize the "file_slots" minimum calculation in
fw_cfg_init_io_dma(), and move the constant FW_CFG_FILE_SLOTS_TRAD
argument to the callers of fw_cfg_init_io_dma().

Cc: "Gabriel L. Somlo" 
Cc: "Michael S. Tsirkin" 
Cc: Gerd Hoffmann 
Cc: Igor Mammedov 
Cc: Paolo Bonzini 
Signed-off-by: Laszlo Ersek 
---
 docs/specs/fw_cfg.txt |  4 ++--
 include/hw/nvram/fw_cfg.h |  2 +-
 hw/i386/pc.c  |  3 ++-
 hw/nvram/fw_cfg.c | 13 ++---
 4 files changed, 11 insertions(+), 11 deletions(-)

diff --git a/docs/specs/fw_cfg.txt b/docs/specs/fw_cfg.txt
index 84e2978706f5..4a6888b511f4 100644
--- a/docs/specs/fw_cfg.txt
+++ b/docs/specs/fw_cfg.txt
@@ -153,12 +153,12 @@ Selector Reg.Range Usage
 0x4000 - 0x7fff  Generic (0x - 0x3fff, RW, ignored in QEMU v2.4+)
 0x8000 - 0xbfff  Arch. Specific (0x - 0x3fff, generally RO, possibly RW
  through the DMA interface in QEMU v2.9+)
 0xc000 - 0x  Arch. Specific (0x - 0x3fff, RW, ignored in v2.4+)
 
-In practice, the number of allowed firmware configuration items is given
-by the value (FW_CFG_FILE_FIRST + FW_CFG_FILE_SLOTS_TRAD) (see fw_cfg.h).
+In practice, the number of allowed firmware configuration items depends on the
+machine type.
 
 = Guest-side DMA Interface =
 
 If bit 1 of the feature bitmap is set, the DMA interface is present. This does
 not replace the existing fw_cfg interface, it is an add-on. This interface
diff --git a/include/hw/nvram/fw_cfg.h b/include/hw/nvram/fw_cfg.h
index b980cbaebf43..e9a6b6aa968c 100644
--- a/include/hw/nvram/fw_cfg.h
+++ b/include/hw/nvram/fw_cfg.h
@@ -173,11 +173,11 @@ void fw_cfg_add_file_callback(FWCfgState *s, const char 
*filename,
  */
 void *fw_cfg_modify_file(FWCfgState *s, const char *filename, void *data,
  size_t len);
 
 FWCfgState *fw_cfg_init_io_dma(uint32_t iobase, uint32_t dma_iobase,
-AddressSpace *dma_as);
+AddressSpace *dma_as, uint32_t file_slots);
 FWCfgState *fw_cfg_init_io(uint32_t iobase);
 FWCfgState *fw_cfg_init_mem(hwaddr ctl_addr, hwaddr data_addr);
 FWCfgState *fw_cfg_init_mem_wide(hwaddr ctl_addr,
  hwaddr data_addr, uint32_t data_width,
  hwaddr dma_addr, AddressSpace *dma_as);
diff --git a/hw/i386/pc.c b/hw/i386/pc.c
index a9e64a88e5e7..5d929d8fc887 100644
--- a/hw/i386/pc.c
+++ b/hw/i386/pc.c
@@ -741,11 +741,12 @@ static FWCfgState *bochs_bios_init(AddressSpace *as, 
PCMachineState *pcms)
 {
 FWCfgState *fw_cfg;
 uint64_t *numa_fw_cfg;
 int i, j;
 
-fw_cfg = fw_cfg_init_io_dma(FW_CFG_IO_BASE, FW_CFG_IO_BASE + 4, as);
+fw_cfg = fw_cfg_init_io_dma(FW_CFG_IO_BASE, FW_CFG_IO_BASE + 4, as,
+FW_CFG_FILE_SLOTS_TRAD);
 fw_cfg_add_i16(fw_cfg, FW_CFG_NB_CPUS, pcms->boot_cpus);
 
 /* FW_CFG_MAX_CPUS is a bit confusing/problematic on x86:
  *
  * For machine types prior to 1.8, SeaBIOS needs FW_CFG_MAX_CPUS for
diff --git a/hw/nvram/fw_cfg.c b/hw/nvram/fw_cfg.c
index 2e1441c09750..c33c76ab93b1 100644
--- a/hw/nvram/fw_cfg.c
+++ b/hw/nvram/fw_cfg.c
@@ -926,11 +926,11 @@ static void fw_cfg_init1(DeviceState *dev)
 s->machine_ready.notify = fw_cfg_machine_ready;
 qemu_add_machine_init_done_notifier(&s->machine_ready);
 }
 
 FWCfgState *fw_cfg_init_io_dma(uint32_t iobase, uint32_t dma_iobase,
-AddressSpace *dma_as)
+AddressSpace *dma_as, uint32_t file_slots)
 {
 DeviceState *dev;
 FWCfgState *s;
 uint32_t version = FW_CFG_VERSION;
 bool dma_requested = dma_iobase && dma_as;
@@ -940,15 +940,14 @@ FWCfgState *fw_cfg_init_io_dma(uint32_t iobase, uint32_t 
dma_iobase,
 qdev_prop_set_uint32(dev, "dma_iobase", dma_iobase);
 if (!dma_requested) {
 qdev_prop_set_bit(dev, "dma_enabled", false);
 }
 
-/* Once we expose the "file_slots" property to callers of
- * fw_cfg_init_io_dma(), the following setting should become conditional on
- * the input parameter being lower than the current value of the property.
- */
-qdev_prop_set_uint32(dev, "file_slots", FW_CFG_FILE_SLOTS_TRAD);
+if (file_slots < object_property_get_int(OBJECT(dev), "file_slots",
+ &error_abort)) {
+qdev_prop_set_uint32(dev, "file_slots", file_slots);
+}
 
 fw_cfg_init1(dev);
 s = FW_CFG(dev);
 
 if (s->dma_enabled) {
@@ -964,11 +963,11 @@ FWCfgState *fw_cfg_init_io_dma(uint32_t iobase, uint32_t 
dma_iobase,
 return s;
 }
 
 FWCfgState *fw_cfg_init_io(uint32_t iobase)
 {
-return fw_cfg_init_io_dma(iobase, 0, NULL);
+return fw_cfg_init_io_dma(iobase, 0, NULL, FW_CFG_FILE_SLOTS_TRAD);
 }
 
 FWCfgState *fw_cfg_init_mem_wide(hwaddr ctl_addr,
  hwaddr data_addr, uint32_t data_width,
  hwaddr

[Qemu-devel] [PATCH v4 5/7] hw/isa/lpc_ich9: add SMI feature negotiation via fw_cfg

[Laszlo Ersek]

Introduce the following fw_cfg files:

- "etc/smi/host-features": a little endian uint64_t feature bitmap,
  presenting the features known by the host to the guest. Read-only for
  the guest.

  The content of this file is calculated by QEMU at startup (the
  calculation will be added later). The same machine type is supposed to
  expose the same SMI features regardless of QEMU version, hence this file
  is not migrated.

- "etc/smi/guest-features": a little endian uint64_t feature bitmap,
  representing the features the guest would like to request. Read-write
  for the guest.

  The guest can freely (re)write this file, it has no direct consequence.
  Initial value is zero. A nonzero value causes the SMI-related fw_cfg
  files and fields that are under guest influence to be migrated.

- "etc/smi/features-ok": contains a uint8_t value, and it is read-only for
  the guest. When the guest selects the associated fw_cfg key, the guest
  features are validated against the host features. In case of error, the
  negotiation doesn't proceed, and the features-ok file remains zero. In
  case of success, the features-ok file becomes (uint8_t)1, and the
  negotiated features are locked down internally (to which no further
  changes are possible until reset).

  The initial value is zero.  A nonzero value causes the SMI-related
  fw_cfg files and fields that are under guest influence to be migrated.

The C-language fields backing the host-features and guest-features files
are uint8_t arrays. This is because they carry guest-side representation
(our choice is little endian), while VMSTATE_UINT64() assumes / implies
host-side endianness for any uint64_t fields. If we migrate a guest
between hosts with different endiannesses (which is possible with TCG),
then the host-side value is preserved, and the host-side representation is
translated. This would be visible to the guest through fw_cfg, unless we
used plain byte arrays. So we do.

Cc: "Michael S. Tsirkin" 
Cc: Gerd Hoffmann 
Cc: Igor Mammedov 
Cc: Paolo Bonzini 
Signed-off-by: Laszlo Ersek 
---
 include/hw/i386/ich9.h | 12 +++-
 hw/i386/pc_q35.c   |  2 +-
 hw/isa/lpc_ich9.c  | 83 +-
 3 files changed, 94 insertions(+), 3 deletions(-)

diff --git a/include/hw/i386/ich9.h b/include/hw/i386/ich9.h
index 5fd7e97d2347..33142eb37252 100644
--- a/include/hw/i386/ich9.h
+++ b/include/hw/i386/ich9.h
@@ -15,11 +15,12 @@
 #include "hw/pci/pci_bus.h"
 
 void ich9_lpc_set_irq(void *opaque, int irq_num, int level);
 int ich9_lpc_map_irq(PCIDevice *pci_dev, int intx);
 PCIINTxRoute ich9_route_intx_pin_to_irq(void *opaque, int pirq_pin);
-void ich9_lpc_pm_init(PCIDevice *pci_lpc, bool smm_enabled);
+void ich9_lpc_pm_init(PCIDevice *pci_lpc, bool smm_enabled,
+  uint64_t smi_host_features);
 I2CBus *ich9_smb_init(PCIBus *bus, int devfn, uint32_t smb_io_base);
 
 void ich9_generate_smi(void);
 void ich9_generate_nmi(void);
 
@@ -62,10 +63,19 @@ typedef struct ICH9LPCState {
  * register contents and IO memory region
  */
 uint8_t rst_cnt;
 MemoryRegion rst_cnt_mem;
 
+/* SMI feature negotiation via fw_cfg */
+uint8_t smi_host_features[8]; /* guest-visible, read-only, little
+   * endian uint64_t */
+uint8_t smi_guest_features[8];/* guest-visible, read-write, little
+   * endian uint64_t */
+uint8_t smi_features_ok;  /* guest-visible, read-only; selecting it
+   * triggers feature lockdown */
+uint64_t smi_negotiated_features; /* guest-invisible, host endian */
+
 /* isa bus */
 ISABus *isa_bus;
 MemoryRegion rcrb_mem; /* root complex register block */
 Notifier machine_ready;
 
diff --git a/hw/i386/pc_q35.c b/hw/i386/pc_q35.c
index 7fa40e7cbe0e..eb0953bb6b16 100644
--- a/hw/i386/pc_q35.c
+++ b/hw/i386/pc_q35.c
@@ -228,11 +228,11 @@ static void pc_q35_init(MachineState *machine)
 /* init basic PC hardware */
 pc_basic_device_init(isa_bus, pcms->gsi, &rtc_state, !mc->no_floppy,
  (pcms->vmport != ON_OFF_AUTO_ON), 0xff0104);
 
 /* connect pm stuff to lpc */
-ich9_lpc_pm_init(lpc, pc_machine_is_smm_enabled(pcms));
+ich9_lpc_pm_init(lpc, pc_machine_is_smm_enabled(pcms), 0);
 
 /* ahci and SATA device, for q35 1 ahci controller is built-in */
 ahci = pci_create_simple_multifunction(host_bus,
PCI_DEVFN(ICH9_SATA1_DEV,
  ICH9_SATA1_FUNC),
diff --git a/hw/isa/lpc_ich9.c b/hw/isa/lpc_ich9.c
index 10d1ee8b9310..ee1fa553bfee 100644
--- a/hw/isa/lpc_ich9.c
+++ b/hw/isa/lpc_ich9.c
@@ -46,10 +46,12 @@
 #include "hw/acpi/ich9.h"
 #include "hw/pci/pci_bus.h"
 #include "exec/address-spaces.h"
 #include "sysemu/sysemu.h"
 #include "qom/cpu.h"
+#include "hw/nvram/fw_cfg.h"
+#include "qemu/cutils.h"
 
 /

[Qemu-devel] [PATCH v4 6/7] hw/isa/lpc_ich9: add broadcast SMI feature

[Laszlo Ersek]

The generic edk2 SMM infrastructure prefers
EFI_SMM_CONTROL2_PROTOCOL.Trigger() to inject an SMI on each processor. If
Trigger() only brings the current processor into SMM, then edk2 handles it
in the following ways:

(1) If Trigger() is executed by the BSP (which is guaranteed before
ExitBootServices(), but is not necessarily true at runtime), then:

(a) If edk2 has been configured for "traditional" SMM synchronization,
then the BSP sends directed SMIs to the APs with APIC delivery,
bringing them into SMM individually. Then the BSP runs the SMI
handler / dispatcher.

(b) If edk2 has been configured for "relaxed" SMM synchronization,
then the APs that are not already in SMM are not brought in, and
the BSP runs the SMI handler / dispatcher.

(2) If Trigger() is executed by an AP (which is possible after
ExitBootServices(), and can be forced e.g. by "taskset -c 1
efibootmgr"), then the AP in question brings in the BSP with a
directed SMI, and the BSP runs the SMI handler / dispatcher.

The smaller problem with (1a) and (2) is that the BSP and AP
synchronization is slow. For example, the "taskset -c 1 efibootmgr"
command from (2) can take more than 3 seconds to complete, because
efibootmgr accesses non-volatile UEFI variables intensively.

The larger problem is that QEMU's current behavior diverges from the
behavior usually seen on physical hardware, and that keeps exposing
obscure corner cases, race conditions and other instabilities in edk2,
which generally expects / prefers a software SMI to affect all CPUs at
once.

Therefore introduce the "broadcast SMI" feature (ICH9_LPC_SMI_F_BROADCAST)
that causes QEMU to inject the SMI on all VCPUs.

While the original posting of this patch

only intended to speed up (2), based on our recent "stress testing" of SMM
this patch actually provides functional improvements.

Cc: "Michael S. Tsirkin" 
Cc: Gerd Hoffmann 
Cc: Igor Mammedov 
Cc: Paolo Bonzini 
Signed-off-by: Laszlo Ersek 
---
 include/hw/i386/ich9.h | 3 +++
 hw/isa/lpc_ich9.c  | 9 -
 2 files changed, 11 insertions(+), 1 deletion(-)

diff --git a/include/hw/i386/ich9.h b/include/hw/i386/ich9.h
index 33142eb37252..e914b3f56fd8 100644
--- a/include/hw/i386/ich9.h
+++ b/include/hw/i386/ich9.h
@@ -248,6 +248,9 @@ Object *ich9_lpc_find(void);
 #define ICH9_SMB_XMIT_SLVA  0x04
 #define ICH9_SMB_HST_D0 0x05
 #define ICH9_SMB_HST_D1 0x06
 #define ICH9_SMB_HOST_BLOCK_DB  0x07
 
+/* bits used in fw_cfg SMI feature negotiation */
+#define ICH9_LPC_SMI_F_BROADCAST   (UINT64_C(1) << 0)
+
 #endif /* HW_ICH9_H */
diff --git a/hw/isa/lpc_ich9.c b/hw/isa/lpc_ich9.c
index ee1fa553bfee..6e9edbe62226 100644
--- a/hw/isa/lpc_ich9.c
+++ b/hw/isa/lpc_ich9.c
@@ -437,11 +437,18 @@ static void ich9_apm_ctrl_changed(uint32_t val, void *arg)
 return;
 }
 
 /* SMI_EN = PMBASE + 30. SMI control and enable register */
 if (lpc->pm.smi_en & ICH9_PMIO_SMI_EN_APMC_EN) {
-cpu_interrupt(current_cpu, CPU_INTERRUPT_SMI);
+if (lpc->smi_negotiated_features & ICH9_LPC_SMI_F_BROADCAST) {
+CPUState *cs;
+CPU_FOREACH(cs) {
+cpu_interrupt(cs, CPU_INTERRUPT_SMI);
+}
+} else {
+cpu_interrupt(current_cpu, CPU_INTERRUPT_SMI);
+}
 }
 }
 
 /* config:PMBASE */
 static void
-- 
2.9.2

[Qemu-devel] [PATCH v4 2/7] fw-cfg: turn FW_CFG_FILE_SLOTS into a device property

[Laszlo Ersek]

We'd like to raise the value of FW_CFG_FILE_SLOTS. Doing it naively could
lead to problems with backward migration: a more recent QEMU (running an
older machine type) would allow the guest, in fw_cfg_select(), to select a
high key value that is unavailable in the same machine type implemented by
the older (target) QEMU. On the target host, fw_cfg_data_read() for
example could dereference nonexistent entries.

As first step, size the FWCfgState.entries[*] and FWCfgState.entry_order
arrays dynamically. All three array sizes will be influenced by the new
field (and device property) FWCfgState.file_slots.

Make the following changes:

- Replace the FW_CFG_FILE_SLOTS macro with FW_CFG_FILE_SLOTS_TRAD
  (traditional count of fw_cfg file slots) in the header file. The value
  remains 0x10.

- Replace all uses of FW_CFG_FILE_SLOTS with a helper function called
  fw_cfg_file_slots(), returning the new property.

- Eliminate the macro FW_CFG_MAX_ENTRY, and replace all its uses with a
  helper function called fw_cfg_max_entry().

- In the MMIO- and IO-mapped realize functions both, allocate all three
  arrays dynamically, based on the new property.

- The new property defaults to 0x20; however at the moment we forcibly set
  it to FW_CFG_FILE_SLOTS_TRAD on all code paths available to board code
  (namely in the fw_cfg_init_io_dma() and fw_cfg_init_mem_wide() helper
  functions). This is going to be customized in the following patches.

Cc: "Gabriel L. Somlo" 
Cc: "Michael S. Tsirkin" 
Cc: Gerd Hoffmann 
Cc: Igor Mammedov 
Cc: Paolo Bonzini 
Signed-off-by: Laszlo Ersek 
---

Notes:
I know that upstream doesn't care about backward migration, but some
downstreams might.

 docs/specs/fw_cfg.txt  |  2 +-
 include/hw/nvram/fw_cfg_keys.h |  3 +-
 hw/nvram/fw_cfg.c  | 85 ++
 3 files changed, 79 insertions(+), 11 deletions(-)

diff --git a/docs/specs/fw_cfg.txt b/docs/specs/fw_cfg.txt
index a19e2adbe1c6..84e2978706f5 100644
--- a/docs/specs/fw_cfg.txt
+++ b/docs/specs/fw_cfg.txt
@@ -154,11 +154,11 @@ Selector Reg.Range Usage
 0x8000 - 0xbfff  Arch. Specific (0x - 0x3fff, generally RO, possibly RW
  through the DMA interface in QEMU v2.9+)
 0xc000 - 0x  Arch. Specific (0x - 0x3fff, RW, ignored in v2.4+)
 
 In practice, the number of allowed firmware configuration items is given
-by the value of FW_CFG_MAX_ENTRY (see fw_cfg.h).
+by the value (FW_CFG_FILE_FIRST + FW_CFG_FILE_SLOTS_TRAD) (see fw_cfg.h).
 
 = Guest-side DMA Interface =
 
 If bit 1 of the feature bitmap is set, the DMA interface is present. This does
 not replace the existing fw_cfg interface, it is an add-on. This interface
diff --git a/include/hw/nvram/fw_cfg_keys.h b/include/hw/nvram/fw_cfg_keys.h
index 0f3e871884c0..627589793671 100644
--- a/include/hw/nvram/fw_cfg_keys.h
+++ b/include/hw/nvram/fw_cfg_keys.h
@@ -27,12 +27,11 @@
 #define FW_CFG_SETUP_SIZE   0x17
 #define FW_CFG_SETUP_DATA   0x18
 #define FW_CFG_FILE_DIR 0x19
 
 #define FW_CFG_FILE_FIRST   0x20
-#define FW_CFG_FILE_SLOTS   0x10
-#define FW_CFG_MAX_ENTRY(FW_CFG_FILE_FIRST + FW_CFG_FILE_SLOTS)
+#define FW_CFG_FILE_SLOTS_TRAD  0x10
 
 #define FW_CFG_WRITE_CHANNEL0x4000
 #define FW_CFG_ARCH_LOCAL   0x8000
 #define FW_CFG_ENTRY_MASK   (~(FW_CFG_WRITE_CHANNEL | FW_CFG_ARCH_LOCAL))
 
diff --git a/hw/nvram/fw_cfg.c b/hw/nvram/fw_cfg.c
index e0145c11a19b..2e1441c09750 100644
--- a/hw/nvram/fw_cfg.c
+++ b/hw/nvram/fw_cfg.c
@@ -31,10 +31,13 @@
 #include "hw/sysbus.h"
 #include "trace.h"
 #include "qemu/error-report.h"
 #include "qemu/config-file.h"
 #include "qemu/cutils.h"
+#include "qapi/error.h"
+
+#define FW_CFG_FILE_SLOTS_DFLT 0x20
 
 #define FW_CFG_NAME "fw_cfg"
 #define FW_CFG_PATH "/machine/" FW_CFG_NAME
 
 #define TYPE_FW_CFG "fw_cfg"
@@ -69,12 +72,13 @@ typedef struct FWCfgEntry {
 struct FWCfgState {
 /*< private >*/
 SysBusDevice parent_obj;
 /*< public >*/
 
-FWCfgEntry entries[2][FW_CFG_MAX_ENTRY];
-int entry_order[FW_CFG_MAX_ENTRY];
+uint32_t file_slots;
+FWCfgEntry *entries[2];
+int *entry_order;
 FWCfgFiles *files;
 uint16_t cur_entry;
 uint32_t cur_offset;
 Notifier machine_ready;
 
@@ -255,17 +259,27 @@ static void fw_cfg_reboot(FWCfgState *s)
 static void fw_cfg_write(FWCfgState *s, uint8_t value)
 {
 /* nothing, write support removed in QEMU v2.4+ */
 }
 
+static inline uint32_t fw_cfg_file_slots(const FWCfgState *s)
+{
+return s->file_slots;
+}
+
+static inline uint32_t fw_cfg_max_entry(const FWCfgState *s)
+{
+return FW_CFG_FILE_FIRST + fw_cfg_file_slots(s);
+}
+
 static int fw_cfg_select(FWCfgState *s, uint16_t key)
 {
 int arch, ret;
 FWCfgEntry *e;
 
 s->cur_offset = 0;
-if ((key & FW_CFG_ENTRY_MASK) >= FW_CFG_MAX_ENTRY) {
+if ((key & FW_CFG_ENTRY_MASK) >= fw_cfg_max_entry(s)) {
 s->cur_entry = FW_CFG_INVALID;
 ret = 0;
 }

[Qemu-devel] [PATCH v4 1/7] fw-cfg: support writeable blobs

[Laszlo Ersek]

From: "Michael S. Tsirkin" 

Useful to send guest data back to QEMU.

Changes from Laszlo Ersek :
- rebase the patch from Michael Tsirkin's original postings at [1] and [2]
  to the following patches:
  - loader: Allow a custom AddressSpace when loading ROMs
  - loader: Add AddressSpace loading support to uImages
  - loader: fix handling of custom address spaces when adding ROM blobs
- reject such writes immediately that would exceed the end of the array,
  rather than performing a partial write before setting the error bit: see
  the (len != dma.length) condition
- document the write interface

[1] http://lists.nongnu.org/archive/html/qemu-devel/2016-02/msg04968.html
[2] http://lists.nongnu.org/archive/html/qemu-devel/2016-03/msg02735.html

Cc: "Gabriel L. Somlo" 
Cc: "Michael S. Tsirkin" 
Cc: Gerd Hoffmann 
Cc: Igor Mammedov 
Cc: Michael Walle 
Cc: Paolo Bonzini 
Cc: Peter Maydell 
Cc: Shannon Zhao 
Cc: qemu-...@nongnu.org
Signed-off-by: Michael S. Tsirkin 
Signed-off-by: Laszlo Ersek 
---
 docs/specs/fw_cfg.txt | 32 +---
 hw/lm32/lm32_hwsetup.h|  2 +-
 include/hw/loader.h   |  7 ---
 include/hw/nvram/fw_cfg.h |  3 ++-
 hw/arm/virt-acpi-build.c  |  2 +-
 hw/core/loader.c  | 18 +++---
 hw/i386/acpi-build.c  |  4 ++--
 hw/nvram/fw_cfg.c | 37 +
 8 files changed, 75 insertions(+), 30 deletions(-)

diff --git a/docs/specs/fw_cfg.txt b/docs/specs/fw_cfg.txt
index 7a5f8c7824ce..a19e2adbe1c6 100644
--- a/docs/specs/fw_cfg.txt
+++ b/docs/specs/fw_cfg.txt
@@ -31,21 +31,25 @@ register. In other words, configuration write mode is 
enabled when
 the selector value is between 0x4000-0x7fff or 0xc000-0x.
 
 NOTE: As of QEMU v2.4, writes to the fw_cfg data register are no
   longer supported, and will be ignored (treated as no-ops)!
 
+NOTE: As of QEMU v2.9, writes are reinstated, but only through the DMA
+  interface (see below). Furthermore, writeability of any specific item is
+  governed independently of Bit14 in the selector key value.
+
 Bit15 of the selector register indicates whether the configuration
 setting is architecture specific. A value of 0 means the item is a
 generic configuration item. A value of 1 means the item is specific
 to a particular architecture. In other words, generic configuration
 items are accessed with a selector value between 0x-0x7fff, and
 architecture specific configuration items are accessed with a selector
 value between 0x8000-0x.
 
 == Data Register ==
 
-* Read/Write (writes ignored as of QEMU v2.4)
+* Read/Write (writes ignored as of QEMU v2.4, but see the DMA interface)
 * Location: platform dependent (IOport [*] or MMIO)
 * Width: 8-bit (if IOport), 8/16/32/64-bit (if MMIO)
 * Endianness: string-preserving
 
 [*] On platforms where the data register is exposed as an IOport, its
@@ -132,23 +136,25 @@ struct FWCfgFile {/* an individual file 
entry, 64 bytes total */
 char name[56]; /* fw_cfg item name, NUL-terminated ascii */
 };
 
 === All Other Data Items ===
 
-Please consult the QEMU source for the most up-to-date and authoritative
-list of selector keys and their respective items' purpose and format.
+Please consult the QEMU source for the most up-to-date and authoritative list
+of selector keys and their respective items' purpose, format and writeability.
 
 === Ranges ===
 
 Theoretically, there may be up to 0x4000 generic firmware configuration
 items, and up to 0x4000 architecturally specific ones.
 
 Selector Reg.Range Usage
 ---  ---
-0x - 0x3fff  Generic (0x - 0x3fff, RO)
+0x - 0x3fff  Generic (0x - 0x3fff, generally RO, possibly RW through
+  the DMA interface in QEMU v2.9+)
 0x4000 - 0x7fff  Generic (0x - 0x3fff, RW, ignored in QEMU v2.4+)
-0x8000 - 0xbfff  Arch. Specific (0x - 0x3fff, RO)
+0x8000 - 0xbfff  Arch. Specific (0x - 0x3fff, generally RO, possibly RW
+ through the DMA interface in QEMU v2.9+)
 0xc000 - 0x  Arch. Specific (0x - 0x3fff, RW, ignored in v2.4+)
 
 In practice, the number of allowed firmware configuration items is given
 by the value of FW_CFG_MAX_ENTRY (see fw_cfg.h).
 
@@ -180,21 +186,31 @@ address is the "control" field.
 The "control" field has the following bits:
  - Bit 0: Error
  - Bit 1: Read
  - Bit 2: Skip
  - Bit 3: Select. The upper 16 bits are the selected index.
+ - Bit 4: Write
 
 When an operation is triggered, if the "control" field has bit 3 set, the
 upper 16 bits are interpreted as an index of a firmware configuration item.
 This has the same effect as writing the selector register.
 
 If the "control" field has bit 1 set, a read operation will be performed.
 "length" bytes for the current selector and offset will be copied into the
 physical RAM address specified by the "address" field.
 
-If the "control" field has bit 2 set (and not bit 1),

[Qemu-devel] [PATCH v4 7/7] hw/i386/pc_q35: advertise broadcast SMI if VCPU hotplug is turned off

[Laszlo Ersek]

For the time being, we cannot handle SMIs in OVMF if VCPUs can show up
after boot. Otherwise, advertise ICH9_LPC_SMI_F_BROADCAST.

Implement this generally, by introducing a new PCMachineClass method,
namely get_smi_host_features(), and implement the above logic for
pc-q35-2.9 and later. The idea is that future machine types might want to
calculate (the same or different) SMI host features from different
information, and that shouldn't affect earlier machine types.

In turn, validating guest feature requests (inter-feature dependencies)
should be possible purely based on the available host feature set. For
example, in the future we might enforce that the guest select
ICH9_LPC_SMI_F_VCPU_PARKING as a prerequisite for
ICH9_LPC_SMI_F_BROADCAST, but only if the machine type itself advertises
ICH9_LPC_SMI_F_VCPU_PARKING.

Cc: "Michael S. Tsirkin" 
Cc: Eduardo Habkost 
Cc: Gerd Hoffmann 
Cc: Igor Mammedov 
Cc: Paolo Bonzini 
Signed-off-by: Laszlo Ersek 
---
 include/hw/i386/pc.h |  1 +
 hw/i386/pc_q35.c | 24 +++-
 2 files changed, 24 insertions(+), 1 deletion(-)

diff --git a/include/hw/i386/pc.h b/include/hw/i386/pc.h
index 430735e501dd..e164947116b6 100644
--- a/include/hw/i386/pc.h
+++ b/include/hw/i386/pc.h
@@ -116,10 +116,11 @@ struct PCMachineClass {
 /*< public >*/
 
 /* Methods: */
 HotplugHandler *(*get_hotplug_handler)(MachineState *machine,
DeviceState *dev);
+uint64_t (*get_smi_host_features)(void);
 
 /* Device configuration: */
 bool pci_enabled;
 bool kvmclock_enabled;
 
diff --git a/hw/i386/pc_q35.c b/hw/i386/pc_q35.c
index eb0953bb6b16..bc1ab48d2c4f 100644
--- a/hw/i386/pc_q35.c
+++ b/hw/i386/pc_q35.c
@@ -228,11 +228,13 @@ static void pc_q35_init(MachineState *machine)
 /* init basic PC hardware */
 pc_basic_device_init(isa_bus, pcms->gsi, &rtc_state, !mc->no_floppy,
  (pcms->vmport != ON_OFF_AUTO_ON), 0xff0104);
 
 /* connect pm stuff to lpc */
-ich9_lpc_pm_init(lpc, pc_machine_is_smm_enabled(pcms), 0);
+ich9_lpc_pm_init(lpc, pc_machine_is_smm_enabled(pcms),
+ pcmc->get_smi_host_features == NULL ? 0 :
+ pcmc->get_smi_host_features());
 
 /* ahci and SATA device, for q35 1 ahci controller is built-in */
 ahci = pci_create_simple_multifunction(host_bus,
PCI_DEVFN(ICH9_SATA1_DEV,
  ICH9_SATA1_FUNC),
@@ -267,10 +269,26 @@ static void pc_q35_init(MachineState *machine)
 nvdimm_init_acpi_state(&pcms->acpi_nvdimm_state, system_io,
pcms->fw_cfg, OBJECT(pcms));
 }
 }
 
+static uint64_t pc_q35_get_smi_host_features(void)
+{
+uint64_t host_features = 0;
+
+/* The host features are computed only at startup, they don't depend on
+ * guest actions. For now we only advertise SMI broadcast if VCPU hot-plug
+ * / hot-unplug are disabled. In the future we might advertise it
+ * unconditionally, but negotiate it only if VCPU hot-plug / hot-unplug are
+ * disabled, or if the guest negotiates another feature bit (VCPU parking).
+ */
+if (smp_cpus == max_cpus) {
+host_features |= ICH9_LPC_SMI_F_BROADCAST;
+}
+return host_features;
+}
+
 #define DEFINE_Q35_MACHINE(suffix, name, compatfn, optionfn) \
 static void pc_init_##suffix(MachineState *machine) \
 { \
 void (*compat)(MachineState *m) = (compatfn); \
 if (compat) { \
@@ -281,19 +299,21 @@ static void pc_q35_init(MachineState *machine)
 DEFINE_PC_MACHINE(suffix, name, pc_init_##suffix, optionfn)
 
 
 static void pc_q35_machine_options(MachineClass *m)
 {
+PCMachineClass *pcmc = PC_MACHINE_CLASS(m);
 m->family = "pc_q35";
 m->desc = "Standard PC (Q35 + ICH9, 2009)";
 m->hot_add_cpu = pc_hot_add_cpu;
 m->units_per_default_bus = 1;
 m->default_machine_opts = "firmware=bios-256k.bin";
 m->default_display = "std";
 m->no_floppy = 1;
 m->has_dynamic_sysbus = true;
 m->max_cpus = 288;
+pcmc->get_smi_host_features = pc_q35_get_smi_host_features;
 }
 
 static void pc_q35_2_9_machine_options(MachineClass *m)
 {
 pc_q35_machine_options(m);
@@ -303,12 +323,14 @@ static void pc_q35_2_9_machine_options(MachineClass *m)
 DEFINE_Q35_MACHINE(v2_9, "pc-q35-2.9", NULL,
pc_q35_2_9_machine_options);
 
 static void pc_q35_2_8_machine_options(MachineClass *m)
 {
+PCMachineClass *pcmc = PC_MACHINE_CLASS(m);
 pc_q35_2_9_machine_options(m);
 m->alias = NULL;
+pcmc->get_smi_host_features = NULL;
 SET_MACHINE_COMPAT(m, PC_COMPAT_2_8);
 }
 
 DEFINE_Q35_MACHINE(v2_8, "pc-q35-2.8", NULL,
pc_q35_2_8_machine_options);
-- 
2.9.2

Re: [Qemu-devel] [PATCH v4 14/64] target-arm: Use new deposit and extract ops

[Alex Bennée]

Richard Henderson  writes:

> Use the new primitives for UBFX and SBFX.
>
> Signed-off-by: Richard Henderson 
> ---
>  target-arm/translate-a64.c | 79 
> +++---
>  target-arm/translate.c | 37 +-
>  2 files changed, 34 insertions(+), 82 deletions(-)
>
> diff --git a/target-arm/translate-a64.c b/target-arm/translate-a64.c
> index de48747..e90487b 100644
> --- a/target-arm/translate-a64.c
> +++ b/target-arm/translate-a64.c
> @@ -3219,67 +3219,40 @@ static void disas_bitfield(DisasContext *s, uint32_t 
> insn)
> low 32-bits anyway.  */
>  tcg_tmp = read_cpu_reg(s, rn, 1);
>
> -/* Recognize the common aliases.  */
> -if (opc == 0) { /* SBFM */
> -if (ri == 0) {
> -if (si == 7) { /* SXTB */
> -tcg_gen_ext8s_i64(tcg_rd, tcg_tmp);
> -goto done;
> -} else if (si == 15) { /* SXTH */
> -tcg_gen_ext16s_i64(tcg_rd, tcg_tmp);
> -goto done;
> -} else if (si == 31) { /* SXTW */
> -tcg_gen_ext32s_i64(tcg_rd, tcg_tmp);
> -goto done;
> -}
> -}
> -if (si == 63 || (si == 31 && ri <= si)) { /* ASR */
> -if (si == 31) {
> -tcg_gen_ext32s_i64(tcg_tmp, tcg_tmp);
> -}
> -tcg_gen_sari_i64(tcg_rd, tcg_tmp, ri);
> +/* Recognize simple(r) extractions.  */
> +if (ri <= si) {
> +int len = (si - ri) + 1;

This is confusing as you have now aliased with len above.

> +if (opc == 0) { /* SBFM: ASR, SBFX, SXTB, SXTH, SXTW */
> +tcg_gen_sextract_i64(tcg_rd, tcg_tmp, ri, len);
>  goto done;
> -}
> -} else if (opc == 2) { /* UBFM */
> -if (ri == 0) { /* UXTB, UXTH, plus non-canonical AND */
> -tcg_gen_andi_i64(tcg_rd, tcg_tmp, bitmask64(si + 1));
> -return;
> -}
> -if (si == 63 || (si == 31 && ri <= si)) { /* LSR */
> -if (si == 31) {
> -tcg_gen_ext32u_i64(tcg_tmp, tcg_tmp);
> -}
> -tcg_gen_shri_i64(tcg_rd, tcg_tmp, ri);
> +} else if (opc == 2) { /* UBFM: UBFX, LSR, UXTB, UXTH */
> +tcg_gen_extract_i64(tcg_rd, tcg_tmp, ri, len);
>  return;
>  }
> -if (si + 1 == ri && si != bitsize - 1) { /* LSL */
> -int shift = bitsize - 1 - si;
> -tcg_gen_shli_i64(tcg_rd, tcg_tmp, shift);
> -goto done;
> -}
>  }
>
> -if (opc != 1) { /* SBFM or UBFM */
> -tcg_gen_movi_i64(tcg_rd, 0);
> -}
> +/* Do the bit move operation.  Note that above we handled ri <= si,
> +   Wd = Wn, via tcg_gen_*extract_i64.  Now we handle
> +   the ri > si case, Wd<32+s-r,32-r> = Wn, via deposit.  */
> +pos = (bitsize - ri) & (bitsize - 1);
> +len = si + 1;

The comment implies this is for the ri > si case but you'll still catch
ri <= si for opc = 1, e.g.:

  0x331168a7  bfxil w7, w5, #17, #10

>
> -/* do the bit move operation */
> -if (si >= ri) {

In fact we seem to have subtly reversed the test here but ri <= si is
not exactly equivalent to si >= ri.

My version is as follows:

/* Recognize simple(r) extractions.  */
if (si >= ri) {
/* Wd = Wn */
len = (si - ri) + 1;
if (opc == 0) { /* SBFM: ASR, SBFX, SXTB, SXTH, SXTW */
tcg_gen_sextract_i64(tcg_rd, tcg_tmp, ri, len);
goto done;
} else if (opc == 2) { /* UBFM: UBFX, LSR, UXTB, UXTH */
tcg_gen_extract_i64(tcg_rd, tcg_tmp, ri, len);
return;
}
/* opc == 1, BXFIL fall through to deposit */
tcg_gen_extract_i64(tcg_tmp, tcg_tmp, ri, len);
pos = 0;
} else {
/* Handle the ri > si case with a deposit
 * Wd<32+s-r,32-r> = Wn
 */
len = si + 1;
pos = (bitsize - ri) & (bitsize - 1);
}

I've tested that with risu and all the bitfield tests seem ok. The full
patch on top of your commit was:

target-arm: fix bxfil case

1 file changed, 13 insertions(+), 9 deletions(-)
target-arm/translate-a64.c | 22 +-

modified   target-arm/translate-a64.c
@@ -3220,8 +3220,9 @@ static void disas_bitfield(DisasContext *s, uint32_t insn)
 tcg_tmp = read_cpu_reg(s, rn, 1);

 /* Recognize simple(r) extractions.  */
-if (ri <= si) {
-int len = (si - ri) + 1;
+if (si >= ri) {
+/* Wd = Wn */
+len = (si - ri) + 1;
 if (opc == 0) { /* SBFM: ASR, SBFX, SXTB, SXTH, SXTW */
 tcg_gen_sextract_i64(tcg_rd, tcg_tmp, ri, len);
 goto done;
@@ -3229,14 +3230,17 @@ static void disas_bitfield(DisasContext *s, uint32_t 
insn)
 tcg_gen_extract_i64(tcg_rd, tcg_tmp, ri, len);
 return;
 }
+/* opc == 1, BXFIL fall through to deposit */
+tcg_gen_extract_i64(tcg_tmp, tcg_tmp, ri, len);
+