Re: [Qemu-devel] [RFC 16/17] ppc: Remove counter-productive "sanity checks" in migration

[Alexey Kardashevskiy]

On 30/10/16 22:12, David Gibson wrote:
> When vmstate for the ppc cpu was introduced in a90db158 "target-ppc:
> Convert ppc cpu savevm to VMStateDescription", several "sanity check"
> fields were included, verifying that certain cpu parameters matched between
> source and destination.
> 
> This turns out not to have been a good idea.  For one thing it's redundant
> with existing checks for a compatible cpu version at either end.  But more
> importantly the insns_flags and insns_flags2 checks actively break things:
> they expose what's essentially an internal TCG implementation detail in the
> migration stream.  That means that when new instruction classes are added
> or rearranged, migration can break.
> 
> This removes these ill-considered sanity checks.
> 
> Signed-off-by: David Gibson 
> ---
>  target-ppc/machine.c | 8 
>  1 file changed, 4 insertions(+), 4 deletions(-)
> 
> diff --git a/target-ppc/machine.c b/target-ppc/machine.c
> index 62b9e94..453ef0a 100644
> --- a/target-ppc/machine.c
> +++ b/target-ppc/machine.c
> @@ -602,10 +602,10 @@ const VMStateDescription vmstate_ppc_cpu = {
>  /* FIXME: access_type? */
>  
>  /* Sanity checking */
> -VMSTATE_UINTTL_EQUAL(env.msr_mask, PowerPCCPU),
> -VMSTATE_UINT64_EQUAL(env.insns_flags, PowerPCCPU),
> -VMSTATE_UINT64_EQUAL(env.insns_flags2, PowerPCCPU),
> -VMSTATE_UINT32_EQUAL(env.nb_BATs, PowerPCCPU),
> +VMSTATE_UNUSED(sizeof(target_ulong) /* msr_mask */
> +   + sizeof(uint64_t) /* insns_flags */
> +   + sizeof(uint64_t) /* insns_flags2 */
> +   + sizeof(uint32_t)), /* nb_BATs */


This breaks migration to older QEMU:

25055@1478238734.537761:vmstate_load_field_error field "env.msr_mask" load
failed, ret = -22



>  VMSTATE_END_OF_LIST()
>  },
>  .subsections = (const VMStateDescription*[]) {
> 


-- 
Alexey

Re: [Qemu-devel] [PULL 15/16] spapr_pci: Add a 64-bit MMIO window

[Alexey Kardashevskiy]

On 17/10/16 13:43, David Gibson wrote:
> On real hardware, and under pHyp, the PCI host bridges on Power machines
> typically advertise two outbound MMIO windows from the guest's physical
> memory space to PCI memory space:
>   - A 32-bit window which maps onto 2GiB..4GiB in the PCI address space
>   - A 64-bit window which maps onto a large region somewhere high in PCI
> address space (traditionally this used an identity mapping from guest
> physical address to PCI address, but that's not always the case)
> 
> The qemu implementation in spapr-pci-host-bridge, however, only supports a
> single outbound MMIO window, however.  At least some Linux versions expect
> the two windows however, so we arranged this window to map onto the PCI
> memory space from 2 GiB..~64 GiB, then advertised it as two contiguous
> windows, the "32-bit" window from 2G..4G and the "64-bit" window from
> 4G..~64G.
> 
> This approach means, however, that the 64G window is not naturally aligned.
> In turn this limits the size of the largest BAR we can map (which does have
> to be naturally aligned) to roughly half of the total window.  With some
> large nVidia GPGPU cards which have huge memory BARs, this is starting to
> be a problem.
> 
> This patch adds true support for separate 32-bit and 64-bit outbound MMIO
> windows to the spapr-pci-host-bridge implementation, each of which can
> be independently configured.  The 32-bit window always maps to 2G.. in PCI
> space, but the PCI address of the 64-bit window can be configured (it
> defaults to the same as the guest physical address).
> 
> So as not to break possible existing configurations, as long as a 64-bit
> window is not specified, a large single window can be specified.  This
> will appear the same way to the guest as the old approach, although it's
> now implemented by two contiguous memory regions rather than a single one.
> 
> For now, this only adds the possibility of 64-bit windows.  The default
> configuration still uses the legacy mode.


This breaks migration to QEMU v2.7, the destination reports:

22901@1478235261.799031:vmstate_load spapr_pci, spapr_pci
22901@1478235261.799040:vmstate_load_field_error field "mem_win_size" load
failed, ret = -22
qemu-hostos1: error while loading state for instance 0x0 of device 'spapr_pci'
22901@1478235261.801324:migrate_set_state new state 7
qemu-hostos1: load of migration failed: Invalid argument


mem_win_size decreased from 0xf8000 to 0x8000.

I'd think it should be allowed to migrate like this.


The source PHB is:

(qemu) info qtree
bus: main-system-bus
  type System
  dev: spapr-pci-host-bridge, id ""
index = 0 (0x0)
buid = 576460752840294400 (0x8002000)
liobn = 2147483648 (0x8000)
liobn64 = 4294967295 (0x)
mem_win_addr = 1102195982336 (0x100a000)
mem_win_size = 2147483648 (0x8000)
mem64_win_addr = 1104343465984 (0x1012000)
mem64_win_size = 64424509440 (0xf)
mem64_win_pciaddr = 4294967296 (0x1)


The destination PHB is:

(qemu) info qtree
bus: main-system-bus
  type System
  dev: spapr-pci-host-bridge, id ""
index = 0 (0x0)
buid = 576460752840294400 (0x8002000)
liobn = 2147483648 (0x8000)
liobn64 = 4294967295 (0x)
mem_win_addr = 1102195982336 (0x100a000)
mem_win_size = 66571993088 (0xf8000)



The source QEMU cmdline:

/home/aik/p/qemu/ppc64-softmmu/qemu-system-ppc64 -nodefaults \
-chardev stdio,id=STDIO0,signal=off,mux=on \
-device spapr-vty,id=svty0,chardev=STDIO0,reg=0x71000100 \
-mon id=MON0,chardev=STDIO0,mode=readline -nographic -vga none \
-kernel /home/aik/t/vml450le \
-initrd /home/aik/t/le.cpio -m 4G \
-machine pseries-2.6 -enable-kvm \


The destination (./qemu-hostos1 is v2.7.0 from
https://github.com/open-power-host-os/qemu/commits/hostos-stable )

./qemu-hostos1 -nodefaults \
-chardev stdio,id=STDIO0,signal=off,mux=on \
-device spapr-vty,id=svty0,chardev=STDIO0,reg=0x71000100 \
-mon id=MON0,chardev=STDIO0,mode=readline -nographic -vga none -m 4G \
-machine pseries-2.6 -enable-kvm \
-mon chardev=SOCKET0,mode=readline -incoming "tcp:fstn1:2"



> 
> Signed-off-by: David Gibson 
> Reviewed-by: Laurent Vivier 
> ---
>  hw/ppc/spapr.c  | 10 +--
>  hw/ppc/spapr_pci.c  | 70 
> -
>  include/hw/pci-host/spapr.h |  8 --
>  include/hw/ppc/spapr.h  |  3 +-
>  4 files changed, 72 insertions(+), 19 deletions(-)
> 
> diff --git a/hw/ppc/spapr.c b/hw/ppc/spapr.c
> index d747e58..ea5d0e6 100644
> --- a/hw/ppc/spapr.c
> +++ b/hw/ppc/spapr.c
> @@ -2371,7 +2371,8 @@ static HotpluggableCPUList 
> *spapr_query_hotpluggable_cpus(MachineState *machine)
>  }
>  
>  static void spapr_phb_placement(sPAPRMachineState *spapr, uint32_t index,
> -uint64_t *buid, hwaddr *pio, hwaddr *mmio,
> +uint64_t *buid, 

Re: [Qemu-devel] Migration dirty bitmap: should only mark pages as dirty after they have been sent

[Li, Liang Z]

> > > > > > > I think this is "very" wasteful. Assume the workload writes
> > > > > > > the pages
> > > dirty randomly within the guest address space, and the transfer
> > > speed is constant. Intuitively, I think nearly half of the dirty
> > > pages produced in Iteration 1 is not really dirty. This means the
> > > time of Iteration 2 is double of that to send only really dirty pages.
> > > > > >
> > > > > > It makes sense, can you get some perf numbers to show what
> > > > > > kinds of workloads get impacted the most?  That would also
> > > > > > help us to figure out what kinds of speed improvements we can
> expect.
> > > > > >
> > > > > >
> > > > > > Amit
> > > > >
> > > > > I have picked up 6 workloads and got the following statistics
> > > > > numbers of every iteration (except the last stop-copy one) during
> precopy.
> > > > > These numbers are obtained with the basic precopy migration,
> > > > > without the capabilities like xbzrle or compression, etc. The
> > > > > network for the migration is exclusive, with a separate network for
> the workloads.
> > > > > They are both gigabit ethernet. I use qemu-2.5.1.
> > > > >
> > > > > Three (booting, idle, web server) of them converged to the
> > > > > stop-copy
> > > phase,
> > > > > with the given bandwidth and default downtime (300ms), while the
> > > > > other three (kernel compilation, zeusmp, memcached) did not.
> > > > >
> > > > > One page is "not-really-dirty", if it is written first and is
> > > > > sent later (and not written again after that) during one
> > > > > iteration. I guess this would not happen so often during the
> > > > > other iterations as during the 1st iteration. Because all the
> > > > > pages of the VM are sent to the dest node
> > > during
> > > > > the 1st iteration, while during the others, only part of the pages are
> sent.
> > > > > So I think the "not-really-dirty" pages should be produced
> > > > > mainly during the 1st iteration , and maybe very little during the 
> > > > > other
> iterations.
> > > > >
> > > > > If we could avoid resending the "not-really-dirty" pages,
> > > > > intuitively, I think the time spent on Iteration 2 would be
> > > > > halved. This is a chain
> > > reaction,
> > > > > because the dirty pages produced during Iteration 2 is halved,
> > > > > which
> > > incurs
> > > > > that the time spent on Iteration 3 is halved, then Iteration 4, 5...
> > > >
> > > > Yes; these numbers don't show how many of them are false dirty
> though.
> > > >
> > > > One problem is thinking about pages that have been redirtied, if
> > > > the page is
> > > dirtied
> > > > after the sync but before the network write then it's the
> > > > false-dirty that you're describing.
> > > >
> > > > However, if the page is being written a few times, and so it would
> > > > have
> > > been written
> > > > after the network write then it isn't a false-dirty.
> > > >
> > > > You might be able to figure that out with some kernel tracing of
> > > > when the
> > > dirtying
> > > > happens, but it might be easier to write the fix!
> > > >
> > > > Dave
> > >
> > > Hi, I have made some new progress now.
> > >
> > > To tell how many false dirty pages there are exactly in each
> > > iteration, I malloc a buffer in memory as big as the size of the
> > > whole VM memory. When a page is transferred to the dest node, it is
> > > copied to the buffer; During the next iteration, if one page is
> > > transferred, it is compared to the old one in the buffer, and the
> > > old one will be replaced for next comparison if it is really dirty.
> > > Thus, we are now able to get the exact number of false dirty pages.
> > >
> > > This time, I use 15 workloads to get the statistic number. They are:
> > >
> > >   1. 11 benchmarks picked up from cpu2006 benchmark suit. They are
> > > all scientific
> > >  computing workloads like Quantum Chromodynamics, Fluid Dynamics,
> etc.
> > > I pick
> > >  up these 11 benchmarks because compared to others, they have
> > > bigger memory
> > >  occupation and higher memory dirty rate. Thus most of them
> > > could not converge
> > >  to stop-and-copy using the default migration speed (32MB/s).
> > >   2. kernel compilation
> > >   3. idle VM
> > >   4. Apache web server which serves static content
> > >
> > >   (the above workloads are all running in VM with 1 vcpu and 1GB
> > > memory, and the
> > >migration speed is the default 32MB/s)
> > >
> > >   5. Memcached. The VM has 6 cpu cores and 6GB memory, and 4GB are
> > > used as the cache.
> > >  After filling up the 4GB cache, a client writes the cache at a 
> > > constant
> speed
> > >  during migration. This time, migration speed has no limit, and is up 
> > > to
> the
> > >  capability of 1Gbps Ethernet.
> > >
> > > Summarize the results first: (and you can read the precise number
> > > below)
> > >
> > >   1. 4 of these 15 workloads have a big proportion (>60%, even >80%
> > > during some iterations)
> > >  of false 

Re: [Qemu-devel] [PATCH v5 0/5] nvdimm: hotplug support

[Michael S. Tsirkin]

On Fri, Nov 04, 2016 at 06:01:54AM +0200, Michael S. Tsirkin wrote:
> On Fri, Nov 04, 2016 at 11:50:19AM +0800, Xiao Guangrong wrote:
> > 
> > 
> > On 11/04/2016 02:36 AM, Xiao Guangrong wrote:
> > > Hi Michael,
> > > 
> > > This patchset can replace the patches from [PULL 36/47] to [PULL 39/47]
> > > in your pull request:
> > > [PULL 36/47] nvdimm acpi: prebuild nvdimm devices for available slots
> > > [PULL 37/47] nvdimm acpi: introduce fit buffer
> > > [PULL 38/47] nvdimm acpi: introduce _FIT
> > > [PULL 39/47] pc: memhp: enable nvdimm device hotplug
> > > 
> > > Thanks for your patience also thank Igor and Stefan for their review.
> > 
> > Hi,
> > 
> > As the pull request has been upstream (Cool! :)), i will post
> > diff changes based on that.
> > 
> > Thanks!
> 
> Igor prefers seeing revert+patches, I prefer seeing a diff.
> Can you send both? A global diff would be ok for me
> as it's small and easy enough to generate.

Stefan, I wonder what's easier for you to review?

> 
> -- 
> MST

Re: [Qemu-devel] [PATCH v5 0/5] nvdimm: hotplug support

[Michael S. Tsirkin]

On Fri, Nov 04, 2016 at 11:50:19AM +0800, Xiao Guangrong wrote:
> 
> 
> On 11/04/2016 02:36 AM, Xiao Guangrong wrote:
> > Hi Michael,
> > 
> > This patchset can replace the patches from [PULL 36/47] to [PULL 39/47]
> > in your pull request:
> > [PULL 36/47] nvdimm acpi: prebuild nvdimm devices for available slots
> > [PULL 37/47] nvdimm acpi: introduce fit buffer
> > [PULL 38/47] nvdimm acpi: introduce _FIT
> > [PULL 39/47] pc: memhp: enable nvdimm device hotplug
> > 
> > Thanks for your patience also thank Igor and Stefan for their review.
> 
> Hi,
> 
> As the pull request has been upstream (Cool! :)), i will post
> diff changes based on that.
> 
> Thanks!

Igor prefers seeing revert+patches, I prefer seeing a diff.
Can you send both? A global diff would be ok for me
as it's small and easy enough to generate.


-- 
MST

Re: [Qemu-devel] [RFC 11/17] ppc: Add ppc_set_compat_all()

[Alexey Kardashevskiy]

On 30/10/16 22:12, David Gibson wrote:
> Once a compatiblity mode is negotiated with the guest,
> h_client_architecture_support() uses run_on_cpu() to update each CPU to
> the new mode.  We're going to want this logic somewhere else shortly,
> so make a helper function to do this global update.
> 
> We put it in target-ppc/compat.c - it makes as much sense at the CPU level
> as it does at the machine level.  We also move the cpu_synchronize_state()
> into ppc_set_compat(), since it doesn't really make any sense to call that
> without synchronizing state.
> 
> Signed-off-by: David Gibson 
> ---
>  hw/ppc/spapr_hcall.c | 31 +--
>  target-ppc/compat.c  | 36 
>  target-ppc/cpu.h |  3 +++
>  3 files changed, 44 insertions(+), 26 deletions(-)
> 
> diff --git a/hw/ppc/spapr_hcall.c b/hw/ppc/spapr_hcall.c
> index 3bd6d06..4eaf9a6 100644
> --- a/hw/ppc/spapr_hcall.c
> +++ b/hw/ppc/spapr_hcall.c
> @@ -881,20 +881,6 @@ static target_ulong h_set_mode(PowerPCCPU *cpu, 
> sPAPRMachineState *spapr,
>  return ret;
>  }
>  
> -typedef struct {
> -uint32_t compat_pvr;
> -Error *err;
> -} SetCompatState;
> -
> -static void do_set_compat(CPUState *cs, void *arg)
> -{
> -PowerPCCPU *cpu = POWERPC_CPU(cs);
> -SetCompatState *s = arg;
> -
> -cpu_synchronize_state(cs);
> -ppc_set_compat(cpu, s->compat_pvr, >err);
> -}
> -
>  static target_ulong h_client_architecture_support(PowerPCCPU *cpu,
>sPAPRMachineState *spapr,
>target_ulong opcode,
> @@ -902,7 +888,6 @@ static target_ulong 
> h_client_architecture_support(PowerPCCPU *cpu,
>  {
>  target_ulong list = ppc64_phys_to_real(args[0]);
>  target_ulong ov_table;
> -CPUState *cs;
>  bool explicit_match = false; /* Matched the CPU's real PVR */
>  uint32_t max_compat = cpu->max_compat;
>  uint32_t best_compat = 0;
> @@ -949,18 +934,12 @@ static target_ulong 
> h_client_architecture_support(PowerPCCPU *cpu,
>  
>  /* Update CPUs */
>  if (cpu->compat_pvr != best_compat) {
> -CPU_FOREACH(cs) {
> -SetCompatState s = {
> -.compat_pvr = best_compat,
> -.err = NULL,
> -};
> +Error *local_err = NULL;
>  
> -run_on_cpu(cs, do_set_compat, );
> -
> -if (s.err) {
> -error_report_err(s.err);
> -return H_HARDWARE;
> -}
> +ppc_set_compat_all(best_compat, _err);
> +if (local_err) {
> +error_report_err(local_err);
> +return H_HARDWARE;
>  }
>  }
>  
> diff --git a/target-ppc/compat.c b/target-ppc/compat.c
> index 1059555..0b12b58 100644
> --- a/target-ppc/compat.c
> +++ b/target-ppc/compat.c
> @@ -124,6 +124,8 @@ void ppc_set_compat(PowerPCCPU *cpu, uint32_t compat_pvr, 
> Error **errp)
>  pcr = compat->pcr;
>  }
>  
> +cpu_synchronize_state(CPU(cpu));
> +
>  cpu->compat_pvr = compat_pvr;
>  env->spr[SPR_PCR] = pcr & pcc->pcr_mask;
>  
> @@ -136,6 +138,40 @@ void ppc_set_compat(PowerPCCPU *cpu, uint32_t 
> compat_pvr, Error **errp)
>  }
>  }
>  
> +#if !defined(CONFIG_USER_ONLY)
> +typedef struct {
> +uint32_t compat_pvr;
> +Error *err;
> +} SetCompatState;
> +
> +static void do_set_compat(CPUState *cs, void *arg)
> +{
> +PowerPCCPU *cpu = POWERPC_CPU(cs);
> +SetCompatState *s = arg;
> +
> +ppc_set_compat(cpu, s->compat_pvr, >err);
> +}
> +
> +void ppc_set_compat_all(uint32_t compat_pvr, Error **errp)
> +{
> +CPUState *cs;
> +
> +CPU_FOREACH(cs) {
> +SetCompatState s = {
> +.compat_pvr = compat_pvr,
> +.err = NULL,
> +};
> +
> +run_on_cpu(cs, do_set_compat, );
> +
> +if (s.err) {
> +error_propagate(errp, s.err);
> +return;
> +}
> +}
> +}
> +#endif
> +
>  int ppc_compat_max_threads(PowerPCCPU *cpu)
>  {
>  const CompatInfo *compat = compat_by_pvr(cpu->compat_pvr);
> diff --git a/target-ppc/cpu.h b/target-ppc/cpu.h
> index 91e8be8..201a655 100644
> --- a/target-ppc/cpu.h
> +++ b/target-ppc/cpu.h
> @@ -1317,6 +1317,9 @@ static inline int cpu_mmu_index (CPUPPCState *env, bool 
> ifetch)
>  bool ppc_check_compat(PowerPCCPU *cpu, uint32_t compat_pvr,
>uint32_t min_compat_pvr, uint32_t max_compat_pvr);
>  void ppc_set_compat(PowerPCCPU *cpu, uint32_t compat_pvr, Error **errp);
> +#if !defined(CONFIG_USER_ONLY)
> +void ppc_set_compat_all(uint32_t compat_pvr, Error **errp);
> +#endif

I would put all ppc*compat*() under #if defined(CONFIG_USER_ONLY) &&
defined(TARGET_PPC64) (or even moved this to target-ppc/Makefile.objs).
Otherwise, functions like ppc_check_compat() have #if
!defined(CONFIG_USER_ONLY) which suggests that the rest of
ppc_check_compat() can actually be executed in 

Re: [Qemu-devel] [PATCH v5 0/5] nvdimm: hotplug support

[Xiao Guangrong]

On 11/04/2016 02:36 AM, Xiao Guangrong wrote:

Hi Michael,

This patchset can replace the patches from [PULL 36/47] to [PULL 39/47]
in your pull request:
[PULL 36/47] nvdimm acpi: prebuild nvdimm devices for available slots
[PULL 37/47] nvdimm acpi: introduce fit buffer
[PULL 38/47] nvdimm acpi: introduce _FIT
[PULL 39/47] pc: memhp: enable nvdimm device hotplug

Thanks for your patience also thank Igor and Stefan for their review.


Hi,

As the pull request has been upstream (Cool! :)), i will post
diff changes based on that.

Thanks!

Re: [Qemu-devel] [RFC 09/17] ppc: Validate compatibility modes when setting

[Alexey Kardashevskiy]

On 31/10/16 19:39, David Gibson wrote:
> On Mon, Oct 31, 2016 at 04:55:42PM +1100, Alexey Kardashevskiy wrote:
>> On 30/10/16 22:12, David Gibson wrote:
>>> Current ppc_set_compat() will attempt to set any compatiblity mode
>>> specified, regardless of whether it's available on the CPU.  The caller is
>>> expected to make sure it is setting a possible mode, which is awkwward
>>> because most of the information to make that decision is at the CPU level.
>>>
>>> This begins to clean this up by introducing a ppc_check_compat() function
>>> which will determine if a given compatiblity mode is supported on a CPU
>>> (and also whether it lies within specified minimum and maximum compat
>>> levels, which will be useful later).  It also contains an assertion that
>>> the CPU has a "virtual hypervisor"[1], that is, that the guest isn't
>>> permitted to execute hypervisor privilege code.  Without that, the guest
>>> would own the PCR and so could override any mode set here.  Only machine
>>> types which use a virtual hypervisor (i.e. 'pseries') should use
>>> ppc_check_compat().
>>>
>>> ppc_set_compat() is modified to validate the compatibility mode it is given
>>> and fail if it's not available on this CPU.
>>>
>>> [1] Or user-only mode, which also obviously doesn't allow access to the
>>> hypervisor privileged PCR.  We don't use that now, but could in future.
>>>
>>> Signed-off-by: David Gibson 
>>> ---
>>>  target-ppc/compat.c | 41 +
>>>  target-ppc/cpu.h|  2 ++
>>>  2 files changed, 43 insertions(+)
>>>
>>> diff --git a/target-ppc/compat.c b/target-ppc/compat.c
>>> index 66529a6..1059555 100644
>>> --- a/target-ppc/compat.c
>>> +++ b/target-ppc/compat.c
>>> @@ -28,29 +28,37 @@
>>>  typedef struct {
>>>  uint32_t pvr;
>>>  uint64_t pcr;
>>> +uint64_t pcr_level;
>>>  int max_threads;
>>>  } CompatInfo;
>>>  
>>>  static const CompatInfo compat_table[] = {
>>> +/*
>>> + * Ordered from oldest to newest - the code relies on this

In last 5+ years, I have never seen pointer compared anyhow but using "=="
and "!=". A bit unusual.


Reviewed-by: Alexey Kardashevskiy 





>>> + */
>>>  { /* POWER6, ISA2.05 */
>>>  .pvr = CPU_POWERPC_LOGICAL_2_05,
>>>  .pcr = PCR_COMPAT_2_07 | PCR_COMPAT_2_06 | PCR_COMPAT_2_05
>>> | PCR_TM_DIS | PCR_VSX_DIS,
>>> +.pcr_level = PCR_COMPAT_2_05,
>>>  .max_threads = 2,
>>>  },
>>>  { /* POWER7, ISA2.06 */
>>>  .pvr = CPU_POWERPC_LOGICAL_2_06,
>>>  .pcr = PCR_COMPAT_2_07 | PCR_COMPAT_2_06 | PCR_TM_DIS,
>>> +.pcr_level = PCR_COMPAT_2_06,
>>>  .max_threads = 4,
>>>  },
>>>  {
>>>  .pvr = CPU_POWERPC_LOGICAL_2_06_PLUS,
>>>  .pcr = PCR_COMPAT_2_07 | PCR_COMPAT_2_06 | PCR_TM_DIS,
>>> +.pcr_level = PCR_COMPAT_2_06,
>>>  .max_threads = 4,
>>>  },
>>>  { /* POWER8, ISA2.07 */
>>>  .pvr = CPU_POWERPC_LOGICAL_2_07,
>>>  .pcr = PCR_COMPAT_2_07,
>>> +.pcr_level = PCR_COMPAT_2_07,
>>>  .max_threads = 8,
>>>  },
>>>  };
>>> @@ -67,6 +75,35 @@ static const CompatInfo *compat_by_pvr(uint32_t pvr)
>>>  return NULL;
>>>  }
>>>  
>>> +bool ppc_check_compat(PowerPCCPU *cpu, uint32_t compat_pvr,
>>> +  uint32_t min_compat_pvr, uint32_t max_compat_pvr)
>>> +{
>>> +PowerPCCPUClass *pcc = POWERPC_CPU_GET_CLASS(cpu);
>>> +const CompatInfo *compat = compat_by_pvr(compat_pvr);
>>> +const CompatInfo *min = compat_by_pvr(min_compat_pvr);
>>> +const CompatInfo *max = compat_by_pvr(max_compat_pvr);
>>
>>
>> You keep giving very generic names (as "min" and "max") to local
>> variables ;)
> 
> For local variables, brevity is a virtue.





-- 
Alexey



signature.asc
Description: OpenPGP digital signature

Re: [Qemu-devel] [RFC 08/17] ppc: Rewrite ppc_get_compat_smt_threads()

[Alexey Kardashevskiy]

On 30/10/16 22:11, David Gibson wrote:
> To continue consolidation of compatibility mode information, this rewrites
> the ppc_get_compat_smt_threads() function using the table of compatiblity
> modes in target-ppc/compat.c.
> 
> It's not a direct replacement, the new ppc_compat_max_threads() function
> has simpler semantics - it just returns the number of threads the cpu
> model has, taking into account any compatiblity mode it is in.
> 
> This no longer takes into account kvmppc_smt_threads() as the previous
> version did.  That check wasn't useful because we check elsewhere that

Nit: s/elsewhere/in ppc_cpu_realizefn()/


Reviewed-by: Alexey Kardashevskiy 




> CPUs aren't instantiated with more threads than kvm allows (or if we didn't
> things will already be broken and this won't make it any worse).
> 
> Signed-off-by: David Gibson 
> ---
>  hw/ppc/spapr.c  |  8 
>  target-ppc/compat.c | 18 ++
>  target-ppc/cpu.h|  2 +-
>  target-ppc/translate_init.c | 20 
>  4 files changed, 23 insertions(+), 25 deletions(-)
> 
> diff --git a/hw/ppc/spapr.c b/hw/ppc/spapr.c
> index 276cefa..6c78889 100644
> --- a/hw/ppc/spapr.c
> +++ b/hw/ppc/spapr.c
> @@ -207,6 +207,7 @@ static int spapr_fixup_cpu_dt(void *fdt, 
> sPAPRMachineState *spapr)
>  PowerPCCPU *cpu = POWERPC_CPU(cs);
>  DeviceClass *dc = DEVICE_GET_CLASS(cs);
>  int index = ppc_get_vcpu_dt_id(cpu);
> +int compat_smt = MIN(smp_threads, ppc_compat_max_threads(cpu));
>  
>  if ((index % smt) != 0) {
>  continue;
> @@ -241,8 +242,7 @@ static int spapr_fixup_cpu_dt(void *fdt, 
> sPAPRMachineState *spapr)
>  return ret;
>  }
>  
> -ret = spapr_fixup_cpu_smt_dt(fdt, offset, cpu,
> - ppc_get_compat_smt_threads(cpu));
> +ret = spapr_fixup_cpu_smt_dt(fdt, offset, cpu, compat_smt);
>  if (ret < 0) {
>  return ret;
>  }
> @@ -408,6 +408,7 @@ static void spapr_populate_cpu_dt(CPUState *cs, void 
> *fdt, int offset,
>  size_t page_sizes_prop_size;
>  uint32_t vcpus_per_socket = smp_threads * smp_cores;
>  uint32_t pft_size_prop[] = {0, cpu_to_be32(spapr->htab_shift)};
> +int compat_smt = MIN(smp_threads, ppc_compat_max_threads(cpu));
>  sPAPRDRConnector *drc;
>  sPAPRDRConnectorClass *drck;
>  int drc_index;
> @@ -495,8 +496,7 @@ static void spapr_populate_cpu_dt(CPUState *cs, void 
> *fdt, int offset,
>  
>  _FDT(spapr_fixup_cpu_numa_dt(fdt, offset, cs));
>  
> -_FDT(spapr_fixup_cpu_smt_dt(fdt, offset, cpu,
> -ppc_get_compat_smt_threads(cpu)));
> +_FDT(spapr_fixup_cpu_smt_dt(fdt, offset, cpu, compat_smt));
>  }
>  
>  static void spapr_populate_cpus_dt_node(void *fdt, sPAPRMachineState *spapr)
> diff --git a/target-ppc/compat.c b/target-ppc/compat.c
> index f3fd9c6..66529a6 100644
> --- a/target-ppc/compat.c
> +++ b/target-ppc/compat.c
> @@ -28,6 +28,7 @@
>  typedef struct {
>  uint32_t pvr;
>  uint64_t pcr;
> +int max_threads;
>  } CompatInfo;
>  
>  static const CompatInfo compat_table[] = {
> @@ -35,18 +36,22 @@ static const CompatInfo compat_table[] = {
>  .pvr = CPU_POWERPC_LOGICAL_2_05,
>  .pcr = PCR_COMPAT_2_07 | PCR_COMPAT_2_06 | PCR_COMPAT_2_05
> | PCR_TM_DIS | PCR_VSX_DIS,
> +.max_threads = 2,
>  },
>  { /* POWER7, ISA2.06 */
>  .pvr = CPU_POWERPC_LOGICAL_2_06,
>  .pcr = PCR_COMPAT_2_07 | PCR_COMPAT_2_06 | PCR_TM_DIS,
> +.max_threads = 4,
>  },
>  {
>  .pvr = CPU_POWERPC_LOGICAL_2_06_PLUS,
>  .pcr = PCR_COMPAT_2_07 | PCR_COMPAT_2_06 | PCR_TM_DIS,
> +.max_threads = 4,
>  },
>  { /* POWER8, ISA2.07 */
>  .pvr = CPU_POWERPC_LOGICAL_2_07,
>  .pcr = PCR_COMPAT_2_07,
> +.max_threads = 8,
>  },
>  };
>  
> @@ -89,3 +94,16 @@ void ppc_set_compat(PowerPCCPU *cpu, uint32_t compat_pvr, 
> Error **errp)
>  }
>  }
>  }
> +
> +int ppc_compat_max_threads(PowerPCCPU *cpu)
> +{
> +const CompatInfo *compat = compat_by_pvr(cpu->compat_pvr);
> +int n_threads = CPU(cpu)->nr_threads;
> +
> +if (cpu->compat_pvr) {
> +g_assert(compat);
> +n_threads = MIN(n_threads, compat->max_threads);
> +}
> +
> +return n_threads;
> +}
> diff --git a/target-ppc/cpu.h b/target-ppc/cpu.h
> index 15d5e4b..cfda7b2 100644
> --- a/target-ppc/cpu.h
> +++ b/target-ppc/cpu.h
> @@ -1241,7 +1241,6 @@ void ppc_store_sdr1 (CPUPPCState *env, target_ulong 
> value);
>  void ppc_store_msr (CPUPPCState *env, target_ulong value);
>  
>  void ppc_cpu_list (FILE *f, fprintf_function cpu_fprintf);
> -int ppc_get_compat_smt_threads(PowerPCCPU *cpu);
>  #if defined(TARGET_PPC64)
>  #endif
>  
> @@ -1316,6 +1315,7 @@ static inline int cpu_mmu_index (CPUPPCState *env, bool 
> ifetch)
>  

Re: [Qemu-devel] Migration dirty bitmap: should only mark pages as dirty after they have been sent

[Chunguang Li]

> -Original Messages-
> From: "Li, Liang Z" 
> Sent Time: Thursday, November 3, 2016
> To: "Chunguang Li" , "Dr. David Alan Gilbert" 
> 
> Cc: "Amit Shah" , "pbonz...@redhat.com" 
> , "qemu-devel@nongnu.org" , 
> "stefa...@redhat.com" , "quint...@redhat.com" 
> 
> Subject: RE: [Qemu-devel] Migration dirty bitmap: should only mark pages as 
> dirty after they have been sent
> 
> > > > > > I think this is "very" wasteful. Assume the workload writes the 
> > > > > > pages
> > dirty randomly within the guest address space, and the transfer speed is
> > constant. Intuitively, I think nearly half of the dirty pages produced in
> > Iteration 1 is not really dirty. This means the time of Iteration 2 is 
> > double of
> > that to send only really dirty pages.
> > > > >
> > > > > It makes sense, can you get some perf numbers to show what kinds of
> > > > > workloads get impacted the most?  That would also help us to figure
> > > > > out what kinds of speed improvements we can expect.
> > > > >
> > > > >
> > > > >   Amit
> > > >
> > > > I have picked up 6 workloads and got the following statistics numbers
> > > > of every iteration (except the last stop-copy one) during precopy.
> > > > These numbers are obtained with the basic precopy migration, without
> > > > the capabilities like xbzrle or compression, etc. The network for the
> > > > migration is exclusive, with a separate network for the workloads.
> > > > They are both gigabit ethernet. I use qemu-2.5.1.
> > > >
> > > > Three (booting, idle, web server) of them converged to the stop-copy
> > phase,
> > > > with the given bandwidth and default downtime (300ms), while the other
> > > > three (kernel compilation, zeusmp, memcached) did not.
> > > >
> > > > One page is "not-really-dirty", if it is written first and is sent later
> > > > (and not written again after that) during one iteration. I guess this
> > > > would not happen so often during the other iterations as during the 1st
> > > > iteration. Because all the pages of the VM are sent to the dest node
> > during
> > > > the 1st iteration, while during the others, only part of the pages are 
> > > > sent.
> > > > So I think the "not-really-dirty" pages should be produced mainly during
> > > > the 1st iteration , and maybe very little during the other iterations.
> > > >
> > > > If we could avoid resending the "not-really-dirty" pages, intuitively, I
> > > > think the time spent on Iteration 2 would be halved. This is a chain
> > reaction,
> > > > because the dirty pages produced during Iteration 2 is halved, which
> > incurs
> > > > that the time spent on Iteration 3 is halved, then Iteration 4, 5...
> > >
> > > Yes; these numbers don't show how many of them are false dirty though.
> > >
> > > One problem is thinking about pages that have been redirtied, if the page 
> > > is
> > dirtied
> > > after the sync but before the network write then it's the false-dirty that
> > > you're describing.
> > >
> > > However, if the page is being written a few times, and so it would have
> > been written
> > > after the network write then it isn't a false-dirty.
> > >
> > > You might be able to figure that out with some kernel tracing of when the
> > dirtying
> > > happens, but it might be easier to write the fix!
> > >
> > > Dave
> > 
> > Hi, I have made some new progress now.
> > 
> > To tell how many false dirty pages there are exactly in each iteration, I 
> > malloc
> > a
> > buffer in memory as big as the size of the whole VM memory. When a page
> > is
> > transferred to the dest node, it is copied to the buffer; During the next
> > iteration,
> > if one page is transferred, it is compared to the old one in the buffer, 
> > and the
> > old one will be replaced for next comparison if it is really dirty. Thus, 
> > we are
> > now
> > able to get the exact number of false dirty pages.
> > 
> > This time, I use 15 workloads to get the statistic number. They are:
> > 
> >   1. 11 benchmarks picked up from cpu2006 benchmark suit. They are all
> > scientific
> >  computing workloads like Quantum Chromodynamics, Fluid Dynamics, etc.
> > I pick
> >  up these 11 benchmarks because compared to others, they have bigger
> > memory
> >  occupation and higher memory dirty rate. Thus most of them could not
> > converge
> >  to stop-and-copy using the default migration speed (32MB/s).
> >   2. kernel compilation
> >   3. idle VM
> >   4. Apache web server which serves static content
> > 
> >   (the above workloads are all running in VM with 1 vcpu and 1GB memory,
> > and the
> >migration speed is the default 32MB/s)
> > 
> >   5. Memcached. The VM has 6 cpu cores and 6GB memory, and 4GB are used
> > as the cache.
> >  After filling up the 4GB cache, a client writes the cache at a 
> > constant speed
> >  

Re: [Qemu-devel] [PATCH v5 03/10] pci: Convert msix_init() to Error and fix callers to check it

[Cao jin]

On 11/03/2016 07:38 PM, Marcel Apfelbaum wrote:

On 11/03/2016 06:06 AM, Cao jin wrote:






[...]


diff --git a/hw/scsi/megasas.c b/hw/scsi/megasas.c
index 52a4123..fada834 100644
--- a/hw/scsi/megasas.c
+++ b/hw/scsi/megasas.c
@@ -2360,9 +2360,12 @@ static void megasas_scsi_realize(PCIDevice
*dev, Error **errp)

 if (megasas_use_msix(s) &&
 msix_init(dev, 15, >mmio_io, b->mmio_bar, 0x2000,
-  >mmio_io, b->mmio_bar, 0x3800, 0x68)) {
+  >mmio_io, b->mmio_bar, 0x3800, 0x68, )) {
+/*TODO: check msix_init's error, and should fail on msix=on */


Why this "TODO", can't we do something similar to other changes already
done in this patch?



The 1st version of this series handles the error in this patch. look at 
the comments:


http://lists.nongnu.org/archive/html/qemu-devel/2016-08/msg03192.html

*First convert msix_init() without changing behavior, by having every 
caller of msix_init() immediately pass the error received to 
error_report_err().  Then clean up the callers one after the other.*


So later, this patch looks like what it is now. I feel it also make this 
patch thinner, easier to review.



+error_report_err(err);
 s->msix = ON_OFF_AUTO_OFF;
 }
+
 if (pci_is_express(dev)) {
 pcie_endpoint_cap_init(dev, 0xa0);
 }
diff --git a/hw/usb/hcd-xhci.c b/hw/usb/hcd-xhci.c




diff --git a/hw/vfio/pci.c b/hw/vfio/pci.c
index d7dbe0e..6fbd30f 100644
--- a/hw/vfio/pci.c
+++ b/hw/vfio/pci.c
@@ -1432,6 +1432,7 @@ static void vfio_msix_early_setup(VFIOPCIDevice
*vdev, Error **errp)
 static int vfio_msix_setup(VFIOPCIDevice *vdev, int pos, Error **errp)
 {
 int ret;
+Error *err = NULL;

 vdev->msix->pending = g_malloc0(BITS_TO_LONGS(vdev->msix->entries) *
 sizeof(unsigned long));
@@ -1439,7 +1440,8 @@ static int vfio_msix_setup(VFIOPCIDevice *vdev,
int pos, Error **errp)
 vdev->bars[vdev->msix->table_bar].region.mem,
 vdev->msix->table_bar, vdev->msix->table_offset,
 vdev->bars[vdev->msix->pba_bar].region.mem,
-vdev->msix->pba_bar, vdev->msix->pba_offset, pos);
+vdev->msix->pba_bar, vdev->msix->pba_offset, pos,
+);


Do we pass the err pointer to msix_init, but we don't do anything with it?

Also since we do have an *errp in the function already, I suggest
renaming err -> local_err or something. (only if the series needs a
re-spin)



yes, it maybe need a re-spin, thanks


 if (ret < 0) {
 if (ret == -ENOTSUP) {
 return 0;
diff --git a/hw/virtio/virtio-pci.c b/hw/virtio/virtio-pci.c
index 06831de..5acce38 100644
--- a/hw/virtio/virtio-pci.c
+++ b/hw/virtio/virtio-pci.c
@@ -1693,13 +1693,12 @@ static void
virtio_pci_device_plugged(DeviceState *d, Error **errp)

 if (proxy->nvectors) {
 int err = msix_init_exclusive_bar(>pci_dev,
proxy->nvectors,
-  proxy->msix_bar_idx);
+  proxy->msix_bar_idx, errp);
+/* Any error other than -ENOTSUP(board's MSI support is broken)
+ * is a programming error. */
+assert(!err || err == -ENOTSUP);
 if (err) {
-/* Notice when a system that supports MSIx can't
initialize it.  */
-if (err != -ENOTSUP) {
-error_report("unable to init msix vectors to %" PRIu32,
- proxy->nvectors);
-}
+error_report_err(*errp);


Why do we report the error here and we don't let the propagation
mechanism do its thing? We can prep-end the current  message, I think.



The original behaviour won't fail on msix init failure, so, report & 
free the Error keep the behaviour same as before,  propagation will 
results in failing to create virtio device.





Other than a few questions, the patch looks good to me.

Thanks!
Marcel


--
Yours Sincerely,

Cao jin

Re: [Qemu-devel] [RFC 07/17] ppc: Rewrite ppc_set_compat()

[Alexey Kardashevskiy]

On 30/10/16 22:11, David Gibson wrote:
> This rewrites the ppc_set_compat() function so that instead of open coding
> the various compatibility modes, it reads the relevant data from a table.
> This is a first step in consolidating the information on compatibility
> modes scattered across the code into a single place.
> 
> It also makes one change to the logic.  The old code masked the bits to be
> set in the PCR (Processor Compatibility Register) by which bits are valid
> on the host CPU.  This made no sense, since it was done regardless of
> whether our guest CPU was the same as the host CPU or not.  Futhermore,

s/Futhermore/Furthermore/


> the actual PCR bits are only relevant for TCG[1] - KVM instead uses the
> compatibility mode we tell it in kvmppc_set_compat().  When using TCG
> host cpu information usually isn't even present.
> 
> While we're at it, we put the new implementation in a new file to make the
> enormouse translate_init.c a little smaller.

s/enormouse/enormous/


> 
> [1] Actually it doesn't even do anything in TCG, but it will if / when we
> get to implementing compatibility mode logic at that level.
> 
> Signed-off-by: David Gibson 

Reviewed-by: Alexey Kardashevskiy 

> ---
>  target-ppc/Makefile.objs|  1 +
>  target-ppc/compat.c | 91 
> +
>  target-ppc/cpu.h|  6 ++-
>  target-ppc/translate_init.c | 41 
>  4 files changed, 97 insertions(+), 42 deletions(-)
>  create mode 100644 target-ppc/compat.c
> 
> diff --git a/target-ppc/Makefile.objs b/target-ppc/Makefile.objs
> index e667e69..feb5c30 100644
> --- a/target-ppc/Makefile.objs
> +++ b/target-ppc/Makefile.objs
> @@ -15,3 +15,4 @@ obj-y += misc_helper.o
>  obj-y += mem_helper.o
>  obj-$(CONFIG_USER_ONLY) += user_only_helper.o
>  obj-y += gdbstub.o
> +obj-$(TARGET_PPC64) += compat.o
> diff --git a/target-ppc/compat.c b/target-ppc/compat.c
> new file mode 100644
> index 000..f3fd9c6
> --- /dev/null
> +++ b/target-ppc/compat.c
> @@ -0,0 +1,91 @@
> +/*
> + *  PowerPC CPU initialization for qemu.
> + *
> + *  Copyright 2016, David Gibson, Red Hat Inc. 
> + *
> + * This library is free software; you can redistribute it and/or
> + * modify it under the terms of the GNU Lesser General Public
> + * License as published by the Free Software Foundation; either
> + * version 2 of the License, or (at your option) any later version.
> + *
> + * This library 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.
> + *
> + * You should have received a copy of the GNU Lesser General Public
> + * License along with this library; if not, see 
> .
> + */
> +
> +#include "qemu/osdep.h"
> +#include "sysemu/kvm.h"
> +#include "kvm_ppc.h"
> +#include "sysemu/cpus.h"
> +#include "qemu/error-report.h"
> +#include "qapi/error.h"
> +#include "cpu-models.h"
> +
> +typedef struct {
> +uint32_t pvr;
> +uint64_t pcr;
> +} CompatInfo;
> +
> +static const CompatInfo compat_table[] = {
> +{ /* POWER6, ISA2.05 */
> +.pvr = CPU_POWERPC_LOGICAL_2_05,
> +.pcr = PCR_COMPAT_2_07 | PCR_COMPAT_2_06 | PCR_COMPAT_2_05
> +   | PCR_TM_DIS | PCR_VSX_DIS,
> +},
> +{ /* POWER7, ISA2.06 */
> +.pvr = CPU_POWERPC_LOGICAL_2_06,
> +.pcr = PCR_COMPAT_2_07 | PCR_COMPAT_2_06 | PCR_TM_DIS,
> +},
> +{
> +.pvr = CPU_POWERPC_LOGICAL_2_06_PLUS,
> +.pcr = PCR_COMPAT_2_07 | PCR_COMPAT_2_06 | PCR_TM_DIS,
> +},
> +{ /* POWER8, ISA2.07 */
> +.pvr = CPU_POWERPC_LOGICAL_2_07,
> +.pcr = PCR_COMPAT_2_07,
> +},
> +};
> +
> +static const CompatInfo *compat_by_pvr(uint32_t pvr)
> +{
> +int i;
> +
> +for (i = 0; i < ARRAY_SIZE(compat_table); i++) {
> +if (compat_table[i].pvr == pvr) {
> +return _table[i];
> +}
> +}
> +return NULL;
> +}
> +
> +void ppc_set_compat(PowerPCCPU *cpu, uint32_t compat_pvr, Error **errp)
> +{
> +const CompatInfo *compat = compat_by_pvr(compat_pvr);
> +CPUPPCState *env = >env;
> +PowerPCCPUClass *pcc = POWERPC_CPU_GET_CLASS(cpu);
> +uint64_t pcr;
> +
> +if (!compat_pvr) {
> +pcr = 0;
> +} else if (!compat) {
> +error_setg(errp, "Unknown compatibility PVR 0x%08"PRIx32, 
> compat_pvr);
> +return;
> +} else {
> +pcr = compat->pcr;
> +}
> +
> +cpu->compat_pvr = compat_pvr;
> +env->spr[SPR_PCR] = pcr & pcc->pcr_mask;
> +
> +if (kvm_enabled()) {
> +int ret = kvmppc_set_compat(cpu, cpu->compat_pvr);
> +if (ret < 0) {
> +error_setg_errno(errp, -ret,
> + "Unable to set CPU compatibility mode in KVM");
> +}
> +}
> +}

Re: [Qemu-devel] [PATCH v9 00/12] virtio-crypto: introduce framework and device emulation

[Gonglei (Arei)]

> -Original Message-
> From: Halil Pasic [mailto:pa...@linux.vnet.ibm.com]
> Sent: Thursday, November 03, 2016 1:35 AM
> Subject: Re: [Qemu-devel] [PATCH v9 00/12] virtio-crypto: introduce framework
> and device emulation
> 
> 
> 
> On 10/31/2016 03:52 AM, Gonglei (Arei) wrote:
> >> > Unfortunately I encountered a problem already on x86_64, more precisely
> >> > the guest hangs in virtio_crypto_alg_ablkcipher_init_session after the
> >> > kick. But before I start explaining in detail let me ask you: what are
> >> > your plans for the linux kernel driver? I used the most current version
> >> > from your github, but also tried to look for patches on mailing lists
> >> > and I have found none.
> > I haven't submit the virtio-crypto driver to the mailing list yet cause
> > I wanted to the patches on the QEMU side can be merged firstly,
> > and then focus to the frontend driver.
> >
> 
> That is fine and the QEMU stuff does look good :). I'm still curious
> about your road map that is what should I expect on the kernel side
> and when? You could also cc me ;) when sending to the list.
> 
Currently a project of my company eats my time, I'll address it in the
following two weeks I guess. 

Sure, I'll cc you when I sending to the mailing list. :)

> >> > IMHO the problem causing my hang is in the kernel
> >> > module. But I do not know here am I supposed to comment on it -- so I'm
> >> > commenting here. Furthermore your kernel module currently do not seem
> to
> >> > care about endianness which is bad for s390x.
> >> >
> > That's true.
> >
> 
> For the sake of the experiment I have reworked
> virtio_crypto_alg_ablkcipher_init_session so that id does care
> about the endianness of the guest. With that the functions seems
> to work on s390x (but of course the next byte order problem warrants
> that encryption/decryption does not work yet). It is not beautiful
> but I can give you a patch if you want.
> 
Sure, Pls. I can merge it with your sign.


Thanks,
-Gonglei

> >> > The hangs  basically boils down to the following: after the kick in
> >> > virtio_crypto_alg_ablkcipher_init_session we reach the point (in QEMU)
> >> > where we want to translate the address for the third descriptor, the one
> >> > which designates a buffer for the virtio_crypto_session_input. My
> >> > backtrace looks like this:
> >> >
> >> >
> >> > #0  address_space_translate (as=,
> >> > as@entry=0x5607d700 ,
> >> > addr=addr@entry=71468256835928, xlat=xlat@entry=0x7fffef4dc1a0,
> >> > plen=plen@entry=0x7fffef4dc198, is_write=is_write@entry=true)
> >> > at /home/pasic/devel/qemu/exec.c:481
> >> > #1  0x5575ef19 in address_space_map (as=0x5607d700
> >> > , addr=71468256835928, plen= out>,
> >> > is_write=) at /home/pasic/devel/qemu/exec.c:2927
> >> > #2  0x557e5d00 in virtqueue_map_desc
> (vdev=0x57d80de0,
> >> > p_num_sg=0x7fffef4dc2bc, addr=0x7fffef4dc2f0, iov=0x7fffef4de300,
> >> > max_num_sg=1022, is_write=true, pa=71468256835928, sz=16)
> >> > at /home/pasic/devel/qemu/hw/virtio/virtio.c:558
> >> > #3  0x557e5f86 in virtqueue_pop (vq=0x7fffef4dc2c0,
> >> > sz=93825003936576) at /home/pasic/devel/qemu/hw/virtio/virtio.c:717
> >> > #4  0x557ed80b in virtio_crypto_handle_ctrl (vdev= out>,
> >> > vq=0x7fffeec3e090) at
> /home/pasic/devel/qemu/hw/virtio/virtio-crypto.c:218
> >> >
> >> > Now the first suspicious thing I see is that address_space_translate
> >> > returns a pointer to the memory region io_mem_unassigned. Next thing
> >> > happening is that we take the !memory_access_is_direct(mr, is_write)
> >> > branch in address_space_map and return NULL at line 2932 which
> however
> >> > makes  virtqueue_map_desc report "qemu-system-x86_64: virtio: bogus
> >> > descriptor or out of resources" and return with false. Then pop returns
> >> > null too and spins virtio_crypto_alg_ablkcipher_init_session till the
> >> > end of time waiting for the answer.
> >> >
> > It seems that the frontend driver passed a invalid gpa to the QEMU side,
> > The Qemu side will invokes virtio_error() to notify the guest to reset the
> > device.
> >
> 
> I did not say previously but I have checked and the gpa is good, that
> is it has a correct offset in respect to ctrl's gpa (the next variable
> on stack, which is the previous desc.addr used read only) which is good.
> Furthermore the issue seems to be platform dependent as I do not see this
> on s390x.
> 
> >> > Now if I change the code so that the virtio_crypto_session_input
> >> > instance's backing memory is allocated with  kzalloc(sizeof(*input),
> >> > GFP_DMA|GFP_NOIO) of allocating the on the stack things start working
> >> > for me. I'm not too deep into this yet, so please forgive me if
> >> > I'm a bit vague.
> >> >
> > Good, maybe you find a bug of the frontend driver. Using stack memory
> > might not be a good idea ;)
> >
> 
> Yeah, as I said, can't say (that is my understanding too shallow).
> 
> Cheers,
> Halil

Re: [Qemu-devel] [PATCH v2 1/2] virtio: rename virtqueue_discard to virtqueue_unpop

[Alexey Kardashevskiy]

On 03/11/16 19:55, Ladi Prosek wrote:
> The function undoes the effect of virtqueue_pop and doesn't do anything
> destructive or irreversible so virtqueue_unpop is a more fitting name.

virtqueue_undo_pop() is even better, it was suggested by native english
speaker (i.e. not myself) :)



> 
> Signed-off-by: Ladi Prosek 
> ---
>  hw/net/virtio-net.c| 2 +-
>  hw/virtio/virtio-balloon.c | 2 +-
>  hw/virtio/virtio.c | 8 
>  include/hw/virtio/virtio.h | 4 ++--
>  4 files changed, 8 insertions(+), 8 deletions(-)
> 
> diff --git a/hw/net/virtio-net.c b/hw/net/virtio-net.c
> index 06bfe4b..20aa63e 100644
> --- a/hw/net/virtio-net.c
> +++ b/hw/net/virtio-net.c
> @@ -1177,7 +1177,7 @@ static ssize_t virtio_net_receive(NetClientState *nc, 
> const uint8_t *buf, size_t
>   * must have consumed the complete packet.
>   * Otherwise, drop it. */
>  if (!n->mergeable_rx_bufs && offset < size) {
> -virtqueue_discard(q->rx_vq, elem, total);
> +virtqueue_unpop(q->rx_vq, elem, total);
>  g_free(elem);
>  return size;
>  }
> diff --git a/hw/virtio/virtio-balloon.c b/hw/virtio/virtio-balloon.c
> index 1d77028..8e3b91c 100644
> --- a/hw/virtio/virtio-balloon.c
> +++ b/hw/virtio/virtio-balloon.c
> @@ -456,7 +456,7 @@ static void virtio_balloon_device_reset(VirtIODevice 
> *vdev)
>  VirtIOBalloon *s = VIRTIO_BALLOON(vdev);
>  
>  if (s->stats_vq_elem != NULL) {
> -virtqueue_discard(s->svq, s->stats_vq_elem, 0);
> +virtqueue_unpop(s->svq, s->stats_vq_elem, 0);
>  g_free(s->stats_vq_elem);
>  s->stats_vq_elem = NULL;
>  }
> diff --git a/hw/virtio/virtio.c b/hw/virtio/virtio.c
> index d48d1a9..68971fd 100644
> --- a/hw/virtio/virtio.c
> +++ b/hw/virtio/virtio.c
> @@ -280,7 +280,7 @@ void virtqueue_detach_element(VirtQueue *vq, const 
> VirtQueueElement *elem,
>  virtqueue_unmap_sg(vq, elem, len);
>  }
>  
> -/* virtqueue_discard:
> +/* virtqueue_unpop:
>   * @vq: The #VirtQueue
>   * @elem: The #VirtQueueElement
>   * @len: number of bytes written
> @@ -288,8 +288,8 @@ void virtqueue_detach_element(VirtQueue *vq, const 
> VirtQueueElement *elem,
>   * Pretend the most recent element wasn't popped from the virtqueue.  The 
> next
>   * call to virtqueue_pop() will refetch the element.
>   */
> -void virtqueue_discard(VirtQueue *vq, const VirtQueueElement *elem,
> -   unsigned int len)
> +void virtqueue_unpop(VirtQueue *vq, const VirtQueueElement *elem,
> + unsigned int len)
>  {
>  vq->last_avail_idx--;
>  virtqueue_detach_element(vq, elem, len);
> @@ -302,7 +302,7 @@ void virtqueue_discard(VirtQueue *vq, const 
> VirtQueueElement *elem,
>   * Pretend that elements weren't popped from the virtqueue.  The next
>   * virtqueue_pop() will refetch the oldest element.
>   *
> - * Use virtqueue_discard() instead if you have a VirtQueueElement.
> + * Use virtqueue_unpop() instead if you have a VirtQueueElement.
>   *
>   * Returns: true on success, false if @num is greater than the number of in 
> use
>   * elements.
> diff --git a/include/hw/virtio/virtio.h b/include/hw/virtio/virtio.h
> index b913aac..95adaca 100644
> --- a/include/hw/virtio/virtio.h
> +++ b/include/hw/virtio/virtio.h
> @@ -157,8 +157,8 @@ void virtqueue_push(VirtQueue *vq, const VirtQueueElement 
> *elem,
>  void virtqueue_flush(VirtQueue *vq, unsigned int count);
>  void virtqueue_detach_element(VirtQueue *vq, const VirtQueueElement *elem,
>unsigned int len);
> -void virtqueue_discard(VirtQueue *vq, const VirtQueueElement *elem,
> -   unsigned int len);
> +void virtqueue_unpop(VirtQueue *vq, const VirtQueueElement *elem,
> + unsigned int len);
>  bool virtqueue_rewind(VirtQueue *vq, unsigned int num);
>  void virtqueue_fill(VirtQueue *vq, const VirtQueueElement *elem,
>  unsigned int len, unsigned int idx);
> 


-- 
Alexey

Re: [Qemu-devel] [RFC 06/17] ppc: Rename cpu_version to compat_pvr

[Alexey Kardashevskiy]

On 30/10/16 22:11, David Gibson wrote:
> The 'cpu_version' field in PowerPCCPU is badly named.  It's named after the
> 'cpu-version' device tree property where it is advertised, but that meaning
> may not be obvious in most places it appears.
> 
> Worse, it doesn't even really correspond to that device tree property.  The
> property contains either the processor's PVR, or, if the CPU is running in
> a compatibility mode, a special "logical PVR" representing which mode.
> 
> Rename the cpu_version field, and a number of related variables to
> compat_pvr to make this clearer.
> 
> Signed-off-by: David Gibson 
> ---
>  hw/ppc/spapr.c  |  4 ++--
>  hw/ppc/spapr_hcall.c| 30 +++---
>  target-ppc/cpu.h|  6 +++---
>  target-ppc/kvm.c|  4 ++--
>  target-ppc/kvm_ppc.h|  4 ++--
>  target-ppc/translate_init.c | 10 +-
>  6 files changed, 29 insertions(+), 29 deletions(-)
> 
> diff --git a/hw/ppc/spapr.c b/hw/ppc/spapr.c
> index b7762ee..276cefa 100644
> --- a/hw/ppc/spapr.c
> +++ b/hw/ppc/spapr.c
> @@ -149,8 +149,8 @@ static int spapr_fixup_cpu_smt_dt(void *fdt, int offset, 
> PowerPCCPU *cpu,
>  uint32_t gservers_prop[smt_threads * 2];
>  int index = ppc_get_vcpu_dt_id(cpu);
>  
> -if (cpu->cpu_version) {
> -ret = fdt_setprop_cell(fdt, offset, "cpu-version", cpu->cpu_version);
> +if (cpu->compat_pvr) {


Nit: g_assert(cpu->compat_pvr & 0x0F00); may be?


Reviewed-by: Alexey Kardashevskiy 




> +ret = fdt_setprop_cell(fdt, offset, "cpu-version", cpu->compat_pvr);
>  if (ret < 0) {
>  return ret;
>  }
> diff --git a/hw/ppc/spapr_hcall.c b/hw/ppc/spapr_hcall.c
> index b5544cb..d93f580 100644
> --- a/hw/ppc/spapr_hcall.c
> +++ b/hw/ppc/spapr_hcall.c
> @@ -882,7 +882,7 @@ static target_ulong h_set_mode(PowerPCCPU *cpu, 
> sPAPRMachineState *spapr,
>  }
>  
>  typedef struct {
> -uint32_t cpu_version;
> +uint32_t compat_pvr;
>  Error *err;
>  } SetCompatState;
>  
> @@ -892,7 +892,7 @@ static void do_set_compat(CPUState *cs, void *arg)
>  SetCompatState *s = arg;
>  
>  cpu_synchronize_state(cs);
> -ppc_set_compat(cpu, s->cpu_version, >err);
> +ppc_set_compat(cpu, s->compat_pvr, >err);
>  }
>  
>  #define get_compat_level(cpuver) ( \
> @@ -903,7 +903,7 @@ static void do_set_compat(CPUState *cs, void *arg)
>  
>  static void cas_handle_compat_cpu(PowerPCCPUClass *pcc, uint32_t pvr,
>unsigned max_lvl, unsigned *compat_lvl,
> -  unsigned *cpu_version)
> +  unsigned *compat_pvr)
>  {
>  unsigned lvl = get_compat_level(pvr);
>  bool is205, is206, is207;
> @@ -926,12 +926,12 @@ static void cas_handle_compat_cpu(PowerPCCPUClass *pcc, 
> uint32_t pvr,
>  /* User did not set the level, choose the highest */
>  if (*compat_lvl <= lvl) {
>  *compat_lvl = lvl;
> -*cpu_version = pvr;
> +*compat_pvr = pvr;
>  }
>  } else if (max_lvl >= lvl) {
>  /* User chose the level, don't set higher than this */
>  *compat_lvl = lvl;
> -*cpu_version = pvr;
> +*compat_pvr = pvr;
>  }
>  }
>  }
> @@ -946,8 +946,8 @@ static target_ulong 
> h_client_architecture_support(PowerPCCPU *cpu_,
>  PowerPCCPUClass *pcc = POWERPC_CPU_GET_CLASS(cpu_);
>  CPUState *cs;
>  bool cpu_match = false;
> -unsigned old_cpu_version = cpu_->cpu_version;
> -unsigned compat_lvl = 0, cpu_version = 0;
> +unsigned old_compat_pvr = cpu_->compat_pvr;
> +unsigned compat_lvl = 0, compat_pvr = 0;
>  unsigned max_lvl = get_compat_level(cpu_->max_compat);
>  int counter;
>  sPAPROptionVector *ov5_guest, *ov5_cas_old, *ov5_updates;
> @@ -965,12 +965,12 @@ static target_ulong 
> h_client_architecture_support(PowerPCCPU *cpu_,
>  if (!max_lvl &&
>  ((cpu_->env.spr[SPR_PVR] & pvr_mask) == (pvr & pvr_mask))) {
>  cpu_match = true;
> -cpu_version = 0;
> -} else if (pvr == cpu_->cpu_version) {
> +compat_pvr = 0;
> +} else if (pvr == cpu_->compat_pvr) {
>  cpu_match = true;
> -cpu_version = cpu_->cpu_version;
> +compat_pvr = cpu_->compat_pvr;
>  } else if (!cpu_match) {
> -cas_handle_compat_cpu(pcc, pvr, max_lvl, _lvl, 
> _version);
> +cas_handle_compat_cpu(pcc, pvr, max_lvl, _lvl, 
> _pvr);
>  }
>  /* Terminator record */
>  if (~pvr_mask & pvr) {
> @@ -979,14 +979,14 @@ static target_ulong 
> h_client_architecture_support(PowerPCCPU *cpu_,
>  }
>  
>  /* Parsing finished */
> -trace_spapr_cas_pvr(cpu_->cpu_version, cpu_match,
> -cpu_version, pcc->pcr_mask);
> +

[Qemu-devel] [PATCH] x86: Fix x86_64 'g' packet response to gdb from 32-bit mode.

[Doug Evans]

The remote protocol can't handle flipping back and forth
between 32-bit and 64-bit regs. To compensate, pretend "as if"
on 64-bit cpu when in 32-bit mode.

Signed-off-by: Doug Evans 
---
 target-i386/gdbstub.c | 52  
++-

 1 file changed, 39 insertions(+), 13 deletions(-)

diff --git a/target-i386/gdbstub.c b/target-i386/gdbstub.c
index c494535..9b94ab8 100644
--- a/target-i386/gdbstub.c
+++ b/target-i386/gdbstub.c
@@ -44,10 +44,22 @@ int x86_cpu_gdb_read_register(CPUState *cs, uint8_t  
*mem_buf, int n)

 X86CPU *cpu = X86_CPU(cs);
 CPUX86State *env = >env;

+/* N.B. GDB can't deal with changes in registers or sizes in the middle
+   of a session. So if we're in 32-bit mode on a 64-bit cpu, still act
+   as if we're on a 64-bit cpu. */
+
 if (n < CPU_NB_REGS) {
-if (TARGET_LONG_BITS == 64 && env->hflags & HF_CS64_MASK) {
-return gdb_get_reg64(mem_buf, env->regs[gpr_map[n]]);
-} else if (n < CPU_NB_REGS32) {
+if (TARGET_LONG_BITS == 64) {
+if (env->hflags & HF_CS64_MASK) {
+return gdb_get_reg64(mem_buf, env->regs[gpr_map[n]]);
+} else if (n < CPU_NB_REGS32) {
+return gdb_get_reg64(mem_buf,
+ env->regs[gpr_map[n]] & 0xUL);
+} else {
+memset(mem_buf, 0, sizeof(target_ulong));
+return sizeof(target_ulong);
+}
+} else {
 return gdb_get_reg32(mem_buf, env->regs[gpr_map32[n]]);
 }
 } else if (n >= IDX_FP_REGS && n < IDX_FP_REGS + 8) {
@@ -60,8 +72,7 @@ int x86_cpu_gdb_read_register(CPUState *cs, uint8_t  
*mem_buf, int n)

 return 10;
 } else if (n >= IDX_XMM_REGS && n < IDX_XMM_REGS + CPU_NB_REGS) {
 n -= IDX_XMM_REGS;
-if (n < CPU_NB_REGS32 ||
-(TARGET_LONG_BITS == 64 && env->hflags & HF_CS64_MASK)) {
+if (n < CPU_NB_REGS32 || TARGET_LONG_BITS == 64) {
 stq_p(mem_buf, env->xmm_regs[n].ZMM_Q(0));
 stq_p(mem_buf + 8, env->xmm_regs[n].ZMM_Q(1));
 return 16;
@@ -69,8 +80,12 @@ int x86_cpu_gdb_read_register(CPUState *cs, uint8_t  
*mem_buf, int n)

 } else {
 switch (n) {
 case IDX_IP_REG:
-if (TARGET_LONG_BITS == 64 && env->hflags & HF_CS64_MASK) {
-return gdb_get_reg64(mem_buf, env->eip);
+if (TARGET_LONG_BITS == 64) {
+if (env->hflags & HF_CS64_MASK) {
+return gdb_get_reg64(mem_buf, env->eip);
+} else {
+return gdb_get_reg64(mem_buf, env->eip & 0xUL);
+}
 } else {
 return gdb_get_reg32(mem_buf, env->eip);
 }
@@ -151,9 +166,17 @@ int x86_cpu_gdb_write_register(CPUState *cs, uint8_t  
*mem_buf, int n)

 CPUX86State *env = >env;
 uint32_t tmp;

+/* N.B. GDB can't deal with changes in registers or sizes in the middle
+   of a session. So if we're in 32-bit mode on a 64-bit cpu, still act
+   as if we're on a 64-bit cpu. */
+
 if (n < CPU_NB_REGS) {
-if (TARGET_LONG_BITS == 64 && env->hflags & HF_CS64_MASK) {
-env->regs[gpr_map[n]] = ldtul_p(mem_buf);
+if (TARGET_LONG_BITS == 64) {
+if (env->hflags & HF_CS64_MASK) {
+env->regs[gpr_map[n]] = ldtul_p(mem_buf);
+} else if (n < CPU_NB_REGS32) {
+env->regs[gpr_map[n]] = ldtul_p(mem_buf) & 0xUL;
+}
 return sizeof(target_ulong);
 } else if (n < CPU_NB_REGS32) {
 n = gpr_map32[n];
@@ -169,8 +192,7 @@ int x86_cpu_gdb_write_register(CPUState *cs, uint8_t  
*mem_buf, int n)

 return 10;
 } else if (n >= IDX_XMM_REGS && n < IDX_XMM_REGS + CPU_NB_REGS) {
 n -= IDX_XMM_REGS;
-if (n < CPU_NB_REGS32 ||
-(TARGET_LONG_BITS == 64 && env->hflags & HF_CS64_MASK)) {
+if (n < CPU_NB_REGS32 || TARGET_LONG_BITS == 64) {
 env->xmm_regs[n].ZMM_Q(0) = ldq_p(mem_buf);
 env->xmm_regs[n].ZMM_Q(1) = ldq_p(mem_buf + 8);
 return 16;
@@ -178,8 +200,12 @@ int x86_cpu_gdb_write_register(CPUState *cs, uint8_t  
*mem_buf, int n)

 } else {
 switch (n) {
 case IDX_IP_REG:
-if (TARGET_LONG_BITS == 64 && env->hflags & HF_CS64_MASK) {
-env->eip = ldq_p(mem_buf);
+if (TARGET_LONG_BITS == 64) {
+if (env->hflags & HF_CS64_MASK) {
+env->eip = ldq_p(mem_buf);
+} else {
+env->eip = ldq_p(mem_buf) & 0xUL;
+}
 return 8;
 } else {
 env->eip &= ~0xUL;
--

[Qemu-devel] [PATCH] Document how x86 gdb_num_core_regs is computed.

[Doug Evans]

Hi.

It helps when reading the code to see how the number is arrived at.

Signed-off-by: Doug Evans 
---
 target-i386/cpu.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/target-i386/cpu.c b/target-i386/cpu.c
index 14c5186..01f1ab0 100644
--- a/target-i386/cpu.c
+++ b/target-i386/cpu.c
@@ -3721,6 +3721,8 @@ static void x86_cpu_common_class_init(ObjectClass  
*oc, void *data)

 cc->write_elf32_qemunote = x86_cpu_write_elf32_qemunote;
 cc->vmsd = _x86_cpu;
 #endif
+/* CPU_NB_REGS * 2 = general regs + xmm regs
+   25 = eip, eflags, 6 seg regs, st[0-7], fctrl,...,fop, mxcsr */
 cc->gdb_num_core_regs = CPU_NB_REGS * 2 + 25;
 #ifndef CONFIG_USER_ONLY
 cc->debug_excp_handler = breakpoint_handler;
--

Re: [Qemu-devel] [PATCH v2] target-sh4: add atomic tas

[Aurelien Jarno]

On 2016-11-03 15:07, Laurent Vivier wrote:
> Implement real atomic tas:
> 
> When (Rn) = 0, 1 -> T
> Otherwise, 0 -> T
> In both cases, 1 -> MSB of (Rn)
> 
> using atomic_fetch_or_i32() and setcondi_i32().
> 
> Tested with image from:
> http://wiki.qemu.org/download/sh-test-0.2.tar.bz2
> 
> This image contains a "tas_test" that runs without
> error with this change.
> 
> Signed-off-by: Laurent Vivier 
> ---
> v2:
> - don't use helper but atomic_fetch_or_i32
>   Thank you Paolo!

Thanks, this look good. I have tried it with my test image, and it
doesn't break it.

Reviewed-by: Aurelien Jarno 
Acked-by: Aurelien Jarno 

I consider this as a bugfix, not a new feature, so that should be fine
despite the soft freeze. Do you want me to send a pull request?

Aurelien

-- 
Aurelien Jarno  GPG: 4096R/1DDD8C9B
aurel...@aurel32.net http://www.aurel32.net


signature.asc
Description: PGP signature

Re: [Qemu-devel] [PATCH 1/5] ARM BE8/BE32 semihosting and gdbstub support.

[Julian Brown]

On Thu, 3 Nov 2016 22:23:09 +
Peter Maydell  wrote:

> On 3 November 2016 at 17:30, Julian Brown 
> wrote:
> > This patch improves support for semihosting and debugging with the
> > in-built gdbstub for ARM system-mode emulation in big-endian mode
> > (either BE8 or BE32), after the fairly recent changes to allow a
> > single QEMU binary to deal with each of LE, BE8 and BE32 modes in
> > one. It's only currently good for little-endian host systems. The
> > relevant use case is using QEMU as a "bare metal" instruction-set
> > simulator, e.g. for toolchain testing.
> >
> > For semihosting, the softmmu-semi.h file is overridden with an
> > ARM-specific version that knows about byte-swapping target memory
> > into host order -- including that which has been byte-swapped at
> > load time for BE32 mode.  
> 
> Something here seems really weird. I would expect gdb
> to be able to cope with the target CPU's endianness
> settings. After all there is real world code which
> starts off in one endianness, temporarily swaps to
> the other and then switches back again, and gdb needs
> to be able to step through it without issues. So having
> code in the gdbstub interface that looks at arm_bswap_needed()
> seems rather odd and in the wrong place. What the guest
> CPU happens to be doing at any particular point shouldn't
> affect the way we talk to gdb.

I think the way it works is, if you invoke GDB with something like,

$ arm-eabi-gdb big-endian-binary.elf

then the remote protocol will talk in big-endian format (memory
read/write packets, register read/write packets, etc.) for that session.
I'm not sure if it'll transparently switch to little-endian remote
protocol format if the target does a SETEND instruction, or whatever.
I'd guess not.

So (IIRC!) the gdbstub needs to interpret some of these read/write
values on the host, i.e. in host byte ordering. "Traditionally", the
ldl_p and stl_p (etc.) macros would byteswap depending on the
TARGET_WORDS_BIGENDIAN setting -- that's how come our internal testing
using QEMU worked at all in the past. But that's changed with the
single-binary-for-all-endiannesses patches.

So -- all uses of ld*_p and st*_p, and the TARGET_WORDS_BIGENDIAN
macro, are now suspect in ARM system-emulation mode. The gdbstub.c
changes appear to fix some of those, but... yeah, there may be
subtleties remaining, like run-time endian switching by the target.
Generally it's not ideal, but I'm not sure how to do better.

Thanks,

Julian

Re: [Qemu-devel] [PATCH 4/5] ARM BE32 watchpoint fix.

[Julian Brown]

On Thu, 3 Nov 2016 23:14:05 +
Peter Maydell  wrote:

> On 3 November 2016 at 17:30, Julian Brown 
> wrote:
> > In BE32 mode, sub-word size watchpoints can fail to trigger because
> > the address of the access is adjusted in the opcode helpers before
> > being compared with the watchpoint registers.  This patch reversed
> > the address adjustment before performing the comparison.
> >
> > Signed-off-by: Julian Brown 
> > ---
> >  exec.c | 13 +
> >  1 file changed, 13 insertions(+)
> >
> > diff --git a/exec.c b/exec.c
> > index 4c84389..eadab54 100644
> > --- a/exec.c
> > +++ b/exec.c
> > @@ -2047,6 +2047,19 @@ static void check_watchpoint(int offset, int
> > len, MemTxAttrs attrs, int flags) return;
> >  }
> >  vaddr = (cpu->mem_io_vaddr & TARGET_PAGE_MASK) + offset;
> > +#if defined(TARGET_ARM) && !defined(CONFIG_USER_ONLY)
> > +/* In BE32 system mode, target memory is stored byteswapped
> > (FIXME:
> > +   relative to a little-endian host system), and by the time
> > we reach here
> > +   (via an opcode helper) the addresses of subword accesses
> > have been
> > +   adjusted to account for that, which means that watchpoints
> > will not
> > +   match.  Undo the adjustment here.  */
> > +if (arm_sctlr_b(env)) {
> > +if (len == 1)
> > +vaddr ^= 3;
> > +else if (len == 2)
> > +vaddr ^= 2;
> > +}
> > +#endif  
> 
> No target-CPU specific code in exec.c, please...

Yeah, I'd imagine not. I struggled with this one. Any suggestions for a
better way to do this?

Thanks,

Julian

Re: [Qemu-devel] [PATCH 4/5] ARM BE32 watchpoint fix.

[Peter Maydell]

On 3 November 2016 at 17:30, Julian Brown  wrote:
> In BE32 mode, sub-word size watchpoints can fail to trigger because the
> address of the access is adjusted in the opcode helpers before being
> compared with the watchpoint registers.  This patch reversed the address
> adjustment before performing the comparison.
>
> Signed-off-by: Julian Brown 
> ---
>  exec.c | 13 +
>  1 file changed, 13 insertions(+)
>
> diff --git a/exec.c b/exec.c
> index 4c84389..eadab54 100644
> --- a/exec.c
> +++ b/exec.c
> @@ -2047,6 +2047,19 @@ static void check_watchpoint(int offset, int len, 
> MemTxAttrs attrs, int flags)
>  return;
>  }
>  vaddr = (cpu->mem_io_vaddr & TARGET_PAGE_MASK) + offset;
> +#if defined(TARGET_ARM) && !defined(CONFIG_USER_ONLY)
> +/* In BE32 system mode, target memory is stored byteswapped (FIXME:
> +   relative to a little-endian host system), and by the time we reach 
> here
> +   (via an opcode helper) the addresses of subword accesses have been
> +   adjusted to account for that, which means that watchpoints will not
> +   match.  Undo the adjustment here.  */
> +if (arm_sctlr_b(env)) {
> +if (len == 1)
> +vaddr ^= 3;
> +else if (len == 2)
> +vaddr ^= 2;
> +}
> +#endif

No target-CPU specific code in exec.c, please...

thanks
-- PMM

Re: [Qemu-devel] [PATCH 1/5] ARM BE8/BE32 semihosting and gdbstub support.

[Peter Maydell]

On 3 November 2016 at 17:30, Julian Brown  wrote:
> This patch improves support for semihosting and debugging with the
> in-built gdbstub for ARM system-mode emulation in big-endian mode (either
> BE8 or BE32), after the fairly recent changes to allow a single QEMU
> binary to deal with each of LE, BE8 and BE32 modes in one. It's only
> currently good for little-endian host systems. The relevant use case
> is using QEMU as a "bare metal" instruction-set simulator, e.g. for
> toolchain testing.
>
> For semihosting, the softmmu-semi.h file is overridden with an
> ARM-specific version that knows about byte-swapping target memory into
> host order -- including that which has been byte-swapped at load time
> for BE32 mode.

Something here seems really weird. I would expect gdb
to be able to cope with the target CPU's endianness
settings. After all there is real world code which
starts off in one endianness, temporarily swaps to
the other and then switches back again, and gdb needs
to be able to step through it without issues. So having
code in the gdbstub interface that looks at arm_bswap_needed()
seems rather odd and in the wrong place. What the guest
CPU happens to be doing at any particular point shouldn't
affect the way we talk to gdb.

> For the gdbstub, we'd like to be able to invoke QEMU from GDB like:
>
> (gdb) target remote | arm-qemu-system -cpu=foo [options] /dev/null
> (gdb) load
> (gdb) ...
>
> which unfortunately bypasses the probing of the loaded ELF file (since
> it's just /dev/null) to determine whether to use BE8/BE32 mode. So,
> I added some "virtual" CPUs to set the endian type instead (arm926-be,
> cortex-a15-be for BE32/BE8 mode respectively), from the reset value
> of the SCTLR. This is kind of like having a configuration input to the
> CPU on some hardware board to select endianness, which is a completely
> legitimate thing to have, even if the implementation as-is is not really
> ideal from a software-engineering standpoint. It suffices for our current
> use-case though.

Strong 'no' for the approach of having different CPU
names, I'm afraid. What you want is to have a CPU
property which works like the hardware CPU's CFGEND
signal to set the reset value of the SCTLR.EE bit. Then
a board can use that where it would wire up CFGEND
in real hardware, and on the command line you can
have -cpu whatever,cfgend=yes (which is a bit ugly
but then it's borderline whether it makes any sense at
all for the user to be able to set the endianness on
the commandline).

(For the rest of the series: you've missed the 2.8
freeze, and I'm on holiday for most of November, so
it may be a while before I can get to it; hopefully
somebody else will step up and have a look at it.)

thanks
-- PMM

Re: [Qemu-devel] [PATCH 0/5] ARM BE8/BE32 big-endian system-mode fixes (semihosting, gdbstub)

[no-reply]

Hi,

Your series failed automatic build test. Please find the testing commands and
their output below. If you have docker installed, you can probably reproduce it
locally.

Type: series
Subject: [Qemu-devel] [PATCH 0/5] ARM BE8/BE32 big-endian system-mode fixes 
(semihosting, gdbstub)
Message-id: 1478194258-75276-1-git-send-email-jul...@codesourcery.com

=== TEST SCRIPT BEGIN ===
#!/bin/bash
set -e
git submodule update --init dtc
# Let docker tests dump environment info
export SHOW_ENV=1
export J=16
make docker-test-quick@centos6
make docker-test-mingw@fedora
=== TEST SCRIPT END ===

Updating 3c8cf5a9c21ff8782164d1def7f44bd888713384
Switched to a new branch 'test'
fed6fdc Fix typo in arm_cpu_do_interrupt_aarch32.
8e8228b ARM BE32 watchpoint fix.
c35a16c Fix arm_semi_flen_cb for BE32 system mode.
34c88b7 Fix Thumb-1 BE32 execution and disassembly.
23bc6c4 ARM BE8/BE32 semihosting and gdbstub support.

=== OUTPUT BEGIN ===
Submodule 'dtc' (git://git.qemu-project.org/dtc.git) registered for path 'dtc'
Cloning into 'dtc'...
Submodule path 'dtc': checked out '65cc4d2748a2c2e6f27f1cf39e07a5dbabd80ebf'
  BUILD   centos6
make[1]: Entering directory `/var/tmp/patchew-tester-tmp-pb3qxzah/src'
  ARCHIVE qemu.tgz
  ARCHIVE dtc.tgz
  COPYRUNNER
RUN test-quick in qemu:centos6 
Packages installed:
SDL-devel-1.2.14-7.el6_7.1.x86_64
ccache-3.1.6-2.el6.x86_64
epel-release-6-8.noarch
gcc-4.4.7-17.el6.x86_64
git-1.7.1-4.el6_7.1.x86_64
glib2-devel-2.28.8-5.el6.x86_64
libfdt-devel-1.4.0-1.el6.x86_64
make-3.81-23.el6.x86_64
package g++ is not installed
pixman-devel-0.32.8-1.el6.x86_64
tar-1.23-15.el6_8.x86_64
zlib-devel-1.2.3-29.el6.x86_64

Environment variables:
PACKAGES=libfdt-devel ccache tar git make gcc g++ zlib-devel 
glib2-devel SDL-devel pixman-devel epel-release
HOSTNAME=3aa916f573da
TERM=xterm
MAKEFLAGS= -j16
HISTSIZE=1000
J=16
USER=root
CCACHE_DIR=/var/tmp/ccache
EXTRA_CONFIGURE_OPTS=
V=
SHOW_ENV=1
MAIL=/var/spool/mail/root
PATH=/usr/lib/ccache:/usr/lib64/ccache:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
PWD=/
LANG=en_US.UTF-8
TARGET_LIST=
HISTCONTROL=ignoredups
SHLVL=1
HOME=/root
TEST_DIR=/tmp/qemu-test
LOGNAME=root
LESSOPEN=||/usr/bin/lesspipe.sh %s
FEATURES= dtc
DEBUG=
G_BROKEN_FILENAMES=1
CCACHE_HASHDIR=
_=/usr/bin/env

Configure options:
--enable-werror --target-list=x86_64-softmmu,aarch64-softmmu 
--prefix=/var/tmp/qemu-build/install
No C++ compiler available; disabling C++ specific optional code
Install prefix/var/tmp/qemu-build/install
BIOS directory/var/tmp/qemu-build/install/share/qemu
binary directory  /var/tmp/qemu-build/install/bin
library directory /var/tmp/qemu-build/install/lib
module directory  /var/tmp/qemu-build/install/lib/qemu
libexec directory /var/tmp/qemu-build/install/libexec
include directory /var/tmp/qemu-build/install/include
config directory  /var/tmp/qemu-build/install/etc
local state directory   /var/tmp/qemu-build/install/var
Manual directory  /var/tmp/qemu-build/install/share/man
ELF interp prefix /usr/gnemul/qemu-%M
Source path   /tmp/qemu-test/src
C compilercc
Host C compiler   cc
C++ compiler  
Objective-C compiler cc
ARFLAGS   rv
CFLAGS-O2 -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=2 -g 
QEMU_CFLAGS   -I/usr/include/pixman-1-pthread -I/usr/include/glib-2.0 
-I/usr/lib64/glib-2.0/include   -fPIE -DPIE -m64 -mcx16 -D_GNU_SOURCE 
-D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -Wstrict-prototypes 
-Wredundant-decls -Wall -Wundef -Wwrite-strings -Wmissing-prototypes 
-fno-strict-aliasing -fno-common -fwrapv  -Wendif-labels -Wmissing-include-dirs 
-Wempty-body -Wnested-externs -Wformat-security -Wformat-y2k -Winit-self 
-Wignored-qualifiers -Wold-style-declaration -Wold-style-definition 
-Wtype-limits -fstack-protector-all
LDFLAGS   -Wl,--warn-common -Wl,-z,relro -Wl,-z,now -pie -m64 -g 
make  make
install   install
pythonpython -B
smbd  /usr/sbin/smbd
module supportno
host CPU  x86_64
host big endian   no
target list   x86_64-softmmu aarch64-softmmu
tcg debug enabled no
gprof enabled no
sparse enabledno
strip binariesyes
profiler  no
static build  no
pixmansystem
SDL support   yes (1.2.14)
GTK support   no 
GTK GL supportno
VTE support   no 
TLS priority  NORMAL
GNUTLS supportno
GNUTLS rndno
libgcrypt no
libgcrypt kdf no
nettleno 
nettle kdfno
libtasn1  no
curses supportno
virgl support no
curl support  no
mingw32 support   no
Audio drivers oss
Block whitelist (rw) 
Block whitelist (ro) 
VirtFS supportno
VNC support   yes
VNC SASL support  no
VNC JPEG support  no
VNC PNG support   no
xen support   no
brlapi supportno
bluez  supportno
Documentation no
PIE   yes
vde support   no
netmap supportno
Linux AIO support no
ATTR/XATTR support yes
Install blobs yes
KVM support   

Re: [Qemu-devel] [PATCH 0/5] ARM BE8/BE32 big-endian system-mode fixes (semihosting, gdbstub)

[no-reply]

Hi,

Your series seems to have some coding style problems. See output below for
more information:

Type: series
Subject: [Qemu-devel] [PATCH 0/5] ARM BE8/BE32 big-endian system-mode fixes 
(semihosting, gdbstub)
Message-id: 1478194258-75276-1-git-send-email-jul...@codesourcery.com

=== TEST SCRIPT BEGIN ===
#!/bin/bash

BASE=base
n=1
total=$(git log --oneline $BASE.. | wc -l)
failed=0

# Useful git options
git config --local diff.renamelimit 0
git config --local diff.renames True

commits="$(git log --format=%H --reverse $BASE..)"
for c in $commits; do
echo "Checking PATCH $n/$total: $(git show --no-patch --format=%s $c)..."
if ! git show $c --format=email | ./scripts/checkpatch.pl --mailback -; then
failed=1
echo
fi
n=$((n+1))
done

exit $failed
=== TEST SCRIPT END ===

Updating 3c8cf5a9c21ff8782164d1def7f44bd888713384
From https://github.com/patchew-project/qemu
 * [new tag] 
patchew/1478194258-75276-1-git-send-email-jul...@codesourcery.com -> 
patchew/1478194258-75276-1-git-send-email-jul...@codesourcery.com
Switched to a new branch 'test'
fed6fdc Fix typo in arm_cpu_do_interrupt_aarch32.
8e8228b ARM BE32 watchpoint fix.
c35a16c Fix arm_semi_flen_cb for BE32 system mode.
34c88b7 Fix Thumb-1 BE32 execution and disassembly.
23bc6c4 ARM BE8/BE32 semihosting and gdbstub support.

=== OUTPUT BEGIN ===
fatal: unrecognized argument: --no-patch
Checking PATCH 1/5: ...
fatal: unrecognized argument: --no-patch
Checking PATCH 2/5: ...
ERROR: suspect code indent for conditional statements (6, 10)
#42: FILE: disas/arm.c:3919:
+  if (is_thumb1_be32) {
+  status = info->read_memory_func(pc & ~3, (bfd_byte *)b, 4, info);

ERROR: suspect code indent for conditional statements (10, 14)
#45: FILE: disas/arm.c:3922:
+  if ((pc & 2) == 0) {
+  given = b[2] | (b[3] << 8);

ERROR: suspect code indent for conditional statements (10, 14)
#52: FILE: disas/arm.c:3929:
+  if (little) {
+  given = (b[0]) | (b[1] << 8);

ERROR: suspect code indent for conditional statements (14, 18)
#70: FILE: disas/arm.c:3944:
+  if (is_thumb1_be32) {
+  status = info->read_memory_func((pc + 2) & ~3,

ERROR: suspect code indent for conditional statements (18, 22)
#73: FILE: disas/arm.c:3947:
+  if (((pc + 2) & 2) == 0) {
+  given = b[2] | (b[3] << 8) | (given << 16);

ERROR: suspect code indent for conditional statements (18, 22)
#81: FILE: disas/arm.c:3955:
+  if (little) {
+  given = (b[0]) | (b[1] << 8) | (given << 16);

total: 6 errors, 0 warnings, 100 lines checked

Your patch has style problems, please review.  If any of these errors
are false positives report them to the maintainer, see
CHECKPATCH in MAINTAINERS.

fatal: unrecognized argument: --no-patch
Checking PATCH 3/5: ...
fatal: unrecognized argument: --no-patch
Checking PATCH 4/5: ...
fatal: unrecognized argument: --no-patch
Checking PATCH 5/5: ...
=== OUTPUT END ===

Test command exited with code: 1


---
Email generated automatically by Patchew [http://patchew.org/].
Please send your feedback to patchew-de...@freelists.org

[Qemu-devel] [PATCH 5/5] Fix typo in arm_cpu_do_interrupt_aarch32.

[Julian Brown]

This appears to be a typo in arm_cpu_do_interrupt_aarch32 (OR'ing with ~CPSR_E
instead of CPSR_E).

Signed-off-by: Julian Brown 
---
 target-arm/helper.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/target-arm/helper.c b/target-arm/helper.c
index 25b15dc..b5b65ca 100644
--- a/target-arm/helper.c
+++ b/target-arm/helper.c
@@ -6438,7 +6438,7 @@ static void arm_cpu_do_interrupt_aarch32(CPUState *cs)
 /* Set new mode endianness */
 env->uncached_cpsr &= ~CPSR_E;
 if (env->cp15.sctlr_el[arm_current_el(env)] & SCTLR_EE) {
-env->uncached_cpsr |= ~CPSR_E;
+env->uncached_cpsr |= CPSR_E;
 }
 env->daif |= mask;
 /* this is a lie, as the was no c1_sys on V4T/V5, but who cares
-- 
1.9.1

Re: [Qemu-devel] [PATCH v2 2/3] target-m68k: implement 680x0 movem

[Richard Henderson]

On 11/03/2016 02:11 PM, Laurent Vivier wrote:

Le 03/11/2016 à 20:47, Richard Henderson a écrit :

On 11/02/2016 03:15 PM, Laurent Vivier wrote:

+if ((insn & 7) + 8 == i &&
+m68k_feature(s->env, M68K_FEATURE_EXT_FULL)) {
+/* M68020+: if the addressing register is the
+ * register moved to memory, the value written
+ * is the initial value decremented by the
size of
+ * the operation
+ * M68000/M68010: the value is the initial value
+ */
+TCGv tmp = tcg_temp_new();
+tcg_gen_sub_i32(tmp, mreg(i), incr);
+gen_store(s, opsize, addr, tmp);
+tcg_temp_free(tmp);


This doesn't look right.  Is the value stored the intermediate value of
the decremented register, or the final value?  What you're storing is
reg-4, which is neither of these things.

I could see, maybe, that reg-4 might well turn out to be the right value
for

movem{a0-a7}, (sp)-

since sp == a7, and therefore stored first.  But I question that's the
correct result for

movem{a0-a7}, (a1)-

If it's the incremental value, then you can just store "addr" and you
don't need a temp.  If it's the final value, then you can compute

tcg_gen_subi_i32(tmp, AREG(insn, 0), ctpop32(mask) * 4);



As it was not clear for me, I have written a test to see what was the
good value.

my test program is:

top:
.space 64,0
stack:
.text
.globl _start
_start:
lea stack,%a4
lea 1,%a0
lea 2,%a1
lea 3,%a2
lea 4,%a3
lea 5,%a5
lea 6,%a6
moveq.l #8, %d0
moveq.l #9, %d1
moveq.l #10, %d2
moveq.l #11, %d3
moveq.l #12, %d4
moveq.l #13, %d5
moveq.l #14, %d6
moveq.l #15, %d7
movem.l %a0-%a7/%d0-%d7,-(%a4)

on a real 68040:

initial value of A4 is 0x800020ec
final value of A4 is   0x800020ac

(gdb) x/15x 0x800020ac
0x800020ac: 0x0008  0x0009  0x000a  0x000b
0x800020bc: 0x000c  0x000d  0x000e  0x000f
0x800020cc: 0x0001  0x0002  0x0003  0x0004
0x800020dc: 0x800020e8  0x0005  0x0006

Stored value is thus 0x800020e8 so this is initial value - 4.
[I have tried the same test with a1, for the same result]


Weird.  But, ok.


r~

[Qemu-devel] [PATCH v2 0/3] target-m68k areg writeback

[Richard Henderson]

Changes since v1:
  * writeback_mask initialized
  * the two cmpm patches are squashed.


r~


Laurent Vivier (1):
  target-m68k: add cmpm

Richard Henderson (2):
  target-m68k: Delay autoinc writeback
  target-m68k: Split gen_lea and gen_ea

 target-m68k/translate.c | 208 +++-
 1 file changed, 137 insertions(+), 71 deletions(-)

-- 
2.7.4

[Qemu-devel] [PATCH v2 1/3] target-m68k: Delay autoinc writeback

[Richard Henderson]

Signed-off-by: Richard Henderson 
---
 target-m68k/translate.c | 84 +
 1 file changed, 64 insertions(+), 20 deletions(-)

diff --git a/target-m68k/translate.c b/target-m68k/translate.c
index 9ad974f..25ceb2c 100644
--- a/target-m68k/translate.c
+++ b/target-m68k/translate.c
@@ -59,12 +59,12 @@ static TCGv cpu_aregs[8];
 static TCGv_i64 cpu_fregs[8];
 static TCGv_i64 cpu_macc[4];
 
-#define REG(insn, pos) (((insn) >> (pos)) & 7)
+#define REG(insn, pos)  (((insn) >> (pos)) & 7)
 #define DREG(insn, pos) cpu_dregs[REG(insn, pos)]
-#define AREG(insn, pos) cpu_aregs[REG(insn, pos)]
+#define AREG(insn, pos) get_areg(s, REG(insn, pos))
 #define FREG(insn, pos) cpu_fregs[REG(insn, pos)]
-#define MACREG(acc) cpu_macc[acc]
-#define QREG_SP cpu_aregs[7]
+#define MACREG(acc) cpu_macc[acc]
+#define QREG_SP get_areg(s, 7)
 
 static TCGv NULL_QREG;
 #define IS_NULL_QREG(t) (TCGV_EQUAL(t, NULL_QREG))
@@ -141,8 +141,55 @@ typedef struct DisasContext {
 int singlestep_enabled;
 TCGv_i64 mactmp;
 int done_mac;
+int writeback_mask;
+TCGv writeback[8];
 } DisasContext;
 
+static TCGv get_areg(DisasContext *s, unsigned regno)
+{
+if (s->writeback_mask & (1 << regno)) {
+return s->writeback[regno];
+} else {
+return cpu_aregs[regno];
+}
+}
+
+static void delay_set_areg(DisasContext *s, unsigned regno,
+   TCGv val, bool give_temp)
+{
+if (s->writeback_mask & (1 << regno)) {
+if (give_temp) {
+tcg_temp_free(s->writeback[regno]);
+s->writeback[regno] = val;
+} else {
+tcg_gen_mov_i32(s->writeback[regno], val);
+}
+} else {
+s->writeback_mask |= 1 << regno;
+if (give_temp) {
+s->writeback[regno] = val;
+} else {
+TCGv tmp = tcg_temp_new();
+s->writeback[regno] = tmp;
+tcg_gen_mov_i32(tmp, val);
+}
+}
+}
+
+static void do_writebacks(DisasContext *s)
+{
+unsigned mask = s->writeback_mask;
+if (mask) {
+s->writeback_mask = 0;
+do {
+unsigned regno = ctz32(mask);
+tcg_gen_mov_i32(cpu_aregs[regno], s->writeback[regno]);
+tcg_temp_free(s->writeback[regno]);
+mask &= mask - 1;
+} while (mask);
+}
+}
+
 #define DISAS_JUMP_NEXT 4
 
 #if defined(CONFIG_USER_ONLY)
@@ -331,7 +378,7 @@ static inline uint32_t read_im32(CPUM68KState *env, 
DisasContext *s)
 }
 
 /* Calculate and address index.  */
-static TCGv gen_addr_index(uint16_t ext, TCGv tmp)
+static TCGv gen_addr_index(DisasContext *s, uint16_t ext, TCGv tmp)
 {
 TCGv add;
 int scale;
@@ -388,7 +435,7 @@ static TCGv gen_lea_indexed(CPUM68KState *env, DisasContext 
*s, TCGv base)
 tmp = tcg_temp_new();
 if ((ext & 0x44) == 0) {
 /* pre-index */
-add = gen_addr_index(ext, tmp);
+add = gen_addr_index(s, ext, tmp);
 } else {
 add = NULL_QREG;
 }
@@ -417,7 +464,7 @@ static TCGv gen_lea_indexed(CPUM68KState *env, DisasContext 
*s, TCGv base)
 /* memory indirect */
 base = gen_load(s, OS_LONG, add, 0);
 if ((ext & 0x44) == 4) {
-add = gen_addr_index(ext, tmp);
+add = gen_addr_index(s, ext, tmp);
 tcg_gen_add_i32(tmp, add, base);
 add = tmp;
 } else {
@@ -441,7 +488,7 @@ static TCGv gen_lea_indexed(CPUM68KState *env, DisasContext 
*s, TCGv base)
 } else {
 /* brief extension word format */
 tmp = tcg_temp_new();
-add = gen_addr_index(ext, tmp);
+add = gen_addr_index(s, ext, tmp);
 if (!IS_NULL_QREG(base)) {
 tcg_gen_add_i32(tmp, add, base);
 if ((int8_t)ext)
@@ -755,10 +802,11 @@ static TCGv gen_ea(CPUM68KState *env, DisasContext *s, 
uint16_t insn,
 case 3: /* Indirect postincrement.  */
 reg = AREG(insn, 0);
 result = gen_ldst(s, opsize, reg, val, what);
-/* ??? This is not exception safe.  The instruction may still
-   fault after this point.  */
-if (what == EA_STORE || !addrp)
-tcg_gen_addi_i32(reg, reg, opsize_bytes(opsize));
+if (what == EA_STORE || !addrp) {
+TCGv tmp = tcg_temp_new();
+tcg_gen_addi_i32(tmp, reg, opsize_bytes(opsize));
+delay_set_areg(s, REG(insn, 0), tmp, true);
+}
 return result;
 case 4: /* Indirect predecrememnt.  */
 {
@@ -773,11 +821,8 @@ static TCGv gen_ea(CPUM68KState *env, DisasContext *s, 
uint16_t insn,
 *addrp = tmp;
 }
 result = gen_ldst(s, opsize, tmp, val, what);
-/* ??? This is not exception safe.  The instruction may still
-   fault after this point.  */
 if (what == EA_STORE || !addrp) {
-reg = 

[Qemu-devel] [PATCH v2 2/3] target-m68k: Split gen_lea and gen_ea

[Richard Henderson]

Provide gen_lea_mode and gen_ea_mode, where the mode can be
specified manually, rather than taken from the instruction.

Signed-off-by: Richard Henderson 
---
 target-m68k/translate.c | 112 +---
 1 file changed, 59 insertions(+), 53 deletions(-)

diff --git a/target-m68k/translate.c b/target-m68k/translate.c
index 25ceb2c..5e73abe 100644
--- a/target-m68k/translate.c
+++ b/target-m68k/translate.c
@@ -697,37 +697,37 @@ static void gen_partset_reg(int opsize, TCGv reg, TCGv 
val)
 
 /* Generate code for an "effective address".  Does not adjust the base
register for autoincrement addressing modes.  */
-static TCGv gen_lea(CPUM68KState *env, DisasContext *s, uint16_t insn,
-int opsize)
+static TCGv gen_lea_mode(CPUM68KState *env, DisasContext *s,
+ int mode, int reg0, int opsize)
 {
 TCGv reg;
 TCGv tmp;
 uint16_t ext;
 uint32_t offset;
 
-switch ((insn >> 3) & 7) {
+switch (mode) {
 case 0: /* Data register direct.  */
 case 1: /* Address register direct.  */
 return NULL_QREG;
 case 2: /* Indirect register */
 case 3: /* Indirect postincrement.  */
-return AREG(insn, 0);
+return get_areg(s, reg0);
 case 4: /* Indirect predecrememnt.  */
-reg = AREG(insn, 0);
+reg = get_areg(s, reg0);
 tmp = tcg_temp_new();
 tcg_gen_subi_i32(tmp, reg, opsize_bytes(opsize));
 return tmp;
 case 5: /* Indirect displacement.  */
-reg = AREG(insn, 0);
+reg = get_areg(s, reg0);
 tmp = tcg_temp_new();
 ext = read_im16(env, s);
 tcg_gen_addi_i32(tmp, reg, (int16_t)ext);
 return tmp;
 case 6: /* Indirect index + displacement.  */
-reg = AREG(insn, 0);
+reg = get_areg(s, reg0);
 return gen_lea_indexed(env, s, reg);
 case 7: /* Other */
-switch (insn & 7) {
+switch (reg0) {
 case 0: /* Absolute short.  */
 offset = (int16_t)read_im16(env, s);
 return tcg_const_i32(offset);
@@ -749,39 +749,26 @@ static TCGv gen_lea(CPUM68KState *env, DisasContext *s, 
uint16_t insn,
 return NULL_QREG;
 }
 
-/* Helper function for gen_ea. Reuse the computed address between the
-   for read/write operands.  */
-static inline TCGv gen_ea_once(CPUM68KState *env, DisasContext *s,
-   uint16_t insn, int opsize, TCGv val,
-   TCGv *addrp, ea_what what)
+static TCGv gen_lea(CPUM68KState *env, DisasContext *s, uint16_t insn,
+int opsize)
 {
-TCGv tmp;
-
-if (addrp && what == EA_STORE) {
-tmp = *addrp;
-} else {
-tmp = gen_lea(env, s, insn, opsize);
-if (IS_NULL_QREG(tmp))
-return tmp;
-if (addrp)
-*addrp = tmp;
-}
-return gen_ldst(s, opsize, tmp, val, what);
+int mode = extract32(insn, 3, 3);
+int reg0 = REG(insn, 0);
+return gen_lea_mode(env, s, mode, reg0, opsize);
 }
 
-/* Generate code to load/store a value from/into an EA.  If VAL > 0 this is
+/* Generate code to load/store a value from/into an EA.  If WHAT > 0 this is
a write otherwise it is a read (0 == sign extend, -1 == zero extend).
ADDRP is non-null for readwrite operands.  */
-static TCGv gen_ea(CPUM68KState *env, DisasContext *s, uint16_t insn,
-   int opsize, TCGv val, TCGv *addrp, ea_what what)
+static TCGv gen_ea_mode(CPUM68KState *env, DisasContext *s, int mode, int reg0,
+int opsize, TCGv val, TCGv *addrp, ea_what what)
 {
-TCGv reg;
-TCGv result;
-uint32_t offset;
+TCGv reg, tmp, result;
+int32_t offset;
 
-switch ((insn >> 3) & 7) {
+switch (mode) {
 case 0: /* Data register direct.  */
-reg = DREG(insn, 0);
+reg = cpu_dregs[reg0];
 if (what == EA_STORE) {
 gen_partset_reg(opsize, reg, val);
 return store_dummy;
@@ -789,7 +776,7 @@ static TCGv gen_ea(CPUM68KState *env, DisasContext *s, 
uint16_t insn,
 return gen_extend(reg, opsize, what == EA_LOADS);
 }
 case 1: /* Address register direct.  */
-reg = AREG(insn, 0);
+reg = get_areg(s, reg0);
 if (what == EA_STORE) {
 tcg_gen_mov_i32(reg, val);
 return store_dummy;
@@ -797,45 +784,56 @@ static TCGv gen_ea(CPUM68KState *env, DisasContext *s, 
uint16_t insn,
 return gen_extend(reg, opsize, what == EA_LOADS);
 }
 case 2: /* Indirect register */
-reg = AREG(insn, 0);
+reg = get_areg(s, reg0);
 return gen_ldst(s, opsize, reg, val, what);
 case 3: /* Indirect postincrement.  */
-reg = AREG(insn, 0);
+reg = get_areg(s, reg0);
 result = gen_ldst(s, opsize, reg, val, what);
 if (what == EA_STORE || !addrp) {
 TCGv tmp = tcg_temp_new();
 

[Qemu-devel] [PATCH v2 3/3] target-m68k: add cmpm

[Richard Henderson]

From: Laurent Vivier 

Signed-off-by: Laurent Vivier 
Reviewed-by: Richard Henderson 
Message-Id: <1477604609-2206-2-git-send-email-laur...@vivier.eu>
Signed-off-by: Richard Henderson 
---
 target-m68k/translate.c | 16 
 1 file changed, 16 insertions(+)

diff --git a/target-m68k/translate.c b/target-m68k/translate.c
index 5e73abe..2e85ca9 100644
--- a/target-m68k/translate.c
+++ b/target-m68k/translate.c
@@ -2224,6 +2224,21 @@ DISAS_INSN(cmpa)
 gen_update_cc_cmp(s, reg, src, opsize);
 }
 
+DISAS_INSN(cmpm)
+{
+int opsize = insn_opsize(insn);
+TCGv src, dst;
+
+/* Post-increment load (mode 3) from Ay.  */
+src = gen_ea_mode(env, s, 3, REG(insn, 0), opsize,
+  NULL_QREG, NULL, EA_LOADS);
+/* Post-increment load (mode 3) from Ax.  */
+dst = gen_ea_mode(env, s, 3, REG(insn, 9), opsize,
+  NULL_QREG, NULL, EA_LOADS);
+
+gen_update_cc_cmp(s, dst, src, opsize);
+}
+
 DISAS_INSN(eor)
 {
 TCGv src;
@@ -3465,6 +3480,7 @@ void register_m68k_insns (CPUM68KState *env)
 INSN(cmpa,  b1c0, f1c0, CF_ISA_A);
 INSN(cmp,   b000, f100, M68000);
 INSN(eor,   b100, f100, M68000);
+INSN(cmpm,  b108, f138, M68000);
 INSN(cmpa,  b0c0, f0c0, M68000);
 INSN(eor,   b180, f1c0, CF_ISA_A);
 BASE(and,   c000, f000);
-- 
2.7.4

Re: [Qemu-devel] [PATCH v2 2/3] target-m68k: implement 680x0 movem

[Richard Henderson]

On 11/02/2016 03:15 PM, Laurent Vivier wrote:

+for (i = 15; i >= 0; i--, mask >>= 1) {
+if (mask & 1) {
+if ((insn & 7) + 8 == i &&
+m68k_feature(s->env, M68K_FEATURE_EXT_FULL)) {
+/* M68020+: if the addressing register is the
+ * register moved to memory, the value written
+ * is the initial value decremented by the size of
+ * the operation
+ * M68000/M68010: the value is the initial value
+ */
+TCGv tmp = tcg_temp_new();
+tcg_gen_sub_i32(tmp, mreg(i), incr);
+gen_store(s, opsize, addr, tmp);
+tcg_temp_free(tmp);
+} else {
+gen_store(s, opsize, addr, mreg(i));
+}
+if (mask != 1) {
+tcg_gen_sub_i32(addr, addr, incr);
+}
+}


One more thing: This is pre-decrement.  Why are you decrementing after the 
store?  Seems to me this should be


   if (mask & 1) {
   tcg_gen_sub_i32(addr, addr, incr);
   if (REG(insn, 0) + 8 == i ...)
   ...
   }


r~

[Qemu-devel] [PATCH 4/5] ARM BE32 watchpoint fix.

[Julian Brown]

In BE32 mode, sub-word size watchpoints can fail to trigger because the
address of the access is adjusted in the opcode helpers before being
compared with the watchpoint registers.  This patch reversed the address
adjustment before performing the comparison.

Signed-off-by: Julian Brown 
---
 exec.c | 13 +
 1 file changed, 13 insertions(+)

diff --git a/exec.c b/exec.c
index 4c84389..eadab54 100644
--- a/exec.c
+++ b/exec.c
@@ -2047,6 +2047,19 @@ static void check_watchpoint(int offset, int len, 
MemTxAttrs attrs, int flags)
 return;
 }
 vaddr = (cpu->mem_io_vaddr & TARGET_PAGE_MASK) + offset;
+#if defined(TARGET_ARM) && !defined(CONFIG_USER_ONLY)
+/* In BE32 system mode, target memory is stored byteswapped (FIXME:
+   relative to a little-endian host system), and by the time we reach here
+   (via an opcode helper) the addresses of subword accesses have been
+   adjusted to account for that, which means that watchpoints will not
+   match.  Undo the adjustment here.  */
+if (arm_sctlr_b(env)) {
+if (len == 1)
+vaddr ^= 3;
+else if (len == 2)
+vaddr ^= 2;
+}
+#endif
 QTAILQ_FOREACH(wp, >watchpoints, entry) {
 if (cpu_watchpoint_address_matches(wp, vaddr, len)
 && (wp->flags & flags)) {
-- 
1.9.1

[Qemu-devel] [PATCH 2/5] Fix Thumb-1 BE32 execution and disassembly.

[Julian Brown]

Thumb-1 code has some issues in BE32 mode (as currently implemented). In
short, since bytes are swapped within words at load time for BE32
executables, this also swaps pairs of adjacent Thumb-1 instructions.

This patch un-swaps those pairs of instructions again, both for execution,
and for disassembly.

Signed-off-by: Julian Brown 
---
 disas/arm.c   | 46 +++---
 include/disas/bfd.h   |  1 +
 target-arm/arm_ldst.h | 10 +-
 target-arm/cpu.c  |  4 
 4 files changed, 49 insertions(+), 12 deletions(-)

diff --git a/disas/arm.c b/disas/arm.c
index 93c6503..4807ba3 100644
--- a/disas/arm.c
+++ b/disas/arm.c
@@ -3863,10 +3863,11 @@ print_insn_arm (bfd_vma pc, struct disassemble_info 
*info)
   int   is_data = false;
   unsigned int size = 4;
   void (*printer) (bfd_vma, struct disassemble_info *, long);
-  int little;
+  int little, is_thumb1_be32 = false;
 
   little = (info->endian == BFD_ENDIAN_LITTLE);
   is_thumb |= (pc & 1);
+  is_thumb1_be32 = (info->flags & INSN_ARM_THUMB1_BE32) != 0;
   pc &= ~(bfd_vma)1;
 
   if (force_thumb)
@@ -3915,11 +3916,22 @@ print_insn_arm (bfd_vma pc, struct disassemble_info 
*info)
   info->bytes_per_chunk = 2;
   size = 2;
 
-  status = info->read_memory_func (pc, (bfd_byte *)b, 2, info);
-  if (little)
-   given = (b[0]) | (b[1] << 8);
-  else
-   given = (b[1]) | (b[0] << 8);
+  if (is_thumb1_be32) {
+  status = info->read_memory_func(pc & ~3, (bfd_byte *)b, 4, info);
+  assert(little);
+  if ((pc & 2) == 0) {
+  given = b[2] | (b[3] << 8);
+  } else {
+  given = b[0] | (b[1] << 8);
+  }
+  } else {
+  status = info->read_memory_func(pc, (bfd_byte *)b, 2, info);
+  if (little) {
+  given = (b[0]) | (b[1] << 8);
+  } else {
+  given = (b[1]) | (b[0] << 8);
+  }
+  }
 
   if (!status)
{
@@ -3929,11 +3941,23 @@ print_insn_arm (bfd_vma pc, struct disassemble_info 
*info)
  || (given & 0xF800) == 0xF000
  || (given & 0xF800) == 0xE800)
{
- status = info->read_memory_func (pc + 2, (bfd_byte *)b, 2, info);
- if (little)
-   given = (b[0]) | (b[1] << 8) | (given << 16);
- else
-   given = (b[1]) | (b[0] << 8) | (given << 16);
+  if (is_thumb1_be32) {
+  status = info->read_memory_func((pc + 2) & ~3,
+  (bfd_byte *)b, 4, info);
+  if (((pc + 2) & 2) == 0) {
+  given = b[2] | (b[3] << 8) | (given << 16);
+  } else {
+  given = b[0] | (b[1] << 8) | (given << 16);
+  }
+  } else {
+  status = info->read_memory_func(pc + 2, (bfd_byte *)b, 2,
+  info);
+  if (little) {
+  given = (b[0]) | (b[1] << 8) | (given << 16);
+  } else {
+  given = (b[1]) | (b[0] << 8) | (given << 16);
+  }
+  }
 
  printer = print_insn_thumb32;
  size = 4;
diff --git a/include/disas/bfd.h b/include/disas/bfd.h
index 8a3488c..76ff6a0 100644
--- a/include/disas/bfd.h
+++ b/include/disas/bfd.h
@@ -291,6 +291,7 @@ typedef struct disassemble_info {
  The bottom 16 bits are for the internal use of the disassembler.  */
   unsigned long flags;
 #define INSN_HAS_RELOC 0x8000
+#define INSN_ARM_THUMB1_BE32 0x0001
   PTR private_data;
 
   /* Function used to get bytes to disassemble.  MEMADDR is the
diff --git a/target-arm/arm_ldst.h b/target-arm/arm_ldst.h
index a76d89f..01587b3 100644
--- a/target-arm/arm_ldst.h
+++ b/target-arm/arm_ldst.h
@@ -39,7 +39,15 @@ static inline uint32_t arm_ldl_code(CPUARMState *env, 
target_ulong addr,
 static inline uint16_t arm_lduw_code(CPUARMState *env, target_ulong addr,
  bool sctlr_b)
 {
-uint16_t insn = cpu_lduw_code(env, addr);
+uint16_t insn;
+#ifndef CONFIG_USER_ONLY
+/* In big-endian (BE32) mode, adjacent Thumb instructions have been swapped
+   within each word.  Undo that now.  */
+if (sctlr_b) {
+addr ^= 2;
+}
+#endif
+insn = cpu_lduw_code(env, addr);
 if (bswap_code(sctlr_b)) {
 return bswap16(insn);
 }
diff --git a/target-arm/cpu.c b/target-arm/cpu.c
index 2918b24..b9d7393 100644
--- a/target-arm/cpu.c
+++ b/target-arm/cpu.c
@@ -423,6 +423,10 @@ static void arm_disas_set_info(CPUState *cpu, 
disassemble_info *info)
 #endif
 } else if (env->thumb) {
 info->print_insn = print_insn_thumb1;
+info->flags &= ~INSN_ARM_THUMB1_BE32;
+if (arm_sctlr_b(env)) {
+info->flags |= INSN_ARM_THUMB1_BE32;
+}
 } else {
  

[Qemu-devel] [PATCH 3/5] Fix arm_semi_flen_cb for BE32 system mode.

[Julian Brown]

This patch fixes the arm_semi_flen_cb callback so that it doesn't return
a byte-swapped size in BE32 system mode.

Signed-off-by: Julian Brown 
---
 target-arm/arm-semi.c | 10 ++
 1 file changed, 10 insertions(+)

diff --git a/target-arm/arm-semi.c b/target-arm/arm-semi.c
index a9cf5f2..6c550d0 100644
--- a/target-arm/arm-semi.c
+++ b/target-arm/arm-semi.c
@@ -188,7 +188,17 @@ static void arm_semi_flen_cb(CPUState *cs, target_ulong 
ret, target_ulong err)
the value. We assume the size always fit in 32 bits.  */
 uint32_t size;
 cpu_memory_rw_debug(cs, arm_flen_buf(cpu) + 32, (uint8_t *), 4, 0);
+#ifdef CONFIG_USER_ONLY
 size = be32_to_cpu(size);
+#else
+/* If we're running in BE32 system mode, we don't need to do an explicit
+ * byte swap, because (I think) target memory is already stored in
+ * byte-swapped format.
+ */
+if (!arm_sctlr_b(env)) {
+size = be32_to_cpu(size);
+}
+#endif
 if (is_a64(env)) {
 env->xregs[0] = size;
 } else {
-- 
1.9.1

[Qemu-devel] [PATCH 0/5] ARM BE8/BE32 big-endian system-mode fixes (semihosting, gdbstub)

[Julian Brown]

This patch series contains a few fixes for ARM big-endian system mode
that appear beneficial for our use case of running bare-metal code with
semihosting (for toolchain testing), and running code via the built-in
gdbstub (for debugger testing). The patches are mostly relevant to BE32
mode, but contain some BE8 mode fixes also.

I haven't been following QEMU development terribly closely, so apologies
in advance if these patches are moving along the wrong trajectory! I
hope they're useful as a starting point though, at least.

I have tested (modulo formatting cleanups suggested by checkpatch.pl)
these patches against GCC (in particular ARMv7 LE, BE8 multilibs and
ARMv5te LE, BE32 multilibs), and GDB, with Mentor's internal test
infrastructure (though I needed some other minor local patches to make
QEMU work better with that). Let me know if there's other testing I
should do.

Thank you,

Julian

Julian Brown (5):
  ARM BE8/BE32 semihosting and gdbstub support.
  Fix Thumb-1 BE32 execution and disassembly.
  Fix arm_semi_flen_cb for BE32 system mode.
  ARM BE32 watchpoint fix.
  Fix typo in arm_cpu_do_interrupt_aarch32.

 disas/arm.c |  46 ++---
 exec.c  |  13 
 hw/arm/boot.c   |  16 -
 include/disas/bfd.h |   1 +
 include/exec/softmmu-arm-semi.h | 148 
 target-arm/arm-semi.c   |  12 +++-
 target-arm/arm_ldst.h   |  10 ++-
 target-arm/cpu.c|  53 ++
 target-arm/gdbstub.c|  42 
 target-arm/helper.c |   2 +-
 10 files changed, 328 insertions(+), 15 deletions(-)
 create mode 100644 include/exec/softmmu-arm-semi.h

-- 
1.9.1

[Qemu-devel] [PATCH 1/5] ARM BE8/BE32 semihosting and gdbstub support.

[Julian Brown]

This patch improves support for semihosting and debugging with the
in-built gdbstub for ARM system-mode emulation in big-endian mode (either
BE8 or BE32), after the fairly recent changes to allow a single QEMU
binary to deal with each of LE, BE8 and BE32 modes in one. It's only
currently good for little-endian host systems. The relevant use case
is using QEMU as a "bare metal" instruction-set simulator, e.g. for
toolchain testing.

For semihosting, the softmmu-semi.h file is overridden with an
ARM-specific version that knows about byte-swapping target memory into
host order -- including that which has been byte-swapped at load time
for BE32 mode.

For the gdbstub, we'd like to be able to invoke QEMU from GDB like:

(gdb) target remote | arm-qemu-system -cpu=foo [options] /dev/null
(gdb) load
(gdb) ...

which unfortunately bypasses the probing of the loaded ELF file (since
it's just /dev/null) to determine whether to use BE8/BE32 mode. So,
I added some "virtual" CPUs to set the endian type instead (arm926-be,
cortex-a15-be for BE32/BE8 mode respectively), from the reset value
of the SCTLR. This is kind of like having a configuration input to the
CPU on some hardware board to select endianness, which is a completely
legitimate thing to have, even if the implementation as-is is not really
ideal from a software-engineering standpoint. It suffices for our current
use-case though.

Signed-off-by: Julian Brown 
---
 hw/arm/boot.c   |  16 -
 include/exec/softmmu-arm-semi.h | 148 
 target-arm/arm-semi.c   |   2 +-
 target-arm/cpu.c|  49 +
 target-arm/gdbstub.c|  42 
 5 files changed, 255 insertions(+), 2 deletions(-)
 create mode 100644 include/exec/softmmu-arm-semi.h

diff --git a/hw/arm/boot.c b/hw/arm/boot.c
index 942416d..644fdaf 100644
--- a/hw/arm/boot.c
+++ b/hw/arm/boot.c
@@ -894,7 +894,21 @@ static void arm_load_kernel_notify(Notifier *notifier, 
void *data)
 entry = info->loader_start + kernel_load_offset;
 kernel_size = load_image_targphys(info->kernel_filename, entry,
   info->ram_size - kernel_load_offset);
-is_linux = 1;
+if (kernel_size > 0) {
+is_linux = 1;
+} else {
+/* We've been launched with a kernel of /dev/null or similar.
+ * Infer endianness from the reset value of the SCTLR for this
+ * CPU/board (FIXME: a way of configuring this more nicely).
+ */
+if (!arm_feature(>env, ARM_FEATURE_V7) &&
+(cpu->reset_sctlr & SCTLR_B) != 0)
+info->endianness = ARM_ENDIANNESS_BE32;
+else if ((cpu->reset_sctlr & SCTLR_EE) != 0)
+info->endianness = ARM_ENDIANNESS_BE8;
+else
+info->endianness = ARM_ENDIANNESS_LE;
+}
 }
 if (kernel_size < 0) {
 fprintf(stderr, "qemu: could not load kernel '%s'\n",
diff --git a/include/exec/softmmu-arm-semi.h b/include/exec/softmmu-arm-semi.h
new file mode 100644
index 000..e9ddb21
--- /dev/null
+++ b/include/exec/softmmu-arm-semi.h
@@ -0,0 +1,148 @@
+/*
+ * Helper routines to provide target memory access for ARM semihosting
+ * syscalls in system emulation mode.
+ *
+ * Copyright (c) 2007 CodeSourcery, (c) 2016 Mentor Graphics
+ *
+ * This code is licensed under the GPL
+ */
+
+#ifndef SOFTMMU_ARM_SEMI_H
+#define SOFTMMU_ARM_SEMI_H 1
+
+/* In BE32 system mode, the CPU-specific memory_rw_debug method will arrange to
+ * perform byteswapping on the target memory, so that it appears to the host as
+ * it appears to the emulated CPU.  Memory is read verbatim in BE8 mode.  (In
+ * other words, this function arranges so that BUF has the same format in both
+ * BE8 and BE32 system mode.)
+ */
+
+static inline int armsemi_memory_rw_debug(CPUState *cpu, target_ulong addr,
+  uint8_t *buf, int len, bool is_write)
+{
+CPUClass *cc = CPU_GET_CLASS(cpu);
+
+if (cc->memory_rw_debug) {
+return cc->memory_rw_debug(cpu, addr, buf, len, is_write);
+}
+return cpu_memory_rw_debug(cpu, addr, buf, len, is_write);
+}
+
+/* In big-endian mode (either BE8 or BE32), values larger than a byte will be
+ * transferred to/from memory in big-endian format.  Assuming we're on a
+ * little-endian host machine, such values will need to be byteswapped before
+ * and after the host processes them.
+ *
+ * This means that byteswapping will occur *twice* in BE32 mode for
+ * halfword/word reads/writes.
+ */
+
+static inline bool arm_bswap_needed(CPUARMState *env)
+{
+#ifdef HOST_WORDS_BIGENDIAN
+#error HOST_WORDS_BIGENDIAN is not supported for ARM semihosting at the moment.
+#else
+return arm_sctlr_b(env) || (env->uncached_cpsr & CPSR_E) != 0;
+#endif
+}
+
+static inline uint64_t softmmu_tget64(CPUArchState *env, target_ulong addr)
+{
+

Re: [Qemu-devel] [PATCH v2 2/3] target-m68k: implement 680x0 movem

[Laurent Vivier]

Le 03/11/2016 à 20:47, Richard Henderson a écrit :
> On 11/02/2016 03:15 PM, Laurent Vivier wrote:
>> +if ((insn & 7) + 8 == i &&
>> +m68k_feature(s->env, M68K_FEATURE_EXT_FULL)) {
>> +/* M68020+: if the addressing register is the
>> + * register moved to memory, the value written
>> + * is the initial value decremented by the
>> size of
>> + * the operation
>> + * M68000/M68010: the value is the initial value
>> + */
>> +TCGv tmp = tcg_temp_new();
>> +tcg_gen_sub_i32(tmp, mreg(i), incr);
>> +gen_store(s, opsize, addr, tmp);
>> +tcg_temp_free(tmp);
> 
> This doesn't look right.  Is the value stored the intermediate value of
> the decremented register, or the final value?  What you're storing is
> reg-4, which is neither of these things.
>
> I could see, maybe, that reg-4 might well turn out to be the right value
> for
> 
> movem{a0-a7}, (sp)-
> 
> since sp == a7, and therefore stored first.  But I question that's the
> correct result for
> 
> movem{a0-a7}, (a1)-
> 
> If it's the incremental value, then you can just store "addr" and you
> don't need a temp.  If it's the final value, then you can compute
> 
> tcg_gen_subi_i32(tmp, AREG(insn, 0), ctpop32(mask) * 4);
> 

As it was not clear for me, I have written a test to see what was the
good value.

my test program is:

top:
.space 64,0
stack:
.text
.globl _start
_start:
lea stack,%a4
lea 1,%a0
lea 2,%a1
lea 3,%a2
lea 4,%a3
lea 5,%a5
lea 6,%a6
moveq.l #8, %d0
moveq.l #9, %d1
moveq.l #10, %d2
moveq.l #11, %d3
moveq.l #12, %d4
moveq.l #13, %d5
moveq.l #14, %d6
moveq.l #15, %d7
movem.l %a0-%a7/%d0-%d7,-(%a4)

on a real 68040:

initial value of A4 is 0x800020ec
final value of A4 is   0x800020ac

(gdb) x/15x 0x800020ac
0x800020ac: 0x0008  0x0009  0x000a  0x000b
0x800020bc: 0x000c  0x000d  0x000e  0x000f
0x800020cc: 0x0001  0x0002  0x0003  0x0004
0x800020dc: 0x800020e8  0x0005  0x0006

Stored value is thus 0x800020e8 so this is initial value - 4.
[I have tried the same test with a1, for the same result]

Laurent

Re: [Qemu-devel] [PATCH v4 4/5] backends: add description for enum class properties

[Markus Armbruster]

Lin Ma  writes:

> Signed-off-by: Lin Ma 
> ---
>  backends/hostmem.c | 4 
>  crypto/secret.c| 4 
>  crypto/tlscreds.c  | 4 
>  net/filter.c   | 4 
>  4 files changed, 16 insertions(+)
>
> diff --git a/backends/hostmem.c b/backends/hostmem.c
> index 4256d24..25f303d 100644
> --- a/backends/hostmem.c
> +++ b/backends/hostmem.c
> @@ -377,6 +377,10 @@ host_memory_backend_class_init(ObjectClass *oc, void 
> *data)
>  HostMemPolicy_lookup,
>  host_memory_backend_get_policy,
>  host_memory_backend_set_policy, _abort);
> +object_class_property_set_description(oc, "policy",
> +"Data format: one of "
> +HostMemPolicy_value_str,
> +_abort);
>  }
>  
>  static const TypeInfo host_memory_backend_info = {
> diff --git a/crypto/secret.c b/crypto/secret.c
> index 285ab7a..71d06e3 100644
> --- a/crypto/secret.c
> +++ b/crypto/secret.c
> @@ -382,6 +382,10 @@ qcrypto_secret_class_init(ObjectClass *oc, void *data)
> qcrypto_secret_prop_get_format,
> qcrypto_secret_prop_set_format,
> NULL);
> +object_class_property_set_description(oc, "format",
> +  "Data format: one of "
> +  QCryptoSecretFormat_value_str,
> +  _abort);
>  object_class_property_add_str(oc, "data",
>qcrypto_secret_prop_get_data,
>qcrypto_secret_prop_set_data,
> diff --git a/crypto/tlscreds.c b/crypto/tlscreds.c
> index a896553..d3af38a 100644
> --- a/crypto/tlscreds.c
> +++ b/crypto/tlscreds.c
> @@ -237,6 +237,10 @@ qcrypto_tls_creds_class_init(ObjectClass *oc, void *data)
> qcrypto_tls_creds_prop_get_endpoint,
> qcrypto_tls_creds_prop_set_endpoint,
> NULL);
> +object_class_property_set_description(oc, "endpoint",
> +  "Data format: one of "
> +  QCryptoTLSCredsEndpoint_value_str,
> +  _abort);
>  object_class_property_add_str(oc, "priority",
>qcrypto_tls_creds_prop_get_priority,
>qcrypto_tls_creds_prop_set_priority,
> diff --git a/net/filter.c b/net/filter.c
> index 1dfd2ca..205fb49 100644
> --- a/net/filter.c
> +++ b/net/filter.c
> @@ -182,6 +182,10 @@ static void netfilter_init(Object *obj)
>   NetFilterDirection_lookup,
>   netfilter_get_direction, 
> netfilter_set_direction,
>   NULL);
> +object_property_set_description(obj, "queue",
> +"Data format: one of "
> +NetFilterDirection_value_str,
> +_abort);
>  object_property_add_str(obj, "status",
>  netfilter_get_status, netfilter_set_status,
>  NULL);

After  each

object_class_property_add_enum(OC, PROP_NAME", ENUM_NAME, ...);

you add

object_class_property_set_description(OC, PROP_NAME,
  "Data format: one of "
  ENUM_NAME_value_str,
  _abort);

Whenever somebody adds another object_class_property_add_enum(), he
should also add an object_class_property_set_description().  Easily
forgotten.

Why not do it in object_class_property_add_enum() automatically?
We got strings[] there...

Re: [Qemu-devel] [PATCH v4 5/5] object: Add 'help' option for all available backends and properties

[Markus Armbruster]

Lin Ma  writes:

> '-object help' prints available user creatable backends.
> '-object $typename,help' prints relevant properties.
>
> Signed-off-by: Lin Ma 
> ---
>  include/qom/object_interfaces.h |  2 ++
>  qemu-options.hx |  7 +-
>  qom/object_interfaces.c | 55 
> +
>  vl.c|  5 
>  4 files changed, 68 insertions(+), 1 deletion(-)
>
> diff --git a/include/qom/object_interfaces.h b/include/qom/object_interfaces.h
> index 8b17f4d..197cd5f 100644
> --- a/include/qom/object_interfaces.h
> +++ b/include/qom/object_interfaces.h
> @@ -165,4 +165,6 @@ int user_creatable_add_opts_foreach(void *opaque,
>   */
>  void user_creatable_del(const char *id, Error **errp);
>  
> +int user_creatable_help_func(void *opaque, QemuOpts *opts, Error **errp);
> +

Ugly interface: two arguments that aren't used, one of them void *.
Suggest to follow the device help example: do a non-ugly interface here,
and an ugly, but static wrapper in vl.c

>  #endif
> diff --git a/qemu-options.hx b/qemu-options.hx
> index b1fbdb0..b9573ce 100644
> --- a/qemu-options.hx
> +++ b/qemu-options.hx
> @@ -3761,7 +3761,9 @@ DEF("object", HAS_ARG, QEMU_OPTION_object,
>  "create a new object of type TYPENAME setting 
> properties\n"
>  "in the order they are specified.  Note that the 'id'\n"
>  "property must be set.  These objects are placed in 
> the\n"
> -"'/objects' path.\n",
> +"'/objects' path.\n"
> +"Use '-object help' to print available backend types 
> and\n"
> +"'-object typename,help' to print relevant 
> properties.\n",

The existing text talks about "object of type TYPENAME".  The new text
suddenly talks about "backend types".  Switching terminology is not a
good idea.  Call them "object types".

For comparison, here's the text we use for -device:

use '-device help' to print all possible drivers
use '-device driver,help' to print all possible properties

Let's make this one similar:

use '-object help' to print all possible object types
use '-object driver,help' to print all possible properties

>  QEMU_ARCH_ALL)
>  STEXI
>  @item -object @var{typename}[,@var{prop1}=@var{value1},...]
> @@ -3771,6 +3773,9 @@ in the order they are specified.  Note that the 'id'
>  property must be set.  These objects are placed in the
>  '/objects' path.
>  
> +Use @code{-object help} to print available backend types and
> +@code{-object @var{typename},help} to print relevant properties.
> +

-device's text:

To get help on possible drivers and properties, use @code{-device
help} and @code{-device @var{driver},help}.

Suggest:

To get help on possible object types and properties, use @code{-object
help} and @code{-object @var{type},help}.

>  @table @option
>  
>  @item -object 
> memory-backend-file,id=@var{id},size=@var{size},mem-path=@var{dir},share=@var{on|off}
> diff --git a/qom/object_interfaces.c b/qom/object_interfaces.c
> index bf59846..da8be39 100644
> --- a/qom/object_interfaces.c
> +++ b/qom/object_interfaces.c
> @@ -5,6 +5,7 @@
>  #include "qapi-visit.h"
>  #include "qapi/qmp-output-visitor.h"
>  #include "qapi/opts-visitor.h"
> +#include "qemu/help_option.h"
>  
>  void user_creatable_complete(Object *obj, Error **errp)
>  {
> @@ -212,6 +213,60 @@ void user_creatable_del(const char *id, Error **errp)
>  object_unparent(obj);
>  }
>  
> +int user_creatable_help_func(void *opaque, QemuOpts *opts, Error **errp)
> +{
> +const char *type = NULL;
> +Object *obj = NULL;
> +ObjectClass *klass;
> +ObjectProperty *prop;
> +ObjectPropertyIterator iter;
> +
> +type = qemu_opt_get(opts, "qom-type");
> +if (type && is_help_option(type)) {
> +GSList *list;
> +printf("Available object backend types:\n");

Wrong when running for an HMP monitor command, e.g. "object_add help".
Use error_printf().  That's only slightly wrong in that it prints to
stderr instead of stdout running for the command line.

> +for (list = object_class_get_list(TYPE_USER_CREATABLE, false);  \
> +list;   \
> +list = list->next) {

Superfluous line continuations.  Simply write

   for (list = object_class_get_list(TYPE_USER_CREATABLE, false);
list;
list = list->next) {

Alternatively,

   list = object_class_get_list(TYPE_USER_CREATABLE, false);
   for (elt = list; elt; elt = elt->next) {

> +const char *name;
> +name = object_class_get_name(OBJECT_CLASS(list->data));
> +if (strcmp(name, TYPE_USER_CREATABLE)) {
> +printf("%s\n", name);

error_printf()

> +}
> +}
> +

Re: [Qemu-devel] [PATCH V2 07/11] virtio-pci: address space translation service (ATS) support

[Michael S. Tsirkin]

On Thu, Nov 03, 2016 at 05:27:19PM +0800, Jason Wang wrote:
> This patches enable the Address Translation Service support for virtio
> pci devices. This is needed for a guest visible Device IOTLB
> implementation and will be required by vhost device IOTLB API
> implementation for intel IOMMU.
> 
> Cc: Michael S. Tsirkin 
> Signed-off-by: Jason Wang 

I'd like to understand why do you think this is strictly required.
Won't setting CM bit in the IOMMU do the trick.

Also, could you remind me pls - can guests just disable ATS?

What happens then?


> ---
>  hw/pci/pcie.c | 16 
>  hw/virtio/virtio-pci.c|  7 +++
>  hw/virtio/virtio-pci.h|  4 
>  include/hw/pci/pcie.h |  4 
>  include/standard-headers/linux/pci_regs.h |  1 +
>  5 files changed, 32 insertions(+)
> 
> diff --git a/hw/pci/pcie.c b/hw/pci/pcie.c
> index 99cfb45..02195d9 100644
> --- a/hw/pci/pcie.c
> +++ b/hw/pci/pcie.c
> @@ -717,3 +717,19 @@ void pcie_dev_ser_num_init(PCIDevice *dev, uint16_t 
> offset, uint64_t ser_num)
>  PCI_EXT_CAP_DSN_SIZEOF);
>  pci_set_quad(dev->config + offset + pci_dsn_cap, ser_num);
>  }
> +
> +void pcie_ats_init(PCIDevice *dev, uint16_t offset)
> +{
> +pcie_add_capability(dev, PCI_EXT_CAP_ID_ATS, 0x1,
> +offset, PCI_EXT_CAP_ATS_SIZEOF);
> +
> +dev->exp.ats_cap = offset;
> +
> +/* Invalidate Queue Depth 0, Page Aligned Request 0 */
> +pci_set_word(dev->config + offset + PCI_ATS_CAP, 0);
> +/* STU 0, Disabled by default */
> +pci_set_word(dev->config + offset + PCI_ATS_CTRL, 0);
> +
> +pci_set_word(dev->wmask + dev->exp.ats_cap + PCI_ATS_CTRL, 0x800f);
> +}
> +
> diff --git a/hw/virtio/virtio-pci.c b/hw/virtio/virtio-pci.c
> index 6ceb43e..e357bdf 100644
> --- a/hw/virtio/virtio-pci.c
> +++ b/hw/virtio/virtio-pci.c
> @@ -1838,6 +1838,11 @@ static void virtio_pci_realize(PCIDevice *pci_dev, 
> Error **errp)
>   * PCI Power Management Interface Specification.
>   */
>  pci_set_word(pci_dev->config + pos + PCI_PM_PMC, 0x3);
> +
> +if (proxy->flags & VIRTIO_PCI_FLAG_ATS) {
> +pcie_ats_init(pci_dev, 256);
> +}
> +
>  } else {
>  /*
>   * make future invocations of pci_is_express() return false
> @@ -1889,6 +1894,8 @@ static Property virtio_pci_properties[] = {
>  VIRTIO_PCI_FLAG_DISABLE_PCIE_BIT, false),
>  DEFINE_PROP_BIT("page-per-vq", VirtIOPCIProxy, flags,
>  VIRTIO_PCI_FLAG_PAGE_PER_VQ_BIT, false),
> +DEFINE_PROP_BIT("ats", VirtIOPCIProxy, flags,
> +VIRTIO_PCI_FLAG_ATS_BIT, false),
>  DEFINE_PROP_END_OF_LIST(),
>  };
>  
> diff --git a/hw/virtio/virtio-pci.h b/hw/virtio/virtio-pci.h
> index b4edea6..057d49d 100644
> --- a/hw/virtio/virtio-pci.h
> +++ b/hw/virtio/virtio-pci.h
> @@ -69,6 +69,7 @@ enum {
>  VIRTIO_PCI_FLAG_MODERN_PIO_NOTIFY_BIT,
>  VIRTIO_PCI_FLAG_DISABLE_PCIE_BIT,
>  VIRTIO_PCI_FLAG_PAGE_PER_VQ_BIT,
> +VIRTIO_PCI_FLAG_ATS_BIT,
>  };
>  
>  /* Need to activate work-arounds for buggy guests at vmstate load. */
> @@ -93,6 +94,9 @@ enum {
>  #define VIRTIO_PCI_FLAG_PAGE_PER_VQ \
>  (1 << VIRTIO_PCI_FLAG_PAGE_PER_VQ_BIT)
>  
> +/* address space translation service */
> +#define VIRTIO_PCI_FLAG_ATS (1 << VIRTIO_PCI_FLAG_ATS_BIT)
> +
>  typedef struct {
>  MSIMessage msg;
>  int virq;
> diff --git a/include/hw/pci/pcie.h b/include/hw/pci/pcie.h
> index 056d25e..b08451d 100644
> --- a/include/hw/pci/pcie.h
> +++ b/include/hw/pci/pcie.h
> @@ -74,6 +74,9 @@ struct PCIExpressDevice {
>  /* AER */
>  uint16_t aer_cap;
>  PCIEAERLog aer_log;
> +
> +/* Offset of ATS capability in config space */
> +uint16_t ats_cap;
>  };
>  
>  #define COMPAT_PROP_PCP "power_controller_present"
> @@ -120,6 +123,7 @@ void pcie_add_capability(PCIDevice *dev,
>  
>  void pcie_ari_init(PCIDevice *dev, uint16_t offset, uint16_t nextfn);
>  void pcie_dev_ser_num_init(PCIDevice *dev, uint16_t offset, uint64_t 
> ser_num);
> +void pcie_ats_init(PCIDevice *dev, uint16_t offset);
>  
>  extern const VMStateDescription vmstate_pcie_device;
>  
> diff --git a/include/standard-headers/linux/pci_regs.h 
> b/include/standard-headers/linux/pci_regs.h
> index 4040951..ac426a0 100644
> --- a/include/standard-headers/linux/pci_regs.h
> +++ b/include/standard-headers/linux/pci_regs.h
> @@ -674,6 +674,7 @@
>  #define PCI_EXT_CAP_ID_MAX   PCI_EXT_CAP_ID_DPC
>  
>  #define PCI_EXT_CAP_DSN_SIZEOF   12
> +#define PCI_EXT_CAP_ATS_SIZEOF   8
>  #define PCI_EXT_CAP_MCAST_ENDPOINT_SIZEOF 40
>  
>  /* Advanced Error Reporting */
> -- 
> 2.7.4

Re: [Qemu-devel] [PATCH v2 2/3] target-m68k: implement 680x0 movem

[Richard Henderson]

On 11/02/2016 03:15 PM, Laurent Vivier wrote:

+if ((insn & 7) + 8 == i &&
+m68k_feature(s->env, M68K_FEATURE_EXT_FULL)) {
+/* M68020+: if the addressing register is the
+ * register moved to memory, the value written
+ * is the initial value decremented by the size of
+ * the operation
+ * M68000/M68010: the value is the initial value
+ */
+TCGv tmp = tcg_temp_new();
+tcg_gen_sub_i32(tmp, mreg(i), incr);
+gen_store(s, opsize, addr, tmp);
+tcg_temp_free(tmp);


This doesn't look right.  Is the value stored the intermediate value of the 
decremented register, or the final value?  What you're storing is reg-4, which 
is neither of these things.


I could see, maybe, that reg-4 might well turn out to be the right value for

movem   {a0-a7}, (sp)-

since sp == a7, and therefore stored first.  But I question that's the correct 
result for


movem   {a0-a7}, (a1)-

If it's the incremental value, then you can just store "addr" and you don't 
need a temp.  If it's the final value, then you can compute


tcg_gen_subi_i32(tmp, AREG(insn, 0), ctpop32(mask) * 4);



r~

Re: [Qemu-devel] [PATCH V2 02/11] virtio: convert to use DMA api

[Michael S. Tsirkin]

On Thu, Nov 03, 2016 at 05:27:14PM +0800, Jason Wang wrote:
> Currently, all virtio devices bypass IOMMU completely. This is because
> address_space_memory is assumed and used during DMA emulation. This
> patch converts the virtio core API to use DMA API. This idea is
> 
> - introducing a new transport specific helper to query the dma address
>   space. (only pci version is implemented).
> - query and use this address space during virtio device guest memory
>   accessing when iommu platform (VIRTIO_F_IOMMU_PLATFORM) was enabled
>   for this device.
> 
> Cc: Michael S. Tsirkin 
> Cc: Stefan Hajnoczi 
> Cc: Kevin Wolf 
> Cc: Amit Shah 
> Cc: Paolo Bonzini 
> Cc: qemu-bl...@nongnu.org
> Signed-off-by: Jason Wang 
> ---
>  hw/block/virtio-blk.c |  2 +-
>  hw/char/virtio-serial-bus.c   |  3 ++-
>  hw/scsi/virtio-scsi.c |  4 ++-
>  hw/virtio/virtio-bus.c|  8 ++
>  hw/virtio/virtio-pci.c| 14 ++
>  hw/virtio/virtio.c| 57 
> +--
>  include/hw/virtio/virtio-access.h | 36 ++---
>  include/hw/virtio/virtio-bus.h|  1 +
>  include/hw/virtio/virtio.h|  9 ---
>  9 files changed, 98 insertions(+), 36 deletions(-)
> 
> diff --git a/hw/block/virtio-blk.c b/hw/block/virtio-blk.c
> index 37fe72b..6a2dbaf 100644
> --- a/hw/block/virtio-blk.c
> +++ b/hw/block/virtio-blk.c
> @@ -860,7 +860,7 @@ static int virtio_blk_load_device(VirtIODevice *vdev, 
> QEMUFile *f,
>  }
>  }
>  
> -req = qemu_get_virtqueue_element(f, sizeof(VirtIOBlockReq));
> +req = qemu_get_virtqueue_element(vdev, f, sizeof(VirtIOBlockReq));
>  virtio_blk_init_request(s, virtio_get_queue(vdev, vq_idx), req);
>  req->next = s->rq;
>  s->rq = req;
> diff --git a/hw/char/virtio-serial-bus.c b/hw/char/virtio-serial-bus.c
> index 7975c2c..d544cd9 100644
> --- a/hw/char/virtio-serial-bus.c
> +++ b/hw/char/virtio-serial-bus.c
> @@ -732,6 +732,7 @@ static void virtio_serial_post_load_timer_cb(void *opaque)
>  static int fetch_active_ports_list(QEMUFile *f,
> VirtIOSerial *s, uint32_t nr_active_ports)
>  {
> +VirtIODevice *vdev = VIRTIO_DEVICE(s);
>  uint32_t i;
>  
>  s->post_load = g_malloc0(sizeof(*s->post_load));
> @@ -765,7 +766,7 @@ static int fetch_active_ports_list(QEMUFile *f,
>  qemu_get_be64s(f, >iov_offset);
>  
>  port->elem =
> -qemu_get_virtqueue_element(f, sizeof(VirtQueueElement));
> +qemu_get_virtqueue_element(vdev, f, 
> sizeof(VirtQueueElement));
>  
>  /*
>   *  Port was throttled on source machine.  Let's
> diff --git a/hw/scsi/virtio-scsi.c b/hw/scsi/virtio-scsi.c
> index 4762f05..1519cee 100644
> --- a/hw/scsi/virtio-scsi.c
> +++ b/hw/scsi/virtio-scsi.c
> @@ -198,12 +198,14 @@ static void *virtio_scsi_load_request(QEMUFile *f, 
> SCSIRequest *sreq)
>  SCSIBus *bus = sreq->bus;
>  VirtIOSCSI *s = container_of(bus, VirtIOSCSI, bus);
>  VirtIOSCSICommon *vs = VIRTIO_SCSI_COMMON(s);
> +VirtIODevice *vdev = VIRTIO_DEVICE(s);
>  VirtIOSCSIReq *req;
>  uint32_t n;
>  
>  qemu_get_be32s(f, );
>  assert(n < vs->conf.num_queues);
> -req = qemu_get_virtqueue_element(f, sizeof(VirtIOSCSIReq) + 
> vs->cdb_size);
> +req = qemu_get_virtqueue_element(vdev, f,
> + sizeof(VirtIOSCSIReq) + vs->cdb_size);
>  virtio_scsi_init_req(s, vs->cmd_vqs[n], req);
>  
>  if (virtio_scsi_parse_req(req, sizeof(VirtIOSCSICmdReq) + vs->cdb_size,
> diff --git a/hw/virtio/virtio-bus.c b/hw/virtio/virtio-bus.c
> index 11f65bd..8597762 100644
> --- a/hw/virtio/virtio-bus.c
> +++ b/hw/virtio/virtio-bus.c
> @@ -28,6 +28,7 @@
>  #include "hw/qdev.h"
>  #include "hw/virtio/virtio-bus.h"
>  #include "hw/virtio/virtio.h"
> +#include "exec/address-spaces.h"
>  
>  /* #define DEBUG_VIRTIO_BUS */
>  
> @@ -61,6 +62,13 @@ void virtio_bus_device_plugged(VirtIODevice *vdev, Error 
> **errp)
>  if (klass->device_plugged != NULL) {
>  klass->device_plugged(qbus->parent, errp);
>  }
> +
> +if (klass->get_dma_as != NULL &&
> +virtio_host_has_feature(vdev, VIRTIO_F_IOMMU_PLATFORM)) {
> +vdev->dma_as = klass->get_dma_as(qbus->parent);
> +} else {
> +vdev->dma_as = _space_memory;
> +}
>  }
>  
>  /* Reset the virtio_bus */
> diff --git a/hw/virtio/virtio-pci.c b/hw/virtio/virtio-pci.c
> index 06831de..6ceb43e 100644
> --- a/hw/virtio/virtio-pci.c
> +++ b/hw/virtio/virtio-pci.c
> @@ -1168,6 +1168,14 @@ static int virtio_pci_query_nvectors(DeviceState *d)
>  return proxy->nvectors;
>  }
>  
> +static AddressSpace *virtio_pci_get_dma_as(DeviceState *d)
> +{
> +VirtIOPCIProxy *proxy = VIRTIO_PCI(d);
> +PCIDevice 

Re: [Qemu-devel] [PATCH] hw/pci: disable pci-bridge's shpc by default

[Michael S. Tsirkin]

On Thu, Nov 03, 2016 at 01:05:44PM +0200, Marcel Apfelbaum wrote:
> On 11/03/2016 06:18 AM, Michael S. Tsirkin wrote:
> > On Wed, Nov 02, 2016 at 05:16:42PM +0200, Marcel Apfelbaum wrote:
> > > The shpc component is optional while  ACPI hotplug is used
> > > for hot-plugging PCI devices into a PCI-PCI bridge.
> > > Disabling the shpc by default will make slot 0 usable at boot time
> 
> Hi Michael
> 
> > 
> > at the cost of breaking all hotplug for all non-acpi users.
> > 
> 
> Do we have a non-acpi user that is able to use the shpc component as-is today?

power and some arm systems I guess?

> I remember we need to even tweak QEMU before it can be used, but I might be 
> wrong.
> 
> And we don't touch the current machines < 2.8 .
> 
> > > and not only for hot-plug, without loosing any functionality.
> > > Older machines will have shpc enabled for compatibility reasons.
> > > 
> > > Signed-off-by: Marcel Apfelbaum 
> > 
> > Is an extra slot such a big deal? You can always add more bridges ...
> > 
> 
> It is not only about the slot itself, but more about the usage model.
> The PCIe Upstream ports/DMI-PCI devices are also pci-bridges,
> but for them slot 0 is allowed.

The reason is that these devices are not themselves
hotpluggable. Isn't there a flag that allows adding
a non hotpluggable device? Allowing these would be one solution.

> And what about the hotplug? Slot 0 is not usable at boot, but then is
> usable again (for ACPI users) making people wondering:
>  https://bugzilla.redhat.com/show_bug.cgi?id=1175113

Let's just disallow that then for consistency?


> My point is - can shpc be used as-is today? Even so, I suspect there are much 
> (much)
> less users using SHPC than ACPI based hotplug. If this is the case, why 
> bother the
> majority of the users? And for the shpc users, they can keep the prev machines
> or change the command line, I think changes like this happens over the time.
> 
> Adding Markus for his opinion on command line changes.
> 
> Thanks,
> Marcel
> > > ---
> > >  hw/pci-bridge/pci_bridge_dev.c | 2 +-
> > >  include/hw/compat.h| 4 
> > >  2 files changed, 5 insertions(+), 1 deletion(-)
> > > 
> > > diff --git a/hw/pci-bridge/pci_bridge_dev.c 
> > > b/hw/pci-bridge/pci_bridge_dev.c
> > > index 5dbd933..647ad80 100644
> > > --- a/hw/pci-bridge/pci_bridge_dev.c
> > > +++ b/hw/pci-bridge/pci_bridge_dev.c
> > > @@ -163,7 +163,7 @@ static Property pci_bridge_dev_properties[] = {
> > >  DEFINE_PROP_ON_OFF_AUTO(PCI_BRIDGE_DEV_PROP_MSI, PCIBridgeDev, msi,
> > >  ON_OFF_AUTO_AUTO),
> > >  DEFINE_PROP_BIT(PCI_BRIDGE_DEV_PROP_SHPC, PCIBridgeDev, flags,
> > > -PCI_BRIDGE_DEV_F_SHPC_REQ, true),
> > > +PCI_BRIDGE_DEV_F_SHPC_REQ, false),
> > >  DEFINE_PROP_END_OF_LIST(),
> > >  };
> > > 
> > > diff --git a/include/hw/compat.h b/include/hw/compat.h
> > > index 0f06e11..388b7ec 100644
> > > --- a/include/hw/compat.h
> > > +++ b/include/hw/compat.h
> > > @@ -18,6 +18,10 @@
> > >  .driver   = "intel-iommu",\
> > >  .property = "x-buggy-eim",\
> > >  .value= "true",\
> > > +},{\
> > > +.driver   = "pci-bridge",\
> > > +.property = "shpc",\
> > > +.value= "on",\
> > >  },
> > > 
> > >  #define HW_COMPAT_2_6 \
> > > --
> > > 2.5.5

Re: [Qemu-devel] [PATCH v2 3/3] target-m68k: add cas/cas2 ops

[Richard Henderson]

On 11/03/2016 12:03 PM, Laurent Vivier wrote:

CC_OP_CMPW for cas2w.


It was working because I have used helper_be_ldsw_mmu() to load values,
is it better to use helper_be_lduw_mmu with CC_OP_CMPW?


IIRC, one needs the extra sign-extension here:

case CC_OP_CMPB:   \
case CC_OP_CMPW:   \
case CC_OP_CMPL:   \
src1 = n;  \
src2 = v;  \
res = EXTSIGN(src1 - src2, op - CC_OP_CMPB);   \

to get all of the flags correct, even though just Z would be correct without.


r~

Re: [Qemu-devel] [PATCH v4 2/5] qapi: auto generate enum value strings

[Markus Armbruster]

Lin Ma  writes:

> Automatically generate enum value strings that containing the acceptable 
> values.
> (Borrowed Daniel's code.)
>
> Signed-off-by: Lin Ma 
> ---
>  scripts/qapi-types.py | 2 ++
>  scripts/qapi.py   | 9 +
>  2 files changed, 11 insertions(+)
>
> diff --git a/scripts/qapi-types.py b/scripts/qapi-types.py
> index dabc42e..0446839 100644
> --- a/scripts/qapi-types.py
> +++ b/scripts/qapi-types.py
> @@ -202,9 +202,11 @@ class QAPISchemaGenTypeVisitor(QAPISchemaVisitor):
>  self._btin += gen_enum(name, values, prefix)
>  if do_builtins:
>  self.defn += gen_enum_lookup(name, values, prefix)
> +self._btin += gen_enum_value_str(name, values)
>  else:
>  self._fwdecl += gen_enum(name, values, prefix)
>  self.defn += gen_enum_lookup(name, values, prefix)
> +self._fwdecl += gen_enum_value_str(name, values)
>  
>  def visit_array_type(self, name, info, element_type):
>  if isinstance(element_type, QAPISchemaBuiltinType):
> diff --git a/scripts/qapi.py b/scripts/qapi.py
> index 21bc32f..d11c414 100644
> --- a/scripts/qapi.py
> +++ b/scripts/qapi.py
> @@ -1649,6 +1649,15 @@ const char *const %(c_name)s_lookup[] = {
>  return ret
>  
>  
> +def gen_enum_value_str(name, values):
> +return mcgen('''
> +
> +#define %(c_name)s_value_str "%(value_str)s"
> +''',
> +c_name=c_name(name),
> +value_str=", ".join(["'%s'" % c for c in values]))
> +
> +
>  def gen_enum(name, values, prefix=None):
>  # append automatically generated _MAX value
>  enum_values = values + ['_MAX']

This function is generating a macro definition, not a string.  We could
call it gen_enum_values_define().  But I'd simply fold it into
gen_enum().

Adds another 9KiB to qapi-types.h, which is included widely.  Instead of
defining these macros, we could also iterate over FOO_lookup[] at
run-time.  But let's first review how the macro is used.

Re: [Qemu-devel] [PATCH 0/2] qom+coccinelle: add and use object_new_with_class()

[Eduardo Habkost]

On Thu, Nov 03, 2016 at 05:54:19PM +0100, Markus Armbruster wrote:
> Radim Krčmář  writes:
> 
> > This series performs a simple replacement of
> > object_new(object_class_get_name(class)) by object_new_with_class(class)
> > in the spirit of existing object_new_with_type().
> 
> Who's going to take this one?  Still more review needed?

Not sure. I volunteer to queue QOM and qdev patches in my tree if
you and the others agree. But I would like to get any core QOM or
qdev patches at least Acked-by you, Paolo, or Andreas.

-- 
Eduardo

Re: [Qemu-devel] [PATCH v2] target-sh4: add atomic tas

[Richard Henderson]

On 11/03/2016 11:52 AM, Paolo Bonzini wrote:

UP kernel = no sane way to implement this in user-mode qemu?


Probably no straight-forward way, no.


Another possibility is to treat the load as a LL and the store as a SC
(implemented in turn with cmpxchg+branch if it fails).  cmpxchg spans
two basic blocks, so maybe one also needs to look at r0 and sp in
cpu_get_tb_cpu_state...


Yeah, that's a possibility.  With the store-conditional failure auto-branching 
back to the start of the sequence (r0+sp).



Anyhow this patch seems like a bugfix.


Absolutely.


r~

Re: [Qemu-devel] [PATCH] hw/pci: disable pci-bridge's shpc by default

[Eduardo Habkost]

On Thu, Nov 03, 2016 at 06:43:05PM +0200, Marcel Apfelbaum wrote:
> On 11/03/2016 05:24 PM, Laine Stump wrote:
> > On 11/03/2016 07:08 AM, Marcel Apfelbaum wrote:
> > > On 11/02/2016 06:01 PM, Laine Stump wrote:
> > > > On 11/02/2016 11:16 AM, Marcel Apfelbaum wrote:
> > > > > The shpc component is optional while  ACPI hotplug is used
> > > > > for hot-plugging PCI devices into a PCI-PCI bridge.
> > > > > Disabling the shpc by default will make slot 0 usable at boot time
> > > > > and not only for hot-plug, without loosing any functionality.
> > > > > Older machines will have shpc enabled for compatibility reasons.
> > > > 
> > > > From libvirt's POV, changing qemu's default for shpc in qemu only
> > > > serves to confuse; since we have no way to discover what is the
> > > > default setting (especially problematic since it is different for
> > > > different machinetype versions), we now either need to keep a table of
> > > > what the setting is for various machinetypes, or we need to just
> > > > always set it whether it's on or off.
> > > > 
> > > > So for us, the simplest thing is for the default to remain the same
> > > > (since for so long we haven't set this option as we didn't even know
> > > > what it did, or indeed even that it existed), and for libvirt
> > > > to learn about the option, make its default in the config files "on",
> > > > but begin setting it to "off" in all newly defined machines.
> > > > 
> > > 
> > > Hi Laine,
> > > 
> > > Please see my reply to Michael regarding the "why", anyway, can't
> > > libvirt deal with it?
> > > Start use the shpc parameter no matter what QEMU does by default while
> > > keeping it 'on' for machines < 2.8.
> > > (this is only a suggestion, of course...)
> > 
> > 
> > We greatly dislike coding in behavior changes to libvirt
> > based on machinetype/version or qemu version since a version
> > number is a very broad and inaccurate sword. The best
> > behavior changes are those that can be discovered by querying
> > something specific to that behavior, which can't be done in
> > this case, as there is no way to query *anything* specific to
> > a machinetype without instantiating a virtual machine of that
> > machinetype (if it's even queryable then, which is anyway
> > irrelevant to libvirt, since our queries to qemu are done
> > with -machine none).
> > 
> 
> +Eduardo
> 
> Hi Eduardo,
> Can your work can help on this specific case?

In this cases, the needed mechanisms already exist. We just need
to encode that info in the MachineInfo struct, so that it gets
returned by the "query-machines" QMP command. (But making QEMU
maintainers agree on how to encode stuff in QMP is always a
challenge.)

> 
> 
> > libvirt can of course deal with such a change in default behavior by qemu, 
> > but the way it will deal with it is by removing all assumptions about the 
> > default of shpc from the code, and replacing those
> > assumptions with explicit setting of the option in the xml and on the qemu 
> > command line all the time.
> > 
> > In the end, libvirt wouldn't gain anything from this change in qemu's 
> > default behavior - it would be more work than just adding a setting for 
> > shpc to libvirt and having *libvirt* change its default
> > setting (which has the same ultimate results). Of course that's a 
> > relatively selfish (libvirt-centric) view, and I suppose direct users of 
> > the qemu commandline might get some benefit from changing the
> > qemu default, but anyone concerned enough about the exact commandline 
> > contents to be running qemu directly would probably also not have a problem 
> > adding an option to the commandline if they really
> > wanted a 1/32 increase in the number of available slots.
> > 
> 
> As I explained to Michael, this is not only about the extra slot, but
> more about the usage model.
> I do understand the libvirt point of view, on the other hand why
> should we use a default QEMU value that the majority of users don't need?

This is a common problem: sometimes we want to make the default
behavior saner on new machine-types, but changing the default
behavior often doesn't help libvirt (and makes life more
difficult for everybody).

I hope this will become easier over time, once we start making
machine-type info easily discoverable by libvirt.

-- 
Eduardo

[Qemu-devel] [PATCH v5 4/5] nvdimm acpi: introduce _FIT method

[Xiao Guangrong]

_FIT is required for hotplug support, guest will inquire the
updated device info from it if a hotplug event is received

As FIT buffer is not completely mapped into guest address space,
Read_FIT method is introduced to read NFIT structures blob from
QEMU, The buffer is concatenated before _FIT return

Refer to docs/specs/acpi-nvdimm.txt for detailed design

Signed-off-by: Xiao Guangrong 
---
 docs/specs/acpi_nvdimm.txt |  61 --
 hw/acpi/nvdimm.c   | 198 -
 2 files changed, 252 insertions(+), 7 deletions(-)

diff --git a/docs/specs/acpi_nvdimm.txt b/docs/specs/acpi_nvdimm.txt
index 0fdd251..63cb63f 100644
--- a/docs/specs/acpi_nvdimm.txt
+++ b/docs/specs/acpi_nvdimm.txt
@@ -65,8 +65,8 @@ _FIT(Firmware Interface Table)
The detailed definition of the structure can be found at ACPI 6.0: 5.2.25
NVDIMM Firmware Interface Table (NFIT).
 
-QEMU NVDIMM Implemention
-
+QEMU NVDIMM Implementation
+==
 QEMU uses 4 bytes IO Port starting from 0x0a18 and a RAM-based memory page
 for NVDIMM ACPI.
 
@@ -82,6 +82,16 @@ Memory:
ACPI writes _DSM Input Data (based on the offset in the page):
[0x0 - 0x3]: 4 bytes, NVDIMM Device Handle, 0 is reserved for NVDIMM
 Root device.
+
+The handle is completely QEMU internal thing, the values in
+range [1, 0x] indicate nvdimm device. Other values are
+reserved for other purposes.
+
+Reserved handles:
+0 is reserved for nvdimm root device named NVDR.
+0x1 is reserved for QEMU internal DSM function called on
+the root device.
+
[0x4 - 0x7]: 4 bytes, Revision ID, that is the Arg1 of _DSM method.
[0x8 - 0xB]: 4 bytes. Function Index, that is the Arg2 of _DSM method.
[0xC - 0xFFF]: 4084 bytes, the Arg3 of _DSM method.
@@ -127,6 +137,47 @@ _DSM process diagram:
  | result from the page |  |  |
  +--+  +--+
 
- _FIT implementation
- ---
- TODO (will fill it when nvdimm hotplug is introduced)
+QEMU internal use only _DSM function
+
+1) Read FIT
+   _FIT method uses _DSM method to fetch NFIT structures blob from QEMU
+   in 1 page sized increments which are then concatenated and returned
+   as _FIT method result.
+
+   Input parameters:
+   Arg0 – UUID {set to 648B9CF2-CDA1-4312-8AD9-49C4AF32BD62}
+   Arg1 – Revision ID (set to 1)
+   Arg2 - Function Index, 0x1
+   Arg3 - A package containing a buffer whose layout is as follows:
+
+   +--+++---+
+   |  Field   | Length | Offset | Description   |
+   +--+++---+
+   | offset   |   4|   0| offset in QEMU's NFIT structures blob to  |
+   |  ||| read from |
+   +--+++---+
+
+   Output layout in the dsm memory page:
+   +--+++---+
+   |  Field   | Length | Offset | Description   |
+   +--+++---+
+   | length   |   4|   0| length of entire returned data|
+   |  ||| (including the header)|
+   +--+-+---+
+   |  ||| return status codes   |
+   |  ||| 0x0 - success |
+   |  ||| 0x100 - error caused by NFIT update while |
+   | status   |   4|   4| read by _FIT wasn't completed, other  |
+   |  ||| codes follow Chapter 3 in DSM Spec Rev1   |
+   +--+-+---+
+   | fit data | Varies |   8| contains FIT data, this field is present  |
+   |  ||| if status field is 0; |
+   +--+++---+
+
+   The FIT offset is maintained by the OSPM itself, current offset plus
+   the size of the fit data returned by the function is the next offset
+   OSPM should read. When all FIT data has been read out, zero length is
+   returned.
+
+   If it returns status code 0x100, OSPM should restart to read FIT (read
+   from offset 0 again).
diff --git a/hw/acpi/nvdimm.c b/hw/acpi/nvdimm.c
index d9d1ef7..f82ae4a 100644
--- a/hw/acpi/nvdimm.c
+++ b/hw/acpi/nvdimm.c
@@ -478,6 +478,22 @@ typedef struct NvdimmFuncSetLabelDataIn 
NvdimmFuncSetLabelDataIn;
 

[Qemu-devel] [PATCH v5 1/5] nvdimm acpi: prebuild nvdimm devices for available slots

[Xiao Guangrong]

For each NVDIMM present or intended to be supported by platform,
platform firmware also exposes an ACPI Namespace Device under
the root device

So it builds nvdimm devices for all slots to support vNVDIMM hotplug

Reviewed-by: Stefan Hajnoczi 
Signed-off-by: Xiao Guangrong 
---
 hw/acpi/nvdimm.c| 33 -
 hw/i386/acpi-build.c|  2 +-
 include/hw/mem/nvdimm.h |  3 ++-
 3 files changed, 23 insertions(+), 15 deletions(-)

diff --git a/hw/acpi/nvdimm.c b/hw/acpi/nvdimm.c
index bb896c9..58bc5c6 100644
--- a/hw/acpi/nvdimm.c
+++ b/hw/acpi/nvdimm.c
@@ -961,12 +961,11 @@ static void nvdimm_build_device_dsm(Aml *dev, uint32_t 
handle)
 aml_append(dev, method);
 }
 
-static void nvdimm_build_nvdimm_devices(GSList *device_list, Aml *root_dev)
+static void nvdimm_build_nvdimm_devices(Aml *root_dev, uint32_t ram_slots)
 {
-for (; device_list; device_list = device_list->next) {
-DeviceState *dev = device_list->data;
-int slot = object_property_get_int(OBJECT(dev), PC_DIMM_SLOT_PROP,
-   NULL);
+uint32_t slot;
+
+for (slot = 0; slot < ram_slots; slot++) {
 uint32_t handle = nvdimm_slot_to_handle(slot);
 Aml *nvdimm_dev;
 
@@ -987,9 +986,9 @@ static void nvdimm_build_nvdimm_devices(GSList 
*device_list, Aml *root_dev)
 }
 }
 
-static void nvdimm_build_ssdt(GSList *device_list, GArray *table_offsets,
-  GArray *table_data, BIOSLinker *linker,
-  GArray *dsm_dma_arrea)
+static void nvdimm_build_ssdt(GArray *table_offsets, GArray *table_data,
+  BIOSLinker *linker, GArray *dsm_dma_arrea,
+  uint32_t ram_slots)
 {
 Aml *ssdt, *sb_scope, *dev;
 int mem_addr_offset, nvdimm_ssdt;
@@ -1021,7 +1020,7 @@ static void nvdimm_build_ssdt(GSList *device_list, GArray 
*table_offsets,
 /* 0 is reserved for root device. */
 nvdimm_build_device_dsm(dev, 0);
 
-nvdimm_build_nvdimm_devices(device_list, dev);
+nvdimm_build_nvdimm_devices(dev, ram_slots);
 
 aml_append(sb_scope, dev);
 aml_append(ssdt, sb_scope);
@@ -1046,17 +1045,25 @@ static void nvdimm_build_ssdt(GSList *device_list, 
GArray *table_offsets,
 }
 
 void nvdimm_build_acpi(GArray *table_offsets, GArray *table_data,
-   BIOSLinker *linker, GArray *dsm_dma_arrea)
+   BIOSLinker *linker, GArray *dsm_dma_arrea,
+   uint32_t ram_slots)
 {
 GSList *device_list;
 
-/* no NVDIMM device is plugged. */
+/* no nvdimm device can be plugged. */
+if (!ram_slots) {
+return;
+}
+
+nvdimm_build_ssdt(table_offsets, table_data, linker, dsm_dma_arrea,
+  ram_slots);
+
 device_list = nvdimm_get_plugged_device_list();
+/* no NVDIMM device is plugged. */
 if (!device_list) {
 return;
 }
+
 nvdimm_build_nfit(device_list, table_offsets, table_data, linker);
-nvdimm_build_ssdt(device_list, table_offsets, table_data, linker,
-  dsm_dma_arrea);
 g_slist_free(device_list);
 }
diff --git a/hw/i386/acpi-build.c b/hw/i386/acpi-build.c
index e999654..6ae4769 100644
--- a/hw/i386/acpi-build.c
+++ b/hw/i386/acpi-build.c
@@ -2767,7 +2767,7 @@ void acpi_build(AcpiBuildTables *tables, MachineState 
*machine)
 }
 if (pcms->acpi_nvdimm_state.is_enabled) {
 nvdimm_build_acpi(table_offsets, tables_blob, tables->linker,
-  pcms->acpi_nvdimm_state.dsm_mem);
+  pcms->acpi_nvdimm_state.dsm_mem, machine->ram_slots);
 }
 
 /* Add tables supplied by user (if any) */
diff --git a/include/hw/mem/nvdimm.h b/include/hw/mem/nvdimm.h
index 1cfe9e0..63a2b20 100644
--- a/include/hw/mem/nvdimm.h
+++ b/include/hw/mem/nvdimm.h
@@ -112,5 +112,6 @@ typedef struct AcpiNVDIMMState AcpiNVDIMMState;
 void nvdimm_init_acpi_state(AcpiNVDIMMState *state, MemoryRegion *io,
 FWCfgState *fw_cfg, Object *owner);
 void nvdimm_build_acpi(GArray *table_offsets, GArray *table_data,
-   BIOSLinker *linker, GArray *dsm_dma_arrea);
+   BIOSLinker *linker, GArray *dsm_dma_arrea,
+   uint32_t ram_slots);
 #endif
-- 
1.8.3.1

[Qemu-devel] [PATCH v5 5/5] pc: memhp: enable nvdimm device hotplug

[Xiao Guangrong]

_GPE.E04 is dedicated for nvdimm device hotplug

Signed-off-by: Xiao Guangrong 
---
 default-configs/mips-softmmu-common.mak | 1 +
 docs/specs/acpi_nvdimm.txt  | 5 +
 hw/acpi/ich9.c  | 8 ++--
 hw/acpi/nvdimm.c| 7 +++
 hw/acpi/piix4.c | 7 ++-
 hw/i386/acpi-build.c| 7 +++
 hw/i386/pc.c| 6 ++
 hw/mem/nvdimm.c | 4 
 include/hw/acpi/acpi_dev_interface.h| 1 +
 include/hw/mem/nvdimm.h | 1 +
 10 files changed, 40 insertions(+), 7 deletions(-)

diff --git a/default-configs/mips-softmmu-common.mak 
b/default-configs/mips-softmmu-common.mak
index 0394514..f0676f5 100644
--- a/default-configs/mips-softmmu-common.mak
+++ b/default-configs/mips-softmmu-common.mak
@@ -17,6 +17,7 @@ CONFIG_FDC=y
 CONFIG_ACPI=y
 CONFIG_ACPI_X86=y
 CONFIG_ACPI_MEMORY_HOTPLUG=y
+CONFIG_ACPI_NVDIMM=y
 CONFIG_ACPI_CPU_HOTPLUG=y
 CONFIG_APM=y
 CONFIG_I8257=y
diff --git a/docs/specs/acpi_nvdimm.txt b/docs/specs/acpi_nvdimm.txt
index 63cb63f..9ab6d9a 100644
--- a/docs/specs/acpi_nvdimm.txt
+++ b/docs/specs/acpi_nvdimm.txt
@@ -137,6 +137,11 @@ _DSM process diagram:
  | result from the page |  |  |
  +--+  +--+
 
+NVDIMM hotplug
+--
+ACPI BIOS GPE.4 handler is dedicated for notifying OS about nvdimm device
+hot-add event.
+
 QEMU internal use only _DSM function
 
 1) Read FIT
diff --git a/hw/acpi/ich9.c b/hw/acpi/ich9.c
index e5a3c18..830c475 100644
--- a/hw/acpi/ich9.c
+++ b/hw/acpi/ich9.c
@@ -490,8 +490,12 @@ void ich9_pm_device_plug_cb(HotplugHandler *hotplug_dev, 
DeviceState *dev,
 
 if (lpc->pm.acpi_memory_hotplug.is_enabled &&
 object_dynamic_cast(OBJECT(dev), TYPE_PC_DIMM)) {
-acpi_memory_plug_cb(hotplug_dev, >pm.acpi_memory_hotplug,
-dev, errp);
+if (object_dynamic_cast(OBJECT(dev), TYPE_NVDIMM)) {
+nvdimm_acpi_plug_cb(hotplug_dev, dev);
+} else {
+acpi_memory_plug_cb(hotplug_dev, >pm.acpi_memory_hotplug,
+dev, errp);
+}
 } else if (object_dynamic_cast(OBJECT(dev), TYPE_CPU)) {
 if (lpc->pm.cpu_hotplug_legacy) {
 legacy_acpi_cpu_plug_cb(hotplug_dev, >pm.gpe_cpu, dev, errp);
diff --git a/hw/acpi/nvdimm.c b/hw/acpi/nvdimm.c
index f82ae4a..3026e3e 100644
--- a/hw/acpi/nvdimm.c
+++ b/hw/acpi/nvdimm.c
@@ -868,6 +868,13 @@ static const MemoryRegionOps nvdimm_dsm_ops = {
 },
 };
 
+void nvdimm_acpi_plug_cb(HotplugHandler *hotplug_dev, DeviceState *dev)
+{
+if (dev->hotplugged) {
+acpi_send_event(DEVICE(hotplug_dev), ACPI_NVDIMM_HOTPLUG_STATUS);
+}
+}
+
 void nvdimm_init_acpi_state(AcpiNVDIMMState *state, MemoryRegion *io,
 FWCfgState *fw_cfg, Object *owner)
 {
diff --git a/hw/acpi/piix4.c b/hw/acpi/piix4.c
index 2adc246..17d36bd 100644
--- a/hw/acpi/piix4.c
+++ b/hw/acpi/piix4.c
@@ -378,7 +378,12 @@ static void piix4_device_plug_cb(HotplugHandler 
*hotplug_dev,
 
 if (s->acpi_memory_hotplug.is_enabled &&
 object_dynamic_cast(OBJECT(dev), TYPE_PC_DIMM)) {
-acpi_memory_plug_cb(hotplug_dev, >acpi_memory_hotplug, dev, errp);
+if (object_dynamic_cast(OBJECT(dev), TYPE_NVDIMM)) {
+nvdimm_acpi_plug_cb(hotplug_dev, dev);
+} else {
+acpi_memory_plug_cb(hotplug_dev, >acpi_memory_hotplug,
+dev, errp);
+}
 } else if (object_dynamic_cast(OBJECT(dev), TYPE_PCI_DEVICE)) {
 acpi_pcihp_device_plug_cb(hotplug_dev, >acpi_pci_hotplug, dev, 
errp);
 } else if (object_dynamic_cast(OBJECT(dev), TYPE_CPU)) {
diff --git a/hw/i386/acpi-build.c b/hw/i386/acpi-build.c
index bc49958..32270c3 100644
--- a/hw/i386/acpi-build.c
+++ b/hw/i386/acpi-build.c
@@ -2039,6 +2039,13 @@ build_dsdt(GArray *table_data, BIOSLinker *linker,
 method = aml_method("_E03", 0, AML_NOTSERIALIZED);
 aml_append(method, aml_call0(MEMORY_HOTPLUG_HANDLER_PATH));
 aml_append(scope, method);
+
+if (pcms->acpi_nvdimm_state.is_enabled) {
+method = aml_method("_E04", 0, AML_NOTSERIALIZED);
+aml_append(method, aml_notify(aml_name("\\_SB.NVDR"),
+  aml_int(0x80)));
+aml_append(scope, method);
+}
 }
 aml_append(dsdt, scope);
 
diff --git a/hw/i386/pc.c b/hw/i386/pc.c
index a4e1509..bc36e19 100644
--- a/hw/i386/pc.c
+++ b/hw/i386/pc.c
@@ -1723,6 +1723,12 @@ static void pc_dimm_unplug_request(HotplugHandler 
*hotplug_dev,
 goto out;
 }
 
+if (object_dynamic_cast(OBJECT(dev), TYPE_NVDIMM)) {
+error_setg(_err,
+   "nvdimm device hot unplug is not supported yet.");
+goto out;
+}
+
 hhc = 

[Qemu-devel] [PATCH v5 2/5] nvdimm acpi: introduce fit buffer

[Xiao Guangrong]

The buffer is used to save the FIT info for all the presented nvdimm
devices which is updated after the nvdimm device is plugged or
unplugged. In the later patch, it will be used to construct NVDIMM
ACPI _FIT method which reflects the presented nvdimm devices after
nvdimm hotplug

As FIT buffer can not completely mapped into guest address space,
OSPM will exit to QEMU multiple times, however, there is the race
condition - FIT may be changed during these multiple exits, so that
we mark @dirty whenever the buffer is updated.

@dirty is cleared for the first time OSPM gets fit buffer, if
dirty is detected in the later access, OSPM will restart the
access

Signed-off-by: Xiao Guangrong 
---
 hw/acpi/nvdimm.c| 59 +++--
 hw/i386/acpi-build.c|  2 +-
 hw/i386/pc.c|  4 
 include/hw/mem/nvdimm.h | 21 +-
 4 files changed, 62 insertions(+), 24 deletions(-)

diff --git a/hw/acpi/nvdimm.c b/hw/acpi/nvdimm.c
index 58bc5c6..73db3a7 100644
--- a/hw/acpi/nvdimm.c
+++ b/hw/acpi/nvdimm.c
@@ -33,35 +33,30 @@
 #include "hw/nvram/fw_cfg.h"
 #include "hw/mem/nvdimm.h"
 
-static int nvdimm_plugged_device_list(Object *obj, void *opaque)
+static int nvdimm_device_list(Object *obj, void *opaque)
 {
 GSList **list = opaque;
 
 if (object_dynamic_cast(obj, TYPE_NVDIMM)) {
-DeviceState *dev = DEVICE(obj);
-
-if (dev->realized) { /* only realized NVDIMMs matter */
-*list = g_slist_append(*list, DEVICE(obj));
-}
+*list = g_slist_append(*list, DEVICE(obj));
 }
 
-object_child_foreach(obj, nvdimm_plugged_device_list, opaque);
+object_child_foreach(obj, nvdimm_device_list, opaque);
 return 0;
 }
 
 /*
- * inquire plugged NVDIMM devices and link them into the list which is
+ * inquire NVDIMM devices and link them into the list which is
  * returned to the caller.
  *
  * Note: it is the caller's responsibility to free the list to avoid
  * memory leak.
  */
-static GSList *nvdimm_get_plugged_device_list(void)
+static GSList *nvdimm_get_device_list(void)
 {
 GSList *list = NULL;
 
-object_child_foreach(qdev_get_machine(), nvdimm_plugged_device_list,
- );
+object_child_foreach(qdev_get_machine(), nvdimm_device_list, );
 return list;
 }
 
@@ -219,7 +214,7 @@ static uint32_t nvdimm_slot_to_dcr_index(int slot)
 static NVDIMMDevice *nvdimm_get_device_by_handle(uint32_t handle)
 {
 NVDIMMDevice *nvdimm = NULL;
-GSList *list, *device_list = nvdimm_get_plugged_device_list();
+GSList *list, *device_list = nvdimm_get_device_list();
 
 for (list = device_list; list; list = list->next) {
 NVDIMMDevice *nvd = list->data;
@@ -348,8 +343,9 @@ static void nvdimm_build_structure_dcr(GArray *structures, 
DeviceState *dev)
  (DSM) in DSM Spec Rev1.*/);
 }
 
-static GArray *nvdimm_build_device_structure(GSList *device_list)
+static GArray *nvdimm_build_device_structure(void)
 {
+GSList *device_list = nvdimm_get_device_list();
 GArray *structures = g_array_new(false, true /* clear */, 1);
 
 for (; device_list; device_list = device_list->next) {
@@ -367,14 +363,32 @@ static GArray *nvdimm_build_device_structure(GSList 
*device_list)
 /* build NVDIMM Control Region Structure. */
 nvdimm_build_structure_dcr(structures, dev);
 }
+g_slist_free(device_list);
 
 return structures;
 }
 
-static void nvdimm_build_nfit(GSList *device_list, GArray *table_offsets,
+static void nvdimm_init_fit_buffer(NvdimmFitBuffer *fit_buf)
+{
+fit_buf->fit = g_array_new(false, true /* clear */, 1);
+}
+
+static void nvdimm_build_fit_buffer(NvdimmFitBuffer *fit_buf)
+{
+g_array_free(fit_buf->fit, true);
+fit_buf->fit = nvdimm_build_device_structure();
+fit_buf->dirty = true;
+}
+
+void nvdimm_plug(AcpiNVDIMMState *state)
+{
+nvdimm_build_fit_buffer(>fit_buf);
+}
+
+static void nvdimm_build_nfit(AcpiNVDIMMState *state, GArray *table_offsets,
   GArray *table_data, BIOSLinker *linker)
 {
-GArray *structures = nvdimm_build_device_structure(device_list);
+NvdimmFitBuffer *fit_buf = >fit_buf;
 unsigned int header;
 
 acpi_add_table(table_offsets, table_data);
@@ -383,12 +397,11 @@ static void nvdimm_build_nfit(GSList *device_list, GArray 
*table_offsets,
 header = table_data->len;
 acpi_data_push(table_data, sizeof(NvdimmNfitHeader));
 /* NVDIMM device structures. */
-g_array_append_vals(table_data, structures->data, structures->len);
+g_array_append_vals(table_data, fit_buf->fit->data, fit_buf->fit->len);
 
 build_header(linker, table_data,
  (void *)(table_data->data + header), "NFIT",
- sizeof(NvdimmNfitHeader) + structures->len, 1, NULL, NULL);
-g_array_free(structures, true);
+ sizeof(NvdimmNfitHeader) + fit_buf->fit->len, 1, 

[Qemu-devel] [PATCH v5 3/5] nvdimm acpi: define DSM return codes

[Xiao Guangrong]

and use these codes to refine the code

Signed-off-by: Xiao Guangrong 
---
 hw/acpi/nvdimm.c | 30 ++
 1 file changed, 18 insertions(+), 12 deletions(-)

diff --git a/hw/acpi/nvdimm.c b/hw/acpi/nvdimm.c
index 73db3a7..d9d1ef7 100644
--- a/hw/acpi/nvdimm.c
+++ b/hw/acpi/nvdimm.c
@@ -498,6 +498,11 @@ nvdimm_dsm_no_payload(uint32_t func_ret_status, hwaddr 
dsm_mem_addr)
 cpu_physical_memory_write(dsm_mem_addr, , sizeof(out));
 }
 
+#define NVDIMM_DSM_RET_STATUS_SUCCESS0 /* Success */
+#define NVDIMM_DSM_RET_STATUS_UNSUPPORT  1 /* Not Supported */
+#define NVDIMM_DSM_RET_STATUS_NOMEMDEV   2 /* Non-Existing Memory Device */
+#define NVDIMM_DSM_RET_STATUS_INVALID3 /* Invalid Input Parameters */
+
 static void nvdimm_dsm_root(NvdimmDsmIn *in, hwaddr dsm_mem_addr)
 {
 /*
@@ -511,7 +516,7 @@ static void nvdimm_dsm_root(NvdimmDsmIn *in, hwaddr 
dsm_mem_addr)
 }
 
 /* No function except function 0 is supported yet. */
-nvdimm_dsm_no_payload(1 /* Not Supported */, dsm_mem_addr);
+nvdimm_dsm_no_payload(NVDIMM_DSM_RET_STATUS_UNSUPPORT, dsm_mem_addr);
 }
 
 /*
@@ -557,7 +562,7 @@ static void nvdimm_dsm_label_size(NVDIMMDevice *nvdimm, 
hwaddr dsm_mem_addr)
 
 nvdimm_debug("label_size %#x, max_xfer %#x.\n", label_size, mxfer);
 
-label_size_out.func_ret_status = cpu_to_le32(0 /* Success */);
+label_size_out.func_ret_status = 
cpu_to_le32(NVDIMM_DSM_RET_STATUS_SUCCESS);
 label_size_out.label_size = cpu_to_le32(label_size);
 label_size_out.max_xfer = cpu_to_le32(mxfer);
 
@@ -568,7 +573,7 @@ static void nvdimm_dsm_label_size(NVDIMMDevice *nvdimm, 
hwaddr dsm_mem_addr)
 static uint32_t nvdimm_rw_label_data_check(NVDIMMDevice *nvdimm,
uint32_t offset, uint32_t length)
 {
-uint32_t ret = 3 /* Invalid Input Parameters */;
+uint32_t ret = NVDIMM_DSM_RET_STATUS_INVALID;
 
 if (offset + length < offset) {
 nvdimm_debug("offset %#x + length %#x is overflow.\n", offset,
@@ -588,7 +593,7 @@ static uint32_t nvdimm_rw_label_data_check(NVDIMMDevice 
*nvdimm,
 return ret;
 }
 
-return 0 /* Success */;
+return NVDIMM_DSM_RET_STATUS_SUCCESS;
 }
 
 /*
@@ -612,7 +617,7 @@ static void nvdimm_dsm_get_label_data(NVDIMMDevice *nvdimm, 
NvdimmDsmIn *in,
 
 status = nvdimm_rw_label_data_check(nvdimm, get_label_data->offset,
 get_label_data->length);
-if (status != 0 /* Success */) {
+if (status != NVDIMM_DSM_RET_STATUS_SUCCESS) {
 nvdimm_dsm_no_payload(status, dsm_mem_addr);
 return;
 }
@@ -622,7 +627,8 @@ static void nvdimm_dsm_get_label_data(NVDIMMDevice *nvdimm, 
NvdimmDsmIn *in,
 get_label_data_out = g_malloc(size);
 
 get_label_data_out->len = cpu_to_le32(size);
-get_label_data_out->func_ret_status = cpu_to_le32(0 /* Success */);
+get_label_data_out->func_ret_status =
+  cpu_to_le32(NVDIMM_DSM_RET_STATUS_SUCCESS);
 nvc->read_label_data(nvdimm, get_label_data_out->out_buf,
  get_label_data->length, get_label_data->offset);
 
@@ -650,7 +656,7 @@ static void nvdimm_dsm_set_label_data(NVDIMMDevice *nvdimm, 
NvdimmDsmIn *in,
 
 status = nvdimm_rw_label_data_check(nvdimm, set_label_data->offset,
 set_label_data->length);
-if (status != 0 /* Success */) {
+if (status != NVDIMM_DSM_RET_STATUS_SUCCESS) {
 nvdimm_dsm_no_payload(status, dsm_mem_addr);
 return;
 }
@@ -660,7 +666,7 @@ static void nvdimm_dsm_set_label_data(NVDIMMDevice *nvdimm, 
NvdimmDsmIn *in,
 
 nvc->write_label_data(nvdimm, set_label_data->in_buf,
   set_label_data->length, set_label_data->offset);
-nvdimm_dsm_no_payload(0 /* Success */, dsm_mem_addr);
+nvdimm_dsm_no_payload(NVDIMM_DSM_RET_STATUS_SUCCESS, dsm_mem_addr);
 }
 
 static void nvdimm_dsm_device(NvdimmDsmIn *in, hwaddr dsm_mem_addr)
@@ -684,7 +690,7 @@ static void nvdimm_dsm_device(NvdimmDsmIn *in, hwaddr 
dsm_mem_addr)
 }
 
 if (!nvdimm) {
-nvdimm_dsm_no_payload(2 /* Non-Existing Memory Device */,
+nvdimm_dsm_no_payload(NVDIMM_DSM_RET_STATUS_NOMEMDEV,
   dsm_mem_addr);
 return;
 }
@@ -711,7 +717,7 @@ static void nvdimm_dsm_device(NvdimmDsmIn *in, hwaddr 
dsm_mem_addr)
 break;
 }
 
-nvdimm_dsm_no_payload(1 /* Not Supported */, dsm_mem_addr);
+nvdimm_dsm_no_payload(NVDIMM_DSM_RET_STATUS_UNSUPPORT, dsm_mem_addr);
 }
 
 static uint64_t
@@ -747,7 +753,7 @@ nvdimm_dsm_write(void *opaque, hwaddr addr, uint64_t val, 
unsigned size)
 if (in->revision != 0x1 /* Currently we only support DSM Spec Rev1. */) {
 nvdimm_debug("Revision %#x is not supported, expect %#x.\n",
  in->revision, 0x1);
-nvdimm_dsm_no_payload(1 /* Not Supported */, dsm_mem_addr);
+

[Qemu-devel] [PATCH v5 0/5] nvdimm: hotplug support

[Xiao Guangrong]

Hi Michael,

This patchset can replace the patches from [PULL 36/47] to [PULL 39/47]
in your pull request:
[PULL 36/47] nvdimm acpi: prebuild nvdimm devices for available slots
[PULL 37/47] nvdimm acpi: introduce fit buffer
[PULL 38/47] nvdimm acpi: introduce _FIT
[PULL 39/47] pc: memhp: enable nvdimm device hotplug

Thanks for your patience also thank Igor and Stefan for their review.

Chanelog in v5:
   1) make definition of dsm return values be a separate patch
   2) drop stopping nvdimm hot remove in pc_dimm_unplug()
   3) drop length field in the output of Read_Fit
   4) doc fixes & improvement
   5) better naming some functions
   6) code cleanup   
   
Changelog in v4:
   1) drop fit lock and post_hotplug_cb
   2) move nvdimm hotplug code to hw/acpi/nvdimm.c
   3) introduce length field to indicate the fit size
   4) nvdimm acpi cleanup
   5) doc typo fixes

Changelog in v3:
   1) use a dedicated interrupt for nvdimm device hotplug
   2) stop nvdimm device hot unplug
   3) reserve UUID and handle for QEMU internally used QEMU
   5) redesign fit buffer to avoid OSPM reading incomplete fit info
   6) bug fixes and cleanups

Changelog in v2:
   Fixed signed integer overflow pointed out by Stefan Hajnoczi

This patchset enables nvdimm hotplug support, it is used as pc-dimm hotplug,
for example, a new nvdimm device can be plugged as follows:
object_add memory-backend-file,id=mem3,size=10G,mem-path=/home/eric/nvdimm3
device_add nvdimm,id=nvdimm3,memdev=mem3

Xiao Guangrong (5):
  nvdimm acpi: prebuild nvdimm devices for available slots
  nvdimm acpi: introduce fit buffer
  nvdimm acpi: define DSM return codes
  nvdimm acpi: introduce _FIT method
  pc: memhp: enable nvdimm device hotplug

 default-configs/mips-softmmu-common.mak |   1 +
 docs/specs/acpi_nvdimm.txt  |  66 ++-
 hw/acpi/ich9.c  |   8 +-
 hw/acpi/nvdimm.c| 321 +++-
 hw/acpi/piix4.c |   7 +-
 hw/i386/acpi-build.c|   9 +-
 hw/i386/pc.c|  10 +
 hw/mem/nvdimm.c |   4 -
 include/hw/acpi/acpi_dev_interface.h|   1 +
 include/hw/mem/nvdimm.h |  23 ++-
 10 files changed, 390 insertions(+), 60 deletions(-)

-- 
1.8.3.1

Re: [Qemu-devel] [QEMU PATCH v10 3/3] tests/migration: Add test for QTAILQ migration

[Halil Pasic]

On 11/03/2016 07:40 PM, Jianjun Duan wrote:
> 
> 
> On 11/03/2016 10:17 AM, Halil Pasic wrote:
>>
>>
>> On 11/03/2016 05:47 PM, Jianjun Duan wrote:
>>>
>>> On 11/03/2016 05:22 AM, Halil Pasic wrote:
>
>
> On 11/02/2016 11:47 AM, Juan Quintela wrote:
>>> Jianjun Duan  wrote:
> Add a test for QTAILQ migration to tests/test-vmstate.c.
>
> Signed-off-by: Jianjun Duan 
>>>
>>> Reviewed-by: Juan Quintela 
>>>
>
> Empty QTAILQ seems to be broken. Have written a small
> test to prove my point. It May even make sense to have such
> a test in the test-suite (some prettyfication might be
> necessary though).
>
>>> It is working as intended.
>>>
>>
>> My train of thought was that the object holding the queue might
>> be dynamically allocated by the migration code or otherwise
>> uninitialized. I was unaware these scenarios are prohibited.
>>
>>
> This is a valid point. To get this covered vmstate_load_state needs to
> be revised so that at any moment of recursion we know if the field is in
> a dynamic created structure. If yes the structures which need
> initialization such as QTAILQ can be initialized.
> 

Or you just zero out the head in VMStateInfo.get right away and to not care
what was there. Of course this is only if loading to non-empty
lists is invalid. This is why I cared describing why I think
it is (invalid).

> I would leave this until the need is there. In current device migration
> code I imagine such scenarios would be rare if they should appear at
> all. Because all the devices (even the hotplugged ones) are already
> initialized on target. So a QTAILQ in such context should already be
> initialized. Otherwise it should be fixed.
> 

I agree that this type of a solution is an overkill for something
nobody needs at the moment.

>>> The current design is to append the qtailq from source to the
>>> corresponding one on target. 
>>
>> I do not see this documented. I'm used to vmstate_load overwriting
>> values and following pointers, so IMHO it is not obvious that
>> qtailq load does append.
>>
> 
> I will document this.
> 

I'm fine with this option too but I think I would slightly prefer
the solution described above. Maybe some of the more experienced
guys (think Paolo, Juan, Dave) will come up with some guidance.

>>> It works well for the task in hard
>>> such as migrating ccs_list and pending_events for DRC objects.
>>>
>>
>> Because target head is always properly initialized to empty queue?
>>
> They may not be empty. But they should be initialized.
>>> I suspect in most cases the qtailqs on target are empty. 
>>
>> If I think about migration having no queues populated with
>> elements on a target site sounds very reasonable since IFAIU
>> the target should not do any work which would populate these
>> data structures.
>>
> See above.
>>
> 
>>
>>> If not,
>>> appending to them is a good choice. Clearing them is tricky since
>>> each queue probably require a specialized routine to clean. If they
>>> are not empty there are must be good reasons for that.
>>
>> Have you some code or a scenario in mind where this is legit? I
>> mean creating a mix of the state(?) we found at the target and
>> the state captured at the source does not sound right. I would
>> argue that the target should not have any state which is subject
>> to migration.
>>
>> You are right a non-empty queue is trouble, and frankly I never
>> considered it as a valid scenario.
>>
> It may not be a mix of state. It really depends on how the overall state
> of the devices is designed. If there are dependence between different
> elements of the state, then difference in these elements may break some
> consistency. One example is that migrating the length of the qtailq but
> appending the content to a non-empty qtailq. In such a case the length
> should not be migrated. It should be calculated on target instead.
> 
> It should be treated case by case.
> 

I did not get your argument here, but I think we can both live
without me understanding this.

Halil

Re: [Qemu-devel] [QEMU PATCH v10 3/3] tests/migration: Add test for QTAILQ migration

[Jianjun Duan]

On 11/03/2016 10:17 AM, Halil Pasic wrote:
> 
> 
> On 11/03/2016 05:47 PM, Jianjun Duan wrote:
>>
>> On 11/03/2016 05:22 AM, Halil Pasic wrote:


 On 11/02/2016 11:47 AM, Juan Quintela wrote:
>> Jianjun Duan  wrote:
 Add a test for QTAILQ migration to tests/test-vmstate.c.

 Signed-off-by: Jianjun Duan 
>>
>> Reviewed-by: Juan Quintela 
>>

 Empty QTAILQ seems to be broken. Have written a small
 test to prove my point. It May even make sense to have such
 a test in the test-suite (some prettyfication might be
 necessary though).

>> It is working as intended.
>>
> 
> My train of thought was that the object holding the queue might
> be dynamically allocated by the migration code or otherwise
> uninitialized. I was unaware these scenarios are prohibited.
> 
> 
This is a valid point. To get this covered vmstate_load_state needs to
be revised so that at any moment of recursion we know if the field is in
a dynamic created structure. If yes the structures which need
initialization such as QTAILQ can be initialized.

I would leave this until the need is there. In current device migration
code I imagine such scenarios would be rare if they should appear at
all. Because all the devices (even the hotplugged ones) are already
initialized on target. So a QTAILQ in such context should already be
initialized. Otherwise it should be fixed.

>> The current design is to append the qtailq from source to the
>> corresponding one on target. 
> 
> I do not see this documented. I'm used to vmstate_load overwriting
> values and following pointers, so IMHO it is not obvious that
> qtailq load does append.
> 

I will document this.

>> It works well for the task in hard
>> such as migrating ccs_list and pending_events for DRC objects.
>>
> 
> Because target head is always properly initialized to empty queue?
> 
They may not be empty. But they should be initialized.
>> I suspect in most cases the qtailqs on target are empty. 
> 
> If I think about migration having no queues populated with
> elements on a target site sounds very reasonable since IFAIU
> the target should not do any work which would populate these
> data structures.
> 
See above.
>

> 
>> If not,
>> appending to them is a good choice. Clearing them is tricky since
>> each queue probably require a specialized routine to clean. If they
>> are not empty there are must be good reasons for that.
> 
> Have you some code or a scenario in mind where this is legit? I
> mean creating a mix of the state(?) we found at the target and
> the state captured at the source does not sound right. I would
> argue that the target should not have any state which is subject
> to migration.
> 
> You are right a non-empty queue is trouble, and frankly I never
> considered it as a valid scenario.
> 
It may not be a mix of state. It really depends on how the overall state
of the devices is designed. If there are dependence between different
elements of the state, then difference in these elements may break some
consistency. One example is that migrating the length of the qtailq but
appending the content to a non-empty qtailq. In such a case the length
should not be migrated. It should be calculated on target instead.

It should be treated case by case.

Thanks,
Jianjun
> Sorry if I'm bothering you with nonsense.
> 
> Greetings,
> Halil
> 
>>
>> Thanks,
>> Jianjun
>>
> 

Re: [Qemu-devel] [PATCH v4 1/5] qom: Add interface check in object_class_is_abstract

[Markus Armbruster]

Lin Ma  writes:

> Signed-off-by: Lin Ma 
> ---
>  qom/object.c | 6 +-
>  1 file changed, 5 insertions(+), 1 deletion(-)
>
> diff --git a/qom/object.c b/qom/object.c
> index 7a05e35..4096645 100644
> --- a/qom/object.c
> +++ b/qom/object.c
> @@ -747,7 +747,11 @@ ObjectClass *object_get_class(Object *obj)
>  
>  bool object_class_is_abstract(ObjectClass *klass)
>  {
> -return klass->type->abstract;
> +if (type_is_ancestor(klass->type, type_interface)) {
> +return true;
> +} else {
> +return klass->type->abstract;
> +}
>  }
>  
>  const char *object_class_get_name(ObjectClass *klass)

Pardon my ignorance...

If all types derived from type_interface are abstract, why aren't we
setting ->abstract right when such a type is defined?

Hmm, perhaps we do?  type_initialize_interface() sets info.abstract =
true...

In case we don't: what about other uses of ->abstract?  Why is it okay
not to check whether type_interface is an ancestore there?

Re: [Qemu-devel] [PATCH v2 3/3] target-m68k: add cas/cas2 ops

[Laurent Vivier]

Le 03/11/2016 à 17:36, Richard Henderson a écrit :
> On 11/02/2016 03:15 PM, Laurent Vivier wrote:
>> +if (c1 != l1) {
>> +env->cc_n = l1;
>> +env->cc_v = c1;
>> +} else {
>> +env->cc_n = l2;
>> +env->cc_v = c2;
>> +}
>> +env->cc_op = CC_OP_CMPL;
>> +env->dregs[Dc1] = deposit32(env->dregs[Dc1], 0, 16, l1);
>> +env->dregs[Dc2] = deposit32(env->dregs[Dc2], 0, 16, l2);
> 
> CC_OP_CMPW for cas2w.

It was working because I have used helper_be_ldsw_mmu() to load values,
is it better to use helper_be_lduw_mmu with CC_OP_CMPW?

>> +DISAS_INSN(cas2l)
>> +{
> ...
>> +   regs = tcg_const_i32(REG(ext2, 6) |
>> +(REG(ext1, 6) << 3) |
>> +(REG(ext2, 0) << 6) |
>> +(REG(ext1, 0) << 9));
>> +   gen_helper_cas2w(cpu_env, regs, addr1, addr2);
> 
> cas2l.

I should not use values with the high word equal to the low word to test
this...

Many thanks,
Laurent

Re: [Qemu-devel] [PATCH v4 2/3] nvdimm acpi: introduce _FIT

[Igor Mammedov]

On Fri, 4 Nov 2016 01:39:31 +0800
Xiao Guangrong  wrote:

> 
> 
> On 11/04/2016 01:29 AM, Igor Mammedov wrote:
> > On Fri, 4 Nov 2016 00:53:06 +0800
> > Xiao Guangrong  wrote:
> >
> >>
> >>
> >> On 11/04/2016 12:49 AM, Igor Mammedov wrote:
> >>> On Fri, 4 Nov 2016 00:17:00 +0800
> >>> Xiao Guangrong  wrote:
> >>>
> 
> 
>  On 11/04/2016 12:13 AM, Igor Mammedov wrote:
> > On Thu, 3 Nov 2016 22:53:43 +0800
> > Xiao Guangrong  wrote:
> >
> >>
> >>
> >> On 11/03/2016 10:49 PM, Igor Mammedov wrote:
> >>> On Thu, 3 Nov 2016 21:02:22 +0800
> >>> Xiao Guangrong  wrote:
> >>>
> 
> 
>  On 11/03/2016 09:00 PM, Igor Mammedov wrote:
> 
> 
> 
> 
> >>> just drop this and describe properly 'len' in spec section
> >>> i.e. len: length of entire returned data (including the
> >>> header)
> >>
> >> Okay, i will change the spec like this:
> >>
> >> QEMU Writes Output Data (based on the offset in the
> >> page): [0x0 - 0x3]: 4 bytes, length of entire returned data
> >> (including the header)
> >>
> >> And drop the length field in Read_Fit return buffer, doc
> >> the fit buffer like this:
> >>
> >> 
> >> +--+++---+
> >> |  Field   | Length | Offset |
> >> Description   |
> >> +--+++---+
> > you need to add length here, otherwise this table is not
> > correct
> 
>  Ah, so i am confused.
> 
>  struct NvdimmFuncReadFITOut definition is based on the layout
>  of Read_FI output. You suggested to drop the length filed in
>  NvdimmFuncReadFITOut but keep it in the layout, it is not
>  consistent.
> 
>  I missed something?
> >>>
> >>> +struct NvdimmFuncReadFITOut {
> >>> +/* the size of buffer filled by QEMU. */
> >>> +uint32_t len;
> >>> +uint32_t func_ret_status; /* return status code. */
> >>> +uint8_t fit[0]; /* the FIT data. */
> >>> +} QEMU_PACKED;
> >>>
> >>> 
> >>> | field   | len | off | desc...
> >>> 
> >>> | length  |  4  |  0  | 
> >>> 
> >>> | status  |  4  |  4  | 
> >>> 
> >>> | fit data| 
> >>>
> >>> i.e. you were forgetting to add length in spec so offsets were
> >>> wrong even for described fields.
> >>
> >>
> >> We can not do this.
> >>
> >> @len is used by QEMU emulation to count the size of the buffer
> >> that _DSM should return. It's only used in NVDIMM_COMMON_DSM
> >> method which is shared by the DSM method from VM and Read_Fit.
> > spec describes buffer layout independently from AML that uses it,
> > so it should describe whole data structure.
> >
> > Then it's upto guest how to read this data, it could be QEMU
> > generated AML (as it's here) or some other driver or even BIOS.
> 
>  However, what we are talking about is Read_FIT method, so this is
>  the layout of Read_FIT output rather than all memory in the dsm
>  page.
> 
>  Actually, in the spec we already have documented the common len
>  field:
> 
>  QEMU Writes Output Data (based on the offset in the page):
>  [0x0 - 0x3]: 4 bytes, the length of result
>  [0x4 - 0xFFF]: 4092 bytes, the DSM result filled by QEMU
> 
>  Also, i really do not hope to use this field to count the buffer
>  size returned by Read_FIT, we'd try the best to reuse existing DSM
>  method (NVDIMM_COMMON_DSM), i.e, treat Read_FIT as normal DSM
>  method.
> >>> buffer layout describes interface between QEMU and firmware (AML)
> >>> and it should describe it completely every time to avoid confusion.
> >>>
> >>> See for example ACPI spec, NFIT table, SRAT table, ...
> >>> all table descriptions start with complete header.
> >>
> >> Okay. Understood. :)
> >>
> >>>
> >>> If you skip length it rises question how much fit data are there,
> >>> meaning interface description isn't complete.
> >>
> >> So how about introduce a length field in the output buffer just
> >> as this patch did? I understand we are able to count the size
> >> from dsm len, however, it can simplify the code a lot...
> > it's redundant as there already is length for whole buffer,
> > interface should be kept as simple as possible and not include
> > redundant data for convenience.
> 
> Okay.
> 
> So the doc 

Re: [Qemu-devel] [PATCH v2] target-sh4: add atomic tas

[Paolo Bonzini]

On 03/11/2016 17:51, Richard Henderson wrote:
>>> Well, tas_test "runs without error with this change", I suppose it fails
>>> before?  In other words, is this patch enough to run multithreaded sh4
>>> programs with qemu-user?
>>
>> It should,:the problem was reported by Adrian (cc:) while compiling ghc
>> in qemu-sh4, but I have just tested the functionality with the softmmu
>> version, not the atomicity.
>>
>> Adrian, could you test this patch?
> 
> It's a start, but sh4 has an interesting scheme to implement atomic
> sequences via special values in the stack pointer.  E.g. xchg is
> 
> mova1f, r0
> movsp, r1
> mov#(0f-1f), sp
> 0:mov.lmem, out
> mov.lin, mem
> 1:movr1, sp
> 
> which is only atomic if you've got a UP kernel and have code in your
> interrupt entry point that recognizes the small negative value in SP to
> reset the PC as necessary.

UP kernel = no sane way to implement this in user-mode qemu?  Doing
pattern matching on negative sp moves and the instructions in between is
probably not sane, even though GCC always has:

- mov/mov for exchange
- mov/cmpeq/bf/mov for compare-and-swap
- mov/mov/op/mov for fetch-and-foo
- mov/mov/and/not/mov for fetch-and-nand
- mov/op/mov for foo-and-fetch
- mov/and/not/mov for nand-and-fetch

Another possibility is to treat the load as a LL and the store as a SC
(implemented in turn with cmpxchg+branch if it fails).  cmpxchg spans
two basic blocks, so maybe one also needs to look at r0 and sp in
cpu_get_tb_cpu_state...

Anyhow this patch seems like a bugfix.

Paolo

> For SH4A, there are proper load-locked/store-condition insns, but prior
> to that TAS was the only truly atomic insn.

Re: [Qemu-devel] [PATCH v2 3/3] tests: Enhance qobject output to cover partial visit

[Eric Blake]

On 11/03/2016 11:42 AM, Markus Armbruster wrote:
> Eric Blake  writes:
> 
>> Add a test that proves (at least when run under valgrind) that
>> we are correctly handling allocated memory even when a visit
>> is aborted in the middle for whatever other reason.
>>
>> See commit f24582d "qapi: fix double free in
>> qmp_output_visitor_cleanup()" for a fix that was lacking
>> testsuite exposure prior to this patch.
>>
>> Signed-off-by: Eric Blake 

>> +static void test_visitor_out_partial_visit(TestOutputVisitorData *data,
>> +   const void *unused)
>> +{
>> +/* Various checks that a mid-visit abort doesn't leak or double-free. */
>> +const char *str = "hi";
>> +Error *err = NULL;
>> +UserDefAlternate uda = { .type = QTYPE_QDICT,
>> + .u.udfu = { .integer = 1,
>> + .string = (char *) "bye",
>> + .enum1 = -1 } };

^ Not a valid enum value...


>> +
>> +/* Abort in the middle of an alternate. Alternates can't be
>> + * virtually visited, so we get to inline the first half of
>> + * visit_type_UserDefAlternate(). */
>> +visit_start_alternate(data->ov, NULL, (GenericAlternate **),
>> +  sizeof(uda), false, _abort);
>> +visit_start_struct(data->ov, NULL, NULL, 0, _abort);
>> +visit_type_UserDefUnionBase_members(data->ov,
>> +(UserDefUnionBase *),
>> +);
>> +error_free_or_abort();
> 
> Why does this fail?

...so visiting the UnionBase_members gripes loudly.  But I see your
point that more comments would be helpful.

-- 
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 v4 2/3] nvdimm acpi: introduce _FIT

[Xiao Guangrong]

On 11/04/2016 01:29 AM, Igor Mammedov wrote:

On Fri, 4 Nov 2016 00:53:06 +0800
Xiao Guangrong  wrote:




On 11/04/2016 12:49 AM, Igor Mammedov wrote:

On Fri, 4 Nov 2016 00:17:00 +0800
Xiao Guangrong  wrote:




On 11/04/2016 12:13 AM, Igor Mammedov wrote:

On Thu, 3 Nov 2016 22:53:43 +0800
Xiao Guangrong  wrote:




On 11/03/2016 10:49 PM, Igor Mammedov wrote:

On Thu, 3 Nov 2016 21:02:22 +0800
Xiao Guangrong  wrote:




On 11/03/2016 09:00 PM, Igor Mammedov wrote:





just drop this and describe properly 'len' in spec section
i.e. len: length of entire returned data (including the
header)


Okay, i will change the spec like this:

QEMU Writes Output Data (based on the offset in the
page): [0x0 - 0x3]: 4 bytes, length of entire returned data
(including the header)

And drop the length field in Read_Fit return buffer, doc
the fit buffer like this:

+--+++---+
|  Field   | Length | Offset |
Description   |
+--+++---+

you need to add length here, otherwise this table is not
correct


Ah, so i am confused.

struct NvdimmFuncReadFITOut definition is based on the layout
of Read_FI output. You suggested to drop the length filed in
NvdimmFuncReadFITOut but keep it in the layout, it is not
consistent.

I missed something?


+struct NvdimmFuncReadFITOut {
+/* the size of buffer filled by QEMU. */
+uint32_t len;
+uint32_t func_ret_status; /* return status code. */
+uint8_t fit[0]; /* the FIT data. */
+} QEMU_PACKED;


| field   | len | off | desc...

| length  |  4  |  0  | 

| status  |  4  |  4  | 

| fit data| 

i.e. you were forgetting to add length in spec so offsets were
wrong even for described fields.



We can not do this.

@len is used by QEMU emulation to count the size of the buffer
that _DSM should return. It's only used in NVDIMM_COMMON_DSM
method which is shared by the DSM method from VM and Read_Fit.

spec describes buffer layout independently from AML that uses it,
so it should describe whole data structure.

Then it's upto guest how to read this data, it could be QEMU
generated AML (as it's here) or some other driver or even BIOS.


However, what we are talking about is Read_FIT method, so this is
the layout of Read_FIT output rather than all memory in the dsm
page.

Actually, in the spec we already have documented the common len
field:

QEMU Writes Output Data (based on the offset in the page):
[0x0 - 0x3]: 4 bytes, the length of result
[0x4 - 0xFFF]: 4092 bytes, the DSM result filled by QEMU

Also, i really do not hope to use this field to count the buffer
size returned by Read_FIT, we'd try the best to reuse existing DSM
method (NVDIMM_COMMON_DSM), i.e, treat Read_FIT as normal DSM
method.

buffer layout describes interface between QEMU and firmware (AML)
and it should describe it completely every time to avoid confusion.

See for example ACPI spec, NFIT table, SRAT table, ...
all table descriptions start with complete header.


Okay. Understood. :)



If you skip length it rises question how much fit data are there,
meaning interface description isn't complete.


So how about introduce a length field in the output buffer just
as this patch did? I understand we are able to count the size
from dsm len, however, it can simplify the code a lot...

it's redundant as there already is length for whole buffer,
interface should be kept as simple as possible and not include
redundant data for convenience.


Okay.

So the doc should be changed to:

   Output layout in the dsm memory page:

   +--+++---+
   |  Field   | Length | Offset | Description   |
   +--+++---+
   | length   |   4|   4| length of entire returned data|
   |  ||| (including the header)|
   +--+-+---+
   |  ||| return status codes   |
   |  ||| 0x100 - error caused by NFIT update while |
   | status   |   4|   4| read by _FIT wasn't completed, other  |
   |  ||| codes follow Chapter 3 in DSM Spec Rev1   |
   +--+++---+
   | fit data | Varies |   8| FIT data, the remaining size is used by   |
   |  ||| fit data if status is success;|
   |  ||| otherwise it 

Re: [Qemu-devel] [PATCH v4 2/3] nvdimm acpi: introduce _FIT

[Igor Mammedov]

On Fri, 4 Nov 2016 00:53:06 +0800
Xiao Guangrong  wrote:

> 
> 
> On 11/04/2016 12:49 AM, Igor Mammedov wrote:
> > On Fri, 4 Nov 2016 00:17:00 +0800
> > Xiao Guangrong  wrote:
> >
> >>
> >>
> >> On 11/04/2016 12:13 AM, Igor Mammedov wrote:
> >>> On Thu, 3 Nov 2016 22:53:43 +0800
> >>> Xiao Guangrong  wrote:
> >>>
> 
> 
>  On 11/03/2016 10:49 PM, Igor Mammedov wrote:
> > On Thu, 3 Nov 2016 21:02:22 +0800
> > Xiao Guangrong  wrote:
> >
> >>
> >>
> >> On 11/03/2016 09:00 PM, Igor Mammedov wrote:
> >>
> >>
> >>
> >>
> > just drop this and describe properly 'len' in spec section
> > i.e. len: length of entire returned data (including the
> > header)
> 
>  Okay, i will change the spec like this:
> 
>  QEMU Writes Output Data (based on the offset in the
>  page): [0x0 - 0x3]: 4 bytes, length of entire returned data
>  (including the header)
> 
>  And drop the length field in Read_Fit return buffer, doc
>  the fit buffer like this:
> 
>  
>  +--+++---+
>  |  Field   | Length | Offset |
>  Description   |
>  +--+++---+
> >>> you need to add length here, otherwise this table is not
> >>> correct
> >>
> >> Ah, so i am confused.
> >>
> >> struct NvdimmFuncReadFITOut definition is based on the layout
> >> of Read_FI output. You suggested to drop the length filed in
> >> NvdimmFuncReadFITOut but keep it in the layout, it is not
> >> consistent.
> >>
> >> I missed something?
> >
> > +struct NvdimmFuncReadFITOut {
> > +/* the size of buffer filled by QEMU. */
> > +uint32_t len;
> > +uint32_t func_ret_status; /* return status code. */
> > +uint8_t fit[0]; /* the FIT data. */
> > +} QEMU_PACKED;
> >
> > 
> > | field   | len | off | desc...
> > 
> > | length  |  4  |  0  | 
> > 
> > | status  |  4  |  4  | 
> > 
> > | fit data| 
> >
> > i.e. you were forgetting to add length in spec so offsets were
> > wrong even for described fields.
> 
> 
>  We can not do this.
> 
>  @len is used by QEMU emulation to count the size of the buffer
>  that _DSM should return. It's only used in NVDIMM_COMMON_DSM
>  method which is shared by the DSM method from VM and Read_Fit.
> >>> spec describes buffer layout independently from AML that uses it,
> >>> so it should describe whole data structure.
> >>>
> >>> Then it's upto guest how to read this data, it could be QEMU
> >>> generated AML (as it's here) or some other driver or even BIOS.
> >>
> >> However, what we are talking about is Read_FIT method, so this is
> >> the layout of Read_FIT output rather than all memory in the dsm
> >> page.
> >>
> >> Actually, in the spec we already have documented the common len
> >> field:
> >>
> >> QEMU Writes Output Data (based on the offset in the page):
> >> [0x0 - 0x3]: 4 bytes, the length of result
> >> [0x4 - 0xFFF]: 4092 bytes, the DSM result filled by QEMU
> >>
> >> Also, i really do not hope to use this field to count the buffer
> >> size returned by Read_FIT, we'd try the best to reuse existing DSM
> >> method (NVDIMM_COMMON_DSM), i.e, treat Read_FIT as normal DSM
> >> method.
> > buffer layout describes interface between QEMU and firmware (AML)
> > and it should describe it completely every time to avoid confusion.
> >
> > See for example ACPI spec, NFIT table, SRAT table, ...
> > all table descriptions start with complete header.
> 
> Okay. Understood. :)
> 
> >
> > If you skip length it rises question how much fit data are there,
> > meaning interface description isn't complete.
> 
> So how about introduce a length field in the output buffer just
> as this patch did? I understand we are able to count the size
> from dsm len, however, it can simplify the code a lot...
it's redundant as there already is length for whole buffer,
interface should be kept as simple as possible and not include
redundant data for convenience.

> 
> >
> > if you want to describe AML there you can do it after interface
> > description saying that common NCAL method extracts status and fit
> > data form dsm page and returns that as buffer object, but it's AML
> > impl. specific. I could write an alternative AML code that would
> > deal with dms page in its own way as long as I would know what
> > write/read at what offset.
> 
> Yes, i agree with you.
> 

Re: [Qemu-devel] [QEMU PATCH v10 3/3] tests/migration: Add test for QTAILQ migration

[Halil Pasic]

On 11/03/2016 05:47 PM, Jianjun Duan wrote:
> 
> On 11/03/2016 05:22 AM, Halil Pasic wrote:
>> > 
>> > 
>> > On 11/02/2016 11:47 AM, Juan Quintela wrote:
>>> >> Jianjun Duan  wrote:
 >>> Add a test for QTAILQ migration to tests/test-vmstate.c.
 >>>
 >>> Signed-off-by: Jianjun Duan 
>>> >>
>>> >> Reviewed-by: Juan Quintela 
>>> >>
>> > 
>> > Empty QTAILQ seems to be broken. Have written a small
>> > test to prove my point. It May even make sense to have such
>> > a test in the test-suite (some prettyfication might be
>> > necessary though).
>> > 
> It is working as intended.
>

My train of thought was that the object holding the queue might
be dynamically allocated by the migration code or otherwise
uninitialized. I was unaware these scenarios are prohibited.

 
> The current design is to append the qtailq from source to the
> corresponding one on target. 

I do not see this documented. I'm used to vmstate_load overwriting
values and following pointers, so IMHO it is not obvious that
qtailq load does append.

> It works well for the task in hard
> such as migrating ccs_list and pending_events for DRC objects.
> 

Because target head is always properly initialized to empty queue?

> I suspect in most cases the qtailqs on target are empty. 

If I think about migration having no queues populated with
elements on a target site sounds very reasonable since IFAIU
the target should not do any work which would populate these
data structures.


> If not,
> appending to them is a good choice. Clearing them is tricky since
> each queue probably require a specialized routine to clean. If they
> are not empty there are must be good reasons for that.

Have you some code or a scenario in mind where this is legit? I
mean creating a mix of the state(?) we found at the target and
the state captured at the source does not sound right. I would
argue that the target should not have any state which is subject
to migration.

You are right a non-empty queue is trouble, and frankly I never
considered it as a valid scenario.

Sorry if I'm bothering you with nonsense.

Greetings,
Halil

> 
> Thanks,
> Jianjun
> 

Re: [Qemu-devel] [PULL 00/47] virtio, pc: fixes and features

[Stefan Hajnoczi]

On Sun, Oct 30, 2016 at 11:23:18PM +0200, Michael S. Tsirkin wrote:
> The following changes since commit 5b2ecabaeabc17f032197246c4846b9ba95ba8a6:
> 
>   Merge remote-tracking branch 'remotes/kraxel/tags/pull-ui-20161028-1' into 
> staging (2016-10-28 17:59:04 +0100)
> 
> 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 f082ec0225bd15c71e0b4697d2df3af7bad65d7f:
> 
>   acpi: fix assert failure caused by commit 35c5a52d (2016-10-30 20:06:25 
> +0200)
> 
> 
> virtio, pc: fixes and features
> 
> nvdimm hotplug support
> virtio migration and ioeventfd rework
> virtio crypto device
> ipmi fixes
> 
> Signed-off-by: Michael S. Tsirkin 
> 
> 
> Corey Minyard (5):
>   ipmi: Remove hotplug from IPMI BMCs
>   ipmi_bmc_sim: Remove an unnecessary mutex
>   ipmi: Implement shutdown via ACPI overtemp
>   ipmi: Add graceful shutdown handling to the external BMC
>   acpi/ipmi: Initialize the fwinfo before fetching it
> 
> Cédric Le Goater (1):
>   ipmi: chassis poweroff should use qemu_system_shutdown_request()
> 
> Daniel P. Berrange (1):
>   ipmi: fix build config variable name for ipmi_bmc_extern.o
> 
> Dr. David Alan Gilbert (2):
>   virtio/migration: Add VMStateDescription to VirtioDeviceClass
>   virtio/migration: Migrate balloon to VMState
> 
> Gonglei (12):
>   cryptodev: introduce cryptodev backend interface
>   cryptodev: add symmetric algorithm operation stuff
>   virtio-crypto: introduce virtio_crypto.h
>   cryptodev: introduce a new cryptodev backend
>   virtio-crypto: add virtio crypto device emulation
>   virtio-crypto-pci: add virtio crypto pci support
>   virtio-crypto: set capacity of algorithms supported
>   virtio-crypto: add control queue handler
>   virtio-crypto: add data queue processing handler
>   cryptodev: introduce an unified wrapper for crypto operation
>   virtio-crypto: using bh to handle dataq's requests
>   virtio-crypto: add myself as virtio-crypto and cryptodev backends 
> maintainer
> 
> Haozhong Zhang (1):
>   acpi: fix assert failure caused by commit 35c5a52d
> 
> Paolo Bonzini (13):
>   virtio: disable ioeventfd as early as possible
>   virtio: move ioeventfd_disabled flag to VirtioBusState
>   virtio: move ioeventfd_started flag to VirtioBusState
>   virtio: add start_ioeventfd and stop_ioeventfd to VirtioDeviceClass
>   virtio: introduce virtio_device_ioeventfd_enabled
>   virtio-blk: always use dataplane path if ioeventfd is active
>   virtio-scsi: always use dataplane path if ioeventfd is active
>   Revert "virtio: Introduce virtio_add_queue_aio"
>   virtio: remove set_handler argument from set_host_notifier_internal
>   virtio: remove ioeventfd_disabled altogether
>   virtio: use virtio_bus_set_host_notifier to start/stop ioeventfd
>   virtio: inline virtio_queue_set_host_notifier_fd_handler
>   virtio: inline set_host_notifier_internal
> 
> Xiao Guangrong (12):
>   acpi nvdimm: fix wrong buffer size returned by DSM method
>   acpi nvdimm: fix OperationRegion definition
>   acpi nvdimm: fix device physical address base
>   acpi nvdimm: fix ARG3 conflict
>   acpi nvdimm: fix Arg6 usage
>   nvdimm acpi: compile nvdimm acpi code arch-independently
>   acpi nvdimm: rename result_size to dsm_out_buf_siz
>   nvdimm acpi: use common macros instead of magic names
>   nvdimm acpi: prebuild nvdimm devices for available slots
>   nvdimm acpi: introduce fit buffer
>   nvdimm acpi: introduce _FIT
>   pc: memhp: enable nvdimm device hotplug
> 
>  hw/block/dataplane/virtio-blk.h|   6 +-
>  hw/s390x/virtio-ccw.h  |   2 -
>  hw/virtio/virtio-pci.h |  17 +-
>  include/hw/acpi/acpi_dev_interface.h   |   1 +
>  include/hw/hotplug.h   |  10 +
>  include/hw/mem/nvdimm.h|  27 +-
>  include/hw/virtio/virtio-bus.h |  27 +-
>  include/hw/virtio/virtio-crypto.h  | 101 +++
>  include/hw/virtio/virtio-scsi.h|   6 +-
>  include/hw/virtio/virtio.h |  15 +-
>  include/standard-headers/linux/virtio_crypto.h | 429 
>  include/standard-headers/linux/virtio_ids.h|   2 +-
>  include/sysemu/cryptodev.h | 298 
>  backends/cryptodev-builtin.c   | 361 ++
>  backends/cryptodev.c   | 245 +++
>  hw/acpi/ipmi.c |   1 +
>  hw/acpi/memory_hotplug.c   |  31 +-
>  hw/acpi/nvdimm.c   | 468 ++---
>  hw/block/dataplane/virtio-blk.c   

Re: [Qemu-devel] [PATCH V2 05/11] exec: introduce address_space_get_iotlb_entry()

[Paolo Bonzini]

On 03/11/2016 10:27, Jason Wang wrote:
> This patch introduces a helper to query the iotlb entry for a
> possible iova. This will be used by later device IOTLB API to enable
> the capability for a dataplane (e.g vhost) to query the IOTLB.
> 
> Cc: Paolo Bonzini 
> Cc: Peter Crosthwaite 
> Cc: Richard Henderson 
> Signed-off-by: Jason Wang 
> ---
>  exec.c| 33 +
>  include/exec/memory.h |  6 ++
>  2 files changed, 39 insertions(+)
> 
> diff --git a/exec.c b/exec.c
> index b1094c0..00c7a2b 100644
> --- a/exec.c
> +++ b/exec.c
> @@ -449,6 +449,39 @@ address_space_translate_internal(AddressSpaceDispatch 
> *d, hwaddr addr, hwaddr *x
>  }
>  
>  /* Called from RCU critical section */
> +IOMMUTLBEntry address_space_get_iotlb_entry(AddressSpace *as, hwaddr addr,
> +bool is_write)
> +{
> +IOMMUTLBEntry iotlb = {0};
> +MemoryRegionSection *section;
> +MemoryRegion *mr;
> +hwaddr plen;

plen must be initialized on entry to address_space_translate_internal,
since it's set to

   MIN(plen, MIN(section->size,
 addr - section->offset_within_address_space))

after address_space_translate_internal calls
address_space_lookup_region.  But you don't really need plen, so you
should do this:

section = address_space_lookup_region(d, addr, false);
addr = addr
- section->offset_within_address_space
+ section->offset_within_region;

instead of

section = address_space_translate_internal(d, addr, ,
   , true);

and then you don't even need a plen anymore.

Also:


> +for (;;) {
> +AddressSpaceDispatch *d = atomic_rcu_read(>dispatch);
> +section = address_space_translate_internal(d, addr, , , 
> true);
> +mr = section->mr;
> +
> +if (!mr->iommu_ops) {
> +break;
> +}
> +
> +iotlb = mr->iommu_ops->translate(mr, addr, is_write);
> +addr = ((iotlb.translated_addr & ~iotlb.addr_mask)
> +| (addr & iotlb.addr_mask));

This addr assignment is only needed after the iotlb.perm check, so move
it there.

Thanks,

Paolo

> +plen = MIN(plen, (addr | iotlb.addr_mask) - addr + 1);
> +if (!(iotlb.perm & (1 << is_write))) {
> +iotlb.target_as = NULL;
> +break;
> +}
> +
> +as = iotlb.target_as;
> +}
> +
> +return iotlb;
> +}
> +
> +/* Called from RCU critical section */
>  MemoryRegion *address_space_translate(AddressSpace *as, hwaddr addr,
>hwaddr *xlat, hwaddr *plen,
>bool is_write)
> diff --git a/include/exec/memory.h b/include/exec/memory.h
> index 9728a2f..e605de3 100644
> --- a/include/exec/memory.h
> +++ b/include/exec/memory.h
> @@ -1404,6 +1404,12 @@ void address_space_stq_le(AddressSpace *as, hwaddr 
> addr, uint64_t val,
>  void address_space_stq_be(AddressSpace *as, hwaddr addr, uint64_t val,
>  MemTxAttrs attrs, MemTxResult *result);
>  
> +/* address_space_get_iotlb_entry: translate an address into an IOTLB
> + * entry. Should be called from an RCU critical section.
> + */
> +IOMMUTLBEntry address_space_get_iotlb_entry(AddressSpace *as, hwaddr addr,
> +bool is_write);
> +
>  /* address_space_translate: translate an address range into an address space
>   * into a MemoryRegion and an address range into that section.  Should be
>   * called from an RCU critical section, to avoid that the last reference
> 

Re: [Qemu-devel] [PATCH v4 2/3] nvdimm acpi: introduce _FIT

[Xiao Guangrong]

On 11/04/2016 12:49 AM, Igor Mammedov wrote:

On Fri, 4 Nov 2016 00:17:00 +0800
Xiao Guangrong  wrote:




On 11/04/2016 12:13 AM, Igor Mammedov wrote:

On Thu, 3 Nov 2016 22:53:43 +0800
Xiao Guangrong  wrote:




On 11/03/2016 10:49 PM, Igor Mammedov wrote:

On Thu, 3 Nov 2016 21:02:22 +0800
Xiao Guangrong  wrote:




On 11/03/2016 09:00 PM, Igor Mammedov wrote:





just drop this and describe properly 'len' in spec section
i.e. len: length of entire returned data (including the
header)


Okay, i will change the spec like this:

QEMU Writes Output Data (based on the offset in the page):
[0x0 - 0x3]: 4 bytes, length of entire returned data
(including the header)

And drop the length field in Read_Fit return buffer, doc
the fit buffer like this:

+--+++---+
|  Field   | Length | Offset |
Description   |
+--+++---+

you need to add length here, otherwise this table is not correct


Ah, so i am confused.

struct NvdimmFuncReadFITOut definition is based on the layout of
Read_FI output. You suggested to drop the length filed in
NvdimmFuncReadFITOut but keep it in the layout, it is not
consistent.

I missed something?


+struct NvdimmFuncReadFITOut {
+/* the size of buffer filled by QEMU. */
+uint32_t len;
+uint32_t func_ret_status; /* return status code. */
+uint8_t fit[0]; /* the FIT data. */
+} QEMU_PACKED;


| field   | len | off | desc...

| length  |  4  |  0  | 

| status  |  4  |  4  | 

| fit data| 

i.e. you were forgetting to add length in spec so offsets were
wrong even for described fields.



We can not do this.

@len is used by QEMU emulation to count the size of the buffer that
_DSM should return. It's only used in NVDIMM_COMMON_DSM method
which is shared by the DSM method from VM and Read_Fit.

spec describes buffer layout independently from AML that uses it,
so it should describe whole data structure.

Then it's upto guest how to read this data, it could be QEMU
generated AML (as it's here) or some other driver or even BIOS.


However, what we are talking about is Read_FIT method, so this is
the layout of Read_FIT output rather than all memory in the dsm page.

Actually, in the spec we already have documented the common len field:

QEMU Writes Output Data (based on the offset in the page):
[0x0 - 0x3]: 4 bytes, the length of result
[0x4 - 0xFFF]: 4092 bytes, the DSM result filled by QEMU

Also, i really do not hope to use this field to count the buffer size
returned by Read_FIT, we'd try the best to reuse existing DSM method
(NVDIMM_COMMON_DSM), i.e, treat Read_FIT as normal DSM method.

buffer layout describes interface between QEMU and firmware (AML)
and it should describe it completely every time to avoid confusion.

See for example ACPI spec, NFIT table, SRAT table, ...
all table descriptions start with complete header.


Okay. Understood. :)



If you skip length it rises question how much fit data are there,
meaning interface description isn't complete.


So how about introduce a length field in the output buffer just
as this patch did? I understand we are able to count the size
from dsm len, however, it can simplify the code a lot...



if you want to describe AML there you can do it after interface
description saying that common NCAL method extracts status and fit
data form dsm page and returns that as buffer object, but it's AML
impl. specific. I could write an alternative AML code that would deal
with dms page in its own way as long as I would know what write/read at
what offset.


Yes, i agree with you.

[Qemu-devel] [PATCH] linux-user: fix inotify_init1() support

[Lena Djokic]

This commit adds necessary conversion of argument passed to inotify_init1().
inotify_init1() flags can be IN_NONBLOCK and IN_CLOEXEC which rely on O_NONBLOCK
and O_CLOEXEC and those can have different values on different platforms.

Signed-off-by: Lena Djokic 
---
 linux-user/syscall.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/linux-user/syscall.c b/linux-user/syscall.c
index 7b77503..861ccc5 100644
--- a/linux-user/syscall.c
+++ b/linux-user/syscall.c
@@ -11550,7 +11550,8 @@ abi_long do_syscall(void *cpu_env, int num, abi_long 
arg1,
 #ifdef CONFIG_INOTIFY1
 #if defined(TARGET_NR_inotify_init1) && defined(__NR_inotify_init1)
 case TARGET_NR_inotify_init1:
-ret = get_errno(sys_inotify_init1(arg1));
+ret = get_errno(sys_inotify_init1(target_to_host_bitmask(arg1,
+  fcntl_flags_tbl)));
 break;
 #endif
 #endif
-- 
2.7.4

Re: [Qemu-devel] [PATCH 0/2] qom+coccinelle: add and use object_new_with_class()

[Markus Armbruster]

Radim Krčmář  writes:

> This series performs a simple replacement of
> object_new(object_class_get_name(class)) by object_new_with_class(class)
> in the spirit of existing object_new_with_type().

Who's going to take this one?  Still more review needed?

Re: [Qemu-devel] [PULL v3 00/30] Misc patches for 2016-10-31

[Stefan Hajnoczi]

On Wed, Nov 02, 2016 at 09:32:21AM +0100, Paolo Bonzini wrote:
> The following changes since commit 39542105bbb19c690219d2f22844d8dfbd9bba05:
> 
>   Merge remote-tracking branch 'remotes/gkurz/tags/for-upstream' into staging 
> (2016-11-01 12:48:07 +)
> 
> are available in the git repository at:
> 
>   git://github.com/bonzini/qemu.git tags/for-upstream
> 
> for you to fetch changes up to 7d175d29c9430fcba7a98f2c71925137b7870da4:
> 
>   main-loop: Suppress I/O thread warning under qtest (2016-11-02 09:28:57 
> +0100)
> 
> 
> * NBD bugfix (Changlong)
> * NBD write zeroes support (Eric)
> * Memory backend fixes (Haozhong)
> * Atomics fix (Alex)
> * New AVX512 features (Luwei)
> * "make check" logging fix (Paolo)
> * Chardev refactoring fallout (Paolo)
> * Small checkpatch improvements (Paolo, Jeff)
> 
> 
> Alex Bennée (1):
>   exec.c: ensure all AddressSpaceDispatch updates under RCU
> 
> Changlong Xie (1):
>   nbd: Use CoQueue for free_sema instead of CoMutex
> 
> Christian Borntraeger (1):
>   vl: exit qemu on guest panic if -no-shutdown is not set
> 
> Eric Blake (16):
>   nbd: Add qemu-nbd -D for human-readable description
>   nbd: Treat flags vs. command type as separate fields
>   nbd: Rename NBDRequest to NBDRequestData
>   nbd: Rename NbdClientSession to NBDClientSession
>   nbd: Rename struct nbd_request and nbd_reply
>   nbd: Share common reply-sending code in server
>   nbd: Send message along with server NBD_REP_ERR errors
>   nbd: Share common option-sending code in client
>   nbd: Let server know when client gives up negotiation
>   nbd: Let client skip portions of server reply
>   nbd: Less allocation during NBD_OPT_LIST
>   nbd: Support shorter handshake
>   nbd: Refactor conversion to errno to silence checkpatch
>   nbd: Improve server handling of shutdown requests
>   nbd: Implement NBD_CMD_WRITE_ZEROES on server
>   nbd: Implement NBD_CMD_WRITE_ZEROES on client
> 
> Haozhong Zhang (2):
>   exec.c: do not truncate non-empty memory backend file
>   exec.c: check memory backend file size with 'size' option
> 
> Jeff Cody (1):
>   checkpatch: allow spaces before parenthesis for 'coroutine_fn'
> 
> Luwei Kang (1):
>   x86: add AVX512_4VNNIW and AVX512_4FMAPS features
> 
> Max Reitz (1):
>   main-loop: Suppress I/O thread warning under qtest
> 
> Paolo Bonzini (5):
>   checkpatch: tweak "struct should normally be const" warning
>   qemu-error: remove dependency of stubs on monitor
>   tests: send error_report to test log
>   qemu-char: do not forward events through the mux until QEMU has started
>   slirp: fix CharDriver breakage
> 
> Pranith Kumar (1):
>   docs/rcu.txt: Fix minor typo
> 
>  block/nbd-client.c  | 104 +
>  block/nbd-client.h  |  12 +-
>  block/nbd.c |   8 +-
>  docs/rcu.txt|   2 +-
>  exec.c  |  33 ++-
>  include/block/nbd.h |  73 +--
>  include/glib-compat.h   |  13 ++
>  include/qemu/error-report.h |   1 +
>  include/qemu/osdep.h|   3 +
>  main-loop.c |   2 +-
>  monitor.c   |  21 ++
>  nbd/client.c| 498 
> 
>  nbd/nbd-internal.h  |  12 +-
>  nbd/server.c| 292 ++
>  net/slirp.c |   3 +-
>  qapi-schema.json|   4 +-
>  qemu-char.c |   8 +-
>  qemu-nbd.c  |  12 +-
>  qemu-nbd.texi   |   5 +-
>  scripts/checkpatch.pl   |   6 +-
>  stubs/Makefile.objs |   2 +-
>  stubs/error-printf.c|  19 ++
>  stubs/mon-printf.c  |  11 -
>  target-i386/cpu.c   |  19 +-
>  target-i386/cpu.h   |   4 +
>  util/qemu-error.c   |  26 +--
>  vl.c|   5 +
>  27 files changed, 763 insertions(+), 435 deletions(-)
>  create mode 100644 stubs/error-printf.c
>  delete mode 100644 stubs/mon-printf.c
> -- 
> 2.7.4
> 
> 

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

Will be in qemu.git pending Travis-CI build tests.

Stefan


signature.asc
Description: PGP signature

Re: [Qemu-devel] [PATCH V2 10/11] memory: handle alias in memory_region_is_iommu()

[Paolo Bonzini]

On 03/11/2016 10:27, Jason Wang wrote:
> Signed-off-by: Jason Wang 
> ---
>  include/exec/memory.h | 3 +++
>  1 file changed, 3 insertions(+)
> 
> diff --git a/include/exec/memory.h b/include/exec/memory.h
> index e605de3..ab37499 100644
> --- a/include/exec/memory.h
> +++ b/include/exec/memory.h
> @@ -628,6 +628,9 @@ static inline bool memory_region_is_romd(MemoryRegion *mr)
>   */
>  static inline bool memory_region_is_iommu(MemoryRegion *mr)
>  {
> +if (mr->alias) {
> +return memory_region_is_iommu(mr->alias);
> +}
>  return mr->iommu_ops;
>  }
>  
> 

Acked-by: Paolo Bonzini 

Re: [Qemu-devel] [PATCH V2 09/11] memory: handle alias for iommu notifier

[Paolo Bonzini]

On 03/11/2016 10:27, Jason Wang wrote:
> Cc: Paolo Bonzini 
> Signed-off-by: Jason Wang 
> ---
>  memory.c | 9 +
>  1 file changed, 9 insertions(+)
> 
> diff --git a/memory.c b/memory.c
> index 33110e9..2bfc37f 100644
> --- a/memory.c
> +++ b/memory.c
> @@ -1603,6 +1603,11 @@ static void 
> memory_region_update_iommu_notify_flags(MemoryRegion *mr)
>  void memory_region_register_iommu_notifier(MemoryRegion *mr,
> IOMMUNotifier *n)
>  {
> +if (mr->alias) {
> +memory_region_register_iommu_notifier(mr->alias, n);
> +return;
> +}
> +
>  /* We need to register for at least one bitfield */
>  assert(n->notifier_flags != IOMMU_NOTIFIER_NONE);
>  QLIST_INSERT_HEAD(>iommu_notify, n, node);
> @@ -1643,6 +1648,10 @@ void memory_region_iommu_replay(MemoryRegion *mr, 
> IOMMUNotifier *n,
>  void memory_region_unregister_iommu_notifier(MemoryRegion *mr,
>   IOMMUNotifier *n)
>  {
> +if (mr->alias) {
> +memory_region_unregister_iommu_notifier(mr->alias, n);
> +return;
> +}
>  QLIST_REMOVE(n, node);
>  memory_region_update_iommu_notify_flags(mr);
>  }
> 

Acked-by: Paolo Bonzini 

Re: [Qemu-devel] [PATCH v2] target-sh4: add atomic tas

[Laurent Vivier]

Le 03/11/2016 à 17:21, Laurent Vivier a écrit :
> Le 03/11/2016 à 17:18, Paolo Bonzini a écrit :
>>
>>
>> On 03/11/2016 16:35, Laurent Vivier wrote:
>>> Le 03/11/2016 à 16:32, Paolo Bonzini a écrit :


 On 03/11/2016 15:07, Laurent Vivier wrote:
> Implement real atomic tas:
>
> When (Rn) = 0, 1 -> T
> Otherwise, 0 -> T
> In both cases, 1 -> MSB of (Rn)
>
> using atomic_fetch_or_i32() and setcondi_i32().
>
> Tested with image from:
> http://wiki.qemu.org/download/sh-test-0.2.tar.bz2
>
> This image contains a "tas_test" that runs without
> error with this change.
>
> Signed-off-by: Laurent Vivier 
> ---
> v2:
> - don't use helper but atomic_fetch_or_i32
>   Thank you Paolo!
>
>  target-sh4/translate.c | 19 ---
>  1 file changed, 8 insertions(+), 11 deletions(-)
>
> diff --git a/target-sh4/translate.c b/target-sh4/translate.c
> index c89a147..1b83d59 100644
> --- a/target-sh4/translate.c
> +++ b/target-sh4/translate.c
> @@ -1640,18 +1640,15 @@ static void _decode_opc(DisasContext * ctx)
>   tcg_gen_shri_i32(REG(B11_8), REG(B11_8), 16);
>   return;
>  case 0x401b: /* tas.b @Rn */
> - {
> - TCGv addr, val;
> - addr = tcg_temp_local_new();
> - tcg_gen_mov_i32(addr, REG(B11_8));
> - val = tcg_temp_local_new();
> -tcg_gen_qemu_ld_i32(val, addr, ctx->memidx, MO_UB);
> +{
> +TCGv val = tcg_temp_new();
> +TCGv msb = tcg_const_i32(0x80);
> +tcg_gen_atomic_fetch_or_i32(val, REG(B11_8), msb,
> +ctx->memidx, MO_UB);
> +tcg_temp_free(msb);
>  tcg_gen_setcondi_i32(TCG_COND_EQ, cpu_sr_t, val, 0);
> - tcg_gen_ori_i32(val, val, 0x80);
> -tcg_gen_qemu_st_i32(val, addr, ctx->memidx, MO_UB);
> - tcg_temp_free(val);
> - tcg_temp_free(addr);
> - }
> +tcg_temp_free(val);
> +}
>   return;
>  case 0xf00d: /* fsts FPUL,FRn - FPSCR: Nothing */
>   CHECK_FPU_ENABLED
>

 For 2.8?
>>>
>>> Is it possible?
>>
>> Well, tas_test "runs without error with this change", I suppose it fails
>> before?  

I need to add:

It doesn't fail before. The problem is only with qemu-sh4.

Laurent

Re: [Qemu-devel] [PATCH 0/2] tests: A few check-qom-proplist fixes

[Markus Armbruster]

Eduardo Habkost  writes:

> A few fixes on check-qom-proplist that will ensure we test both
> class properties and object properties, and catch errors when
> registering properties in test code.

Series
Reviewed-by: Markus Armbruster 

Excessively long delay considering how simple these patches are.  My
apologies.

Re: [Qemu-devel] [PATCH v2] target-sh4: add atomic tas

[Richard Henderson]

On 11/03/2016 10:21 AM, Laurent Vivier wrote:

Le 03/11/2016 à 17:18, Paolo Bonzini a écrit :

Well, tas_test "runs without error with this change", I suppose it fails
before?  In other words, is this patch enough to run multithreaded sh4
programs with qemu-user?


It should,:the problem was reported by Adrian (cc:) while compiling ghc
in qemu-sh4, but I have just tested the functionality with the softmmu
version, not the atomicity.

Adrian, could you test this patch?


It's a start, but sh4 has an interesting scheme to implement atomic sequences 
via special values in the stack pointer.  E.g. xchg is


mova1f, r0
mov sp, r1
mov #(0f-1f), sp
0:  mov.l   mem, out
mov.l   in, mem
1:  mov r1, sp

which is only atomic if you've got a UP kernel and have code in your interrupt 
entry point that recognizes the small negative value in SP to reset the PC as 
necessary.


For SH4A, there are proper load-locked/store-condition insns, but prior to that 
TAS was the only truly atomic insn.



r~

Re: [Qemu-devel] [PATCH v4 2/3] nvdimm acpi: introduce _FIT

[Igor Mammedov]

On Fri, 4 Nov 2016 00:17:00 +0800
Xiao Guangrong  wrote:

> 
> 
> On 11/04/2016 12:13 AM, Igor Mammedov wrote:
> > On Thu, 3 Nov 2016 22:53:43 +0800
> > Xiao Guangrong  wrote:
> >
> >>
> >>
> >> On 11/03/2016 10:49 PM, Igor Mammedov wrote:
> >>> On Thu, 3 Nov 2016 21:02:22 +0800
> >>> Xiao Guangrong  wrote:
> >>>
> 
> 
>  On 11/03/2016 09:00 PM, Igor Mammedov wrote:
> 
> 
> 
> 
> >>> just drop this and describe properly 'len' in spec section
> >>> i.e. len: length of entire returned data (including the
> >>> header)
> >>
> >> Okay, i will change the spec like this:
> >>
> >> QEMU Writes Output Data (based on the offset in the page):
> >> [0x0 - 0x3]: 4 bytes, length of entire returned data
> >> (including the header)
> >>
> >> And drop the length field in Read_Fit return buffer, doc
> >> the fit buffer like this:
> >>
> >> 
> >> +--+++---+
> >> |  Field   | Length | Offset |
> >> Description   |
> >> +--+++---+
> > you need to add length here, otherwise this table is not correct
> 
>  Ah, so i am confused.
> 
>  struct NvdimmFuncReadFITOut definition is based on the layout of
>  Read_FI output. You suggested to drop the length filed in
>  NvdimmFuncReadFITOut but keep it in the layout, it is not
>  consistent.
> 
>  I missed something?
> >>>
> >>> +struct NvdimmFuncReadFITOut {
> >>> +/* the size of buffer filled by QEMU. */
> >>> +uint32_t len;
> >>> +uint32_t func_ret_status; /* return status code. */
> >>> +uint8_t fit[0]; /* the FIT data. */
> >>> +} QEMU_PACKED;
> >>>
> >>> 
> >>> | field   | len | off | desc...
> >>> 
> >>> | length  |  4  |  0  | 
> >>> 
> >>> | status  |  4  |  4  | 
> >>> 
> >>> | fit data| 
> >>>
> >>> i.e. you were forgetting to add length in spec so offsets were
> >>> wrong even for described fields.
> >>
> >>
> >> We can not do this.
> >>
> >> @len is used by QEMU emulation to count the size of the buffer that
> >> _DSM should return. It's only used in NVDIMM_COMMON_DSM method
> >> which is shared by the DSM method from VM and Read_Fit.
> > spec describes buffer layout independently from AML that uses it,
> > so it should describe whole data structure.
> >
> > Then it's upto guest how to read this data, it could be QEMU
> > generated AML (as it's here) or some other driver or even BIOS.
> 
> However, what we are talking about is Read_FIT method, so this is
> the layout of Read_FIT output rather than all memory in the dsm page.
> 
> Actually, in the spec we already have documented the common len field:
> 
> QEMU Writes Output Data (based on the offset in the page):
> [0x0 - 0x3]: 4 bytes, the length of result
> [0x4 - 0xFFF]: 4092 bytes, the DSM result filled by QEMU
> 
> Also, i really do not hope to use this field to count the buffer size
> returned by Read_FIT, we'd try the best to reuse existing DSM method
> (NVDIMM_COMMON_DSM), i.e, treat Read_FIT as normal DSM method.
buffer layout describes interface between QEMU and firmware (AML)
and it should describe it completely every time to avoid confusion.

See for example ACPI spec, NFIT table, SRAT table, ...
all table descriptions start with complete header.

If you skip length it rises question how much fit data are there,
meaning interface description isn't complete.

if you want to describe AML there you can do it after interface
description saying that common NCAL method extracts status and fit
data form dsm page and returns that as buffer object, but it's AML
impl. specific. I could write an alternative AML code that would deal
with dms page in its own way as long as I would know what write/read at
what offset.


> 
> 
> 
> 
> 

Re: [Qemu-devel] [QEMU PATCH v10 3/3] tests/migration: Add test for QTAILQ migration

[Jianjun Duan]

On 11/03/2016 05:22 AM, Halil Pasic wrote:
> 
> 
> On 11/02/2016 11:47 AM, Juan Quintela wrote:
>> Jianjun Duan  wrote:
>>> Add a test for QTAILQ migration to tests/test-vmstate.c.
>>>
>>> Signed-off-by: Jianjun Duan 
>>
>> Reviewed-by: Juan Quintela 
>>
> 
> Empty QTAILQ seems to be broken. Have written a small
> test to prove my point. It May even make sense to have such
> a test in the test-suite (some prettyfication might be
> necessary though).
> 
It is working as intended.

The current design is to append the qtailq from source to the
corresponding one on target. It works well for the task in hard
such as migrating ccs_list and pending_events for DRC objects.

I suspect in most cases the qtailqs on target are empty. If not,
appending to them is a good choice. Clearing them is tricky since
each queue probably require a specialized routine to clean. If they
are not empty there are must be good reasons for that.

Thanks,
Jianjun

> Halil
> 
> ---8<-
> 
> From 4323c308c5f56ed86eb0a5bb6027bca4617ecc8c Mon Sep 17 00:00:00 2001
> From: Halil Pasic 
> Date: Thu, 3 Nov 2016 13:07:05 +0100
> Subject: [PATCH] tests/test-vmstate.c: add test empty qtailq
> 
> Add test for empty qtailq.
> 
> Signed-off-by: Halil Pasic 
> 
> --
> 
> For fixup.
> ---
>  tests/test-vmstate.c |   28 
>  1 files changed, 28 insertions(+), 0 deletions(-)
> 
> diff --git a/tests/test-vmstate.c b/tests/test-vmstate.c
> index a992408..789f07a 100644
> --- a/tests/test-vmstate.c
> +++ b/tests/test-vmstate.c
> @@ -126,6 +126,14 @@ static int load_vmstate_one(const VMStateDescription 
> *desc, void *obj,
>  return ret;
>  }
> 
> +static void load_vmstate_one_obj(const VMStateDescription *vmsd, void *obj,
> +int version_id)
> +{
> +QEMUFile *fload = open_test_file(false);
> +
> +SUCCESS(vmstate_load_state(fload, vmsd, obj, version_id));
> +qemu_fclose(fload);
> +}
> 
>  static int load_vmstate(const VMStateDescription *desc,
>  void *obj, void *obj_clone,
> @@ -633,6 +641,25 @@ static void test_load_q(void)
>  qemu_fclose(fload);
>  }
> 
> +
> +static void test_sl_empty_q(void)
> +{
> +TestQtailq obj_q = {
> +.i16 = -512,
> +.i32 = 7,
> +};
> +TestQtailq tgt = {.q = {.tqh_first = (void *)1}};
> +
> +QTAILQ_INIT(_q.q);
> +
> +save_vmstate(_q, _q);
> +load_vmstate_one_obj(_q, , 1);
> +g_assert_cmpint(tgt.i16, ==, obj_q.i16);
> +g_assert_cmpint(tgt.i32, ==, obj_q.i32);
> +g_assert_cmpint(QTAILQ_EMPTY(&(tgt.q)),!=, false);
> + 
> +}
> +
>  int main(int argc, char **argv)
>  {
>  temp_fd = mkstemp(temp_file);
> @@ -649,6 +676,7 @@ int main(int argc, char **argv)
>  g_test_add_func("/vmstate/field_exists/save/skip", test_save_skip);
>  g_test_add_func("/vmstate/qtailq/save/saveq", test_save_q);
>  g_test_add_func("/vmstate/qtailq/load/loadq", test_load_q);
> +g_test_add_func("/vmstate/qtailq/empty", test_sl_empty_q);
>  g_test_run();
> 
>  close(temp_fd);
> 

Re: [Qemu-devel] [PATCH v2 3/3] target-m68k: add cas/cas2 ops

[Richard Henderson]

On 11/02/2016 03:15 PM, Laurent Vivier wrote:

+if (c1 != l1) {
+env->cc_n = l1;
+env->cc_v = c1;
+} else {
+env->cc_n = l2;
+env->cc_v = c2;
+}
+env->cc_op = CC_OP_CMPL;
+env->dregs[Dc1] = deposit32(env->dregs[Dc1], 0, 16, l1);
+env->dregs[Dc2] = deposit32(env->dregs[Dc2], 0, 16, l2);


CC_OP_CMPW for cas2w.


+void HELPER(cas2l)(CPUM68KState *env, uint32_t regs, uint32_t a1, uint32_t a2)
+{
+uint32_t Dc1 = extract32(regs, 9, 3);
+uint32_t Dc2 = extract32(regs, 6, 3);
+uint32_t Du1 = extract32(regs, 3, 3);
+uint32_t Du2 = extract32(regs, 0, 3);
+uint32_t c1 = env->dregs[Dc1];
+uint32_t c2 = env->dregs[Dc2];
+uint32_t u1 = env->dregs[Du1];
+uint32_t u2 = env->dregs[Du2];
+uint32_t l1, l2;
+uint64_t c, u, l;
+uintptr_t ra = GETPC();
+#ifndef CONFIG_USER_ONLY
+int mmu_idx = cpu_mmu_index(env, 0);
+TCGMemOpIdx oi;
+#endif
+
+if (parallel_cpus) {
+/* We're executing in a parallel context -- must be atomic.  */
+if ((a1 & 7) == 0 && a2 == a1 + 4) {
+c = deposit64(c2, 32, 32, c1);
+u = deposit64(u2, 32, 32, u1);
+#ifdef CONFIG_USER_ONLY
+uint64_t *ha1 = g2h(a1);
+l = atomic_cmpxchg__nocheck(ha1, c, u);
+#else
+oi = make_memop_idx(MO_BEQ, mmu_idx);
+l = helper_atomic_cmpxchgq_be_mmu(env, a1, c, u, oi, ra);
+#endif


We do need a check here for CONFIG_ATOMIC64.  If that's not set, the host 
doesn't have 64-bit cmpxchg.  Probably arrange this as


if (parallel_cpus) {
#ifdef CONFIG_ATOMIC64
if ((a1 & 7) ...) {
   ...
} else if ((a2 & 7) ...) {
   ...
} else
#endif
{
/* Tell the main loop we need to serialize this insn.  */
cpu_loop_exit_atomic(ENV_GET_CPU(env), ra);
}
} else {
   ...
}

Which is pretty ugly, but the best we can do without re-organizing the helpers.


+   regs = tcg_const_i32(REG(ext2, 6) |
+(REG(ext1, 6) << 3) |
+(REG(ext2, 0) << 6) |
+(REG(ext1, 0) << 9));
+   gen_helper_cas2w(cpu_env, regs, addr1, addr2);
+   tcg_temp_free(regs);


Need

  /* Note that cas2w also assigned to env->cc_op.  */
  s->cc_op = CC_OP_CMPW;
  s->cc_op_synced = 1;


+DISAS_INSN(cas2l)
+{

...

+   regs = tcg_const_i32(REG(ext2, 6) |
+(REG(ext1, 6) << 3) |
+(REG(ext2, 0) << 6) |
+(REG(ext1, 0) << 9));
+   gen_helper_cas2w(cpu_env, regs, addr1, addr2);


cas2l.

Also need to set cc_op to CC_OP_CMPL, as above.


r~

Re: [Qemu-devel] [PATCH] hw/pci: disable pci-bridge's shpc by default

[Marcel Apfelbaum]

On 11/03/2016 05:24 PM, Laine Stump wrote:

On 11/03/2016 07:08 AM, Marcel Apfelbaum wrote:

On 11/02/2016 06:01 PM, Laine Stump wrote:

On 11/02/2016 11:16 AM, Marcel Apfelbaum wrote:

The shpc component is optional while  ACPI hotplug is used
for hot-plugging PCI devices into a PCI-PCI bridge.
Disabling the shpc by default will make slot 0 usable at boot time
and not only for hot-plug, without loosing any functionality.
Older machines will have shpc enabled for compatibility reasons.


From libvirt's POV, changing qemu's default for shpc in qemu only
serves to confuse; since we have no way to discover what is the
default setting (especially problematic since it is different for
different machinetype versions), we now either need to keep a table of
what the setting is for various machinetypes, or we need to just
always set it whether it's on or off.

So for us, the simplest thing is for the default to remain the same
(since for so long we haven't set this option as we didn't even know
what it did, or indeed even that it existed), and for libvirt
to learn about the option, make its default in the config files "on",
but begin setting it to "off" in all newly defined machines.



Hi Laine,

Please see my reply to Michael regarding the "why", anyway, can't
libvirt deal with it?
Start use the shpc parameter no matter what QEMU does by default while
keeping it 'on' for machines < 2.8.
(this is only a suggestion, of course...)



We greatly dislike coding in behavior changes to libvirt based on 
machinetype/version or qemu version since a version number is a very broad and 
inaccurate sword. The best behavior changes are those
that can be discovered by querying something specific to that behavior, which 
can't be done in this case, as there is no way to query *anything* specific to 
a machinetype without instantiating a
virtual machine of that machinetype (if it's even queryable then, which is 
anyway irrelevant to libvirt, since our queries to qemu are done with -machine 
none).



+Eduardo

Hi Eduardo,
Can your work can help on this specific case?



libvirt can of course deal with such a change in default behavior by qemu, but 
the way it will deal with it is by removing all assumptions about the default 
of shpc from the code, and replacing those
assumptions with explicit setting of the option in the xml and on the qemu 
command line all the time.

In the end, libvirt wouldn't gain anything from this change in qemu's default 
behavior - it would be more work than just adding a setting for shpc to libvirt 
and having *libvirt* change its default
setting (which has the same ultimate results). Of course that's a relatively 
selfish (libvirt-centric) view, and I suppose direct users of the qemu 
commandline might get some benefit from changing the
qemu default, but anyone concerned enough about the exact commandline contents 
to be running qemu directly would probably also not have a problem adding an 
option to the commandline if they really
wanted a 1/32 increase in the number of available slots.



As I explained to Michael, this is not only about the extra slot, but
more about the usage model.
I do understand the libvirt point of view, on the other hand why
should we use a default QEMU value that the majority of users don't need?

Thanks,
Marcel






Thanks,
Marcel


(The change to the default for virtio devices' disable-legacy
depending on where the device was connected could also have been
problematic, except that the change in default value of that has no
direct consequences on the rest of the configuration - libvirt will
still use the controllers in exactly the same way, and the same
commandlines for the same machinetype/versions will still result in
identical behavior (so it's not possible for libvirt to know whether
or not IO is enabled for the virtio device, nor to know what is the
device's . In the case of pci-bridge's shpc though, the whole
point of disabling shpc is to make another slot available for libvirt
to use for a device, so presumably the config *beyond the pci-bridge
device* needs to change as a result of this change in default
setting, so libvirt needs to know the setting and behave differently.)



Signed-off-by: Marcel Apfelbaum 
---
 hw/pci-bridge/pci_bridge_dev.c | 2 +-
 include/hw/compat.h| 4 
 2 files changed, 5 insertions(+), 1 deletion(-)

diff --git a/hw/pci-bridge/pci_bridge_dev.c
b/hw/pci-bridge/pci_bridge_dev.c
index 5dbd933..647ad80 100644
--- a/hw/pci-bridge/pci_bridge_dev.c
+++ b/hw/pci-bridge/pci_bridge_dev.c
@@ -163,7 +163,7 @@ static Property pci_bridge_dev_properties[] = {
 DEFINE_PROP_ON_OFF_AUTO(PCI_BRIDGE_DEV_PROP_MSI, PCIBridgeDev, msi,
 ON_OFF_AUTO_AUTO),
 DEFINE_PROP_BIT(PCI_BRIDGE_DEV_PROP_SHPC, PCIBridgeDev, flags,
-PCI_BRIDGE_DEV_F_SHPC_REQ, true),
+PCI_BRIDGE_DEV_F_SHPC_REQ, false),
 DEFINE_PROP_END_OF_LIST(),
 };

diff --git 

Re: [Qemu-devel] [PATCH v2 3/3] tests: Enhance qobject output to cover partial visit

[Markus Armbruster]

Eric Blake  writes:

> Add a test that proves (at least when run under valgrind) that
> we are correctly handling allocated memory even when a visit
> is aborted in the middle for whatever other reason.
>
> See commit f24582d "qapi: fix double free in
> qmp_output_visitor_cleanup()" for a fix that was lacking
> testsuite exposure prior to this patch.
>
> Signed-off-by: Eric Blake 
>
> ---
> v2: rebase (and hence retitle), add list & alternate coverage
> ---
>  tests/test-qobject-output-visitor.c | 39 
> +
>  1 file changed, 39 insertions(+)
>
> diff --git a/tests/test-qobject-output-visitor.c 
> b/tests/test-qobject-output-visitor.c
> index c2e0f43..fdae0d5 100644
> --- a/tests/test-qobject-output-visitor.c
> +++ b/tests/test-qobject-output-visitor.c
> @@ -254,6 +254,43 @@ static void 
> test_visitor_out_struct_errors(TestOutputVisitorData *data,
>  }
>
>
> +static void test_visitor_out_partial_visit(TestOutputVisitorData *data,
> +   const void *unused)
> +{
> +/* Various checks that a mid-visit abort doesn't leak or double-free. */
> +const char *str = "hi";
> +Error *err = NULL;
> +UserDefAlternate uda = { .type = QTYPE_QDICT,
> + .u.udfu = { .integer = 1,
> + .string = (char *) "bye",
> + .enum1 = -1 } };
> +UserDefAlternate *obj = 
> +
> +/* Abort within a nested object with no data members */
> +visit_start_struct(data->ov, NULL, NULL, 0, _abort);
> +visit_start_struct(data->ov, "nested", NULL, 0, _abort);
> +visitor_reset(data);
> +
> +/* Abort in the middle of a list of strings */
> +visit_start_list(data->ov, "list", NULL, 0, _abort);
> +visit_type_str(data->ov, NULL, (char **), _abort);
> +visit_type_str(data->ov, NULL, (char **), _abort);
> +visitor_reset(data);
> +
> +/* Abort in the middle of an alternate. Alternates can't be
> + * virtually visited, so we get to inline the first half of
> + * visit_type_UserDefAlternate(). */
> +visit_start_alternate(data->ov, NULL, (GenericAlternate **),
> +  sizeof(uda), false, _abort);
> +visit_start_struct(data->ov, NULL, NULL, 0, _abort);
> +visit_type_UserDefUnionBase_members(data->ov,
> +(UserDefUnionBase *),
> +);
> +error_free_or_abort();

Why does this fail?

> +visitor_reset(data);
> +}
> +
> +
>  static void test_visitor_out_list(TestOutputVisitorData *data,
>const void *unused)
>  {
> @@ -817,6 +854,8 @@ int main(int argc, char **argv)
>  _visitor_data, 
> test_visitor_out_struct_nested);
>  output_visitor_test_add("/visitor/output/struct-errors",
>  _visitor_data, 
> test_visitor_out_struct_errors);
> +output_visitor_test_add("/visitor/output/partial-visit",
> +_visitor_data, 
> test_visitor_out_partial_visit);
>  output_visitor_test_add("/visitor/output/list",
>  _visitor_data, test_visitor_out_list);
>  output_visitor_test_add("/visitor/output/any",

Re: [Qemu-devel] [PATCH v2 01/11] qapi: add qapi2texi script

[Marc-André Lureau]

Hi

On Thu, Nov 3, 2016 at 5:46 PM Markus Armbruster  wrote:

> Marc-André Lureau  writes:
>
> > If we want to have a very strict grammar, there is even more work needed
> to
> > cleanup the documentation. I don't fancy doing that work, it gives only
> low
> > benefits.
>
> Since I have pretty specific ideas on how I want this part of your much
> larger work done, I think it's only fair if I give it a try myself:
> propose a grammar, create a parser to show it works, clean up existing
> comments to comply with it.
>
>
Thank you, I gladly accept the help :) However, could you wait until the
next iteration? I am trying to improve the parsing and simplifying a bit
the code (although probably not reaching your goal)

-- 
Marc-André Lureau

Re: [Qemu-devel] [PATCH v4 2/3] nvdimm acpi: introduce _FIT

[Xiao Guangrong]

On 11/04/2016 12:13 AM, Igor Mammedov wrote:

On Thu, 3 Nov 2016 22:53:43 +0800
Xiao Guangrong  wrote:




On 11/03/2016 10:49 PM, Igor Mammedov wrote:

On Thu, 3 Nov 2016 21:02:22 +0800
Xiao Guangrong  wrote:




On 11/03/2016 09:00 PM, Igor Mammedov wrote:





just drop this and describe properly 'len' in spec section
i.e. len: length of entire returned data (including the header)


Okay, i will change the spec like this:

QEMU Writes Output Data (based on the offset in the page):
[0x0 - 0x3]: 4 bytes, length of entire returned data
(including the header)

And drop the length field in Read_Fit return buffer, doc
the fit buffer like this:

+--+++---+
|  Field   | Length | Offset |
Description   |
+--+++---+

you need to add length here, otherwise this table is not correct


Ah, so i am confused.

struct NvdimmFuncReadFITOut definition is based on the layout of
Read_FI output. You suggested to drop the length filed in
NvdimmFuncReadFITOut but keep it in the layout, it is not
consistent.

I missed something?


+struct NvdimmFuncReadFITOut {
+/* the size of buffer filled by QEMU. */
+uint32_t len;
+uint32_t func_ret_status; /* return status code. */
+uint8_t fit[0]; /* the FIT data. */
+} QEMU_PACKED;


| field   | len | off | desc...

| length  |  4  |  0  | 

| status  |  4  |  4  | 

| fit data| 

i.e. you were forgetting to add length in spec so offsets were wrong
even for described fields.



We can not do this.

@len is used by QEMU emulation to count the size of the buffer that
_DSM should return. It's only used in NVDIMM_COMMON_DSM method which
is shared by the DSM method from VM and Read_Fit.

spec describes buffer layout independently from AML that uses it,
so it should describe whole data structure.

Then it's upto guest how to read this data, it could be QEMU generated
AML (as it's here) or some other driver or even BIOS.


However, what we are talking about is Read_FIT method, so this is
the layout of Read_FIT output rather than all memory in the dsm page.

Actually, in the spec we already have documented the common len field:

   QEMU Writes Output Data (based on the offset in the page):
   [0x0 - 0x3]: 4 bytes, the length of result
   [0x4 - 0xFFF]: 4092 bytes, the DSM result filled by QEMU

Also, i really do not hope to use this field to count the buffer size
returned by Read_FIT, we'd try the best to reuse existing DSM method
(NVDIMM_COMMON_DSM), i.e, treat Read_FIT as normal DSM method.

Re: [Qemu-devel] [PATCH v2] target-sh4: add atomic tas

[Laurent Vivier]

Le 03/11/2016 à 17:18, Paolo Bonzini a écrit :
> 
> 
> On 03/11/2016 16:35, Laurent Vivier wrote:
>> Le 03/11/2016 à 16:32, Paolo Bonzini a écrit :
>>>
>>>
>>> On 03/11/2016 15:07, Laurent Vivier wrote:
 Implement real atomic tas:

 When (Rn) = 0, 1 -> T
 Otherwise, 0 -> T
 In both cases, 1 -> MSB of (Rn)

 using atomic_fetch_or_i32() and setcondi_i32().

 Tested with image from:
 http://wiki.qemu.org/download/sh-test-0.2.tar.bz2

 This image contains a "tas_test" that runs without
 error with this change.

 Signed-off-by: Laurent Vivier 
 ---
 v2:
 - don't use helper but atomic_fetch_or_i32
   Thank you Paolo!

  target-sh4/translate.c | 19 ---
  1 file changed, 8 insertions(+), 11 deletions(-)

 diff --git a/target-sh4/translate.c b/target-sh4/translate.c
 index c89a147..1b83d59 100644
 --- a/target-sh4/translate.c
 +++ b/target-sh4/translate.c
 @@ -1640,18 +1640,15 @@ static void _decode_opc(DisasContext * ctx)
tcg_gen_shri_i32(REG(B11_8), REG(B11_8), 16);
return;
  case 0x401b:  /* tas.b @Rn */
 -  {
 -  TCGv addr, val;
 -  addr = tcg_temp_local_new();
 -  tcg_gen_mov_i32(addr, REG(B11_8));
 -  val = tcg_temp_local_new();
 -tcg_gen_qemu_ld_i32(val, addr, ctx->memidx, MO_UB);
 +{
 +TCGv val = tcg_temp_new();
 +TCGv msb = tcg_const_i32(0x80);
 +tcg_gen_atomic_fetch_or_i32(val, REG(B11_8), msb,
 +ctx->memidx, MO_UB);
 +tcg_temp_free(msb);
  tcg_gen_setcondi_i32(TCG_COND_EQ, cpu_sr_t, val, 0);
 -  tcg_gen_ori_i32(val, val, 0x80);
 -tcg_gen_qemu_st_i32(val, addr, ctx->memidx, MO_UB);
 -  tcg_temp_free(val);
 -  tcg_temp_free(addr);
 -  }
 +tcg_temp_free(val);
 +}
return;
  case 0xf00d: /* fsts FPUL,FRn - FPSCR: Nothing */
CHECK_FPU_ENABLED

>>>
>>> For 2.8?
>>
>> Is it possible?
> 
> Well, tas_test "runs without error with this change", I suppose it fails
> before?  In other words, is this patch enough to run multithreaded sh4
> programs with qemu-user?

It should,:the problem was reported by Adrian (cc:) while compiling ghc
in qemu-sh4, but I have just tested the functionality with the softmmu
version, not the atomicity.

Adrian, could you test this patch?

Thanks,
Laurent

Re: [Qemu-devel] [PATCH v2 2/3] target-m68k: implement 680x0 movem

[Richard Henderson]

On 11/02/2016 03:15 PM, Laurent Vivier wrote:

680x0 movem can load/store words and long words
and can use more addressing modes.
Coldfire can only use long words with (Ax) and (d16,Ax)
addressing modes.

Signed-off-by: Laurent Vivier 
---
 target-m68k/translate.c | 96 -
 1 file changed, 79 insertions(+), 17 deletions(-)


Reviewed-by: Richard Henderson 


r~

Re: [Qemu-devel] [PATCH v2] target-sh4: add atomic tas

[Paolo Bonzini]

On 03/11/2016 16:35, Laurent Vivier wrote:
> Le 03/11/2016 à 16:32, Paolo Bonzini a écrit :
>>
>>
>> On 03/11/2016 15:07, Laurent Vivier wrote:
>>> Implement real atomic tas:
>>>
>>> When (Rn) = 0, 1 -> T
>>> Otherwise, 0 -> T
>>> In both cases, 1 -> MSB of (Rn)
>>>
>>> using atomic_fetch_or_i32() and setcondi_i32().
>>>
>>> Tested with image from:
>>> http://wiki.qemu.org/download/sh-test-0.2.tar.bz2
>>>
>>> This image contains a "tas_test" that runs without
>>> error with this change.
>>>
>>> Signed-off-by: Laurent Vivier 
>>> ---
>>> v2:
>>> - don't use helper but atomic_fetch_or_i32
>>>   Thank you Paolo!
>>>
>>>  target-sh4/translate.c | 19 ---
>>>  1 file changed, 8 insertions(+), 11 deletions(-)
>>>
>>> diff --git a/target-sh4/translate.c b/target-sh4/translate.c
>>> index c89a147..1b83d59 100644
>>> --- a/target-sh4/translate.c
>>> +++ b/target-sh4/translate.c
>>> @@ -1640,18 +1640,15 @@ static void _decode_opc(DisasContext * ctx)
>>> tcg_gen_shri_i32(REG(B11_8), REG(B11_8), 16);
>>> return;
>>>  case 0x401b:   /* tas.b @Rn */
>>> -   {
>>> -   TCGv addr, val;
>>> -   addr = tcg_temp_local_new();
>>> -   tcg_gen_mov_i32(addr, REG(B11_8));
>>> -   val = tcg_temp_local_new();
>>> -tcg_gen_qemu_ld_i32(val, addr, ctx->memidx, MO_UB);
>>> +{
>>> +TCGv val = tcg_temp_new();
>>> +TCGv msb = tcg_const_i32(0x80);
>>> +tcg_gen_atomic_fetch_or_i32(val, REG(B11_8), msb,
>>> +ctx->memidx, MO_UB);
>>> +tcg_temp_free(msb);
>>>  tcg_gen_setcondi_i32(TCG_COND_EQ, cpu_sr_t, val, 0);
>>> -   tcg_gen_ori_i32(val, val, 0x80);
>>> -tcg_gen_qemu_st_i32(val, addr, ctx->memidx, MO_UB);
>>> -   tcg_temp_free(val);
>>> -   tcg_temp_free(addr);
>>> -   }
>>> +tcg_temp_free(val);
>>> +}
>>> return;
>>>  case 0xf00d: /* fsts FPUL,FRn - FPSCR: Nothing */
>>> CHECK_FPU_ENABLED
>>>
>>
>> For 2.8?
> 
> Is it possible?

Well, tas_test "runs without error with this change", I suppose it fails
before?  In other words, is this patch enough to run multithreaded sh4
programs with qemu-user?

Paolo

Re: [Qemu-devel] [PATCH v2 1/3] target-m68k: add abcd/sbcd/nbcd

[Richard Henderson]

On 11/02/2016 03:15 PM, Laurent Vivier wrote:

+static void bcd_sub(TCGv dest, TCGv src)
+{
+TCGv t0, t1, t2;
+
+/*  dest10 = dest10 - src10 - X
+ * = bcd_add(dest + 1 - X, 0xf99 - src)
+ */
+
+/* t0 = 0xfff - src */
+
+t0 = tcg_temp_new();
+tcg_gen_neg_i32(t0, src);
+tcg_gen_addi_i32(t0, t0, 0xfff);


tcg_gen_subfi_i32(t0, 0xfff, src);

And how did we get 0xfff from 0xf99?  Also, see below...


+
+/* t1 = t0 + dest + 1 - X*/
+
+t1 = tcg_temp_new();
+tcg_gen_add_i32(t1, t0, dest);
+tcg_gen_addi_i32(t1, t1, 1);
+tcg_gen_sub_i32(t1, t1, QREG_CC_X);
+
+/* t2 = t0 ^ dest ^ 1 ^ X */
+
+t2 = tcg_temp_new();
+tcg_gen_xor_i32(t2, t0, dest);
+tcg_gen_xori_i32(t2, t2, 1);
+tcg_gen_xor_i32(t2, t2, QREG_CC_X);


Since you only care about bits 0x110, you can drop the ^ 1 ^ X; they won't 
affect the result.  (Similarly wrt bcd_add, dropping ^ X).



+/* t2 = ~t0 & 0x110 */
+
+tcg_gen_not_i32(t2, t0);
+tcg_gen_andi_i32(t2, t2, 0x110);
+
+/* t0 = (t2 >> 2) | (t2 >> 3) */
+
+tcg_gen_shri_i32(t0, t2, 2);
+tcg_gen_shri_i32(t2, t2, 3);
+tcg_gen_or_i32(t0, t0, t2);


For the benefit of hosts that have 8-bit immediate AND insns (e.g. arm32), it 
would be better to rearrange this a little:


t2 = t0 >> 3;
t3 = ~t2 & 0x22;
t4 = t3 + t3;
t5 = t3 + t4;

(Similarly in bcd_add).


+
+/* return t1 - t0 */
+
+tcg_gen_sub_i32(dest, t1, t0);
+}
+
+static void bcd_flags(TCGv val)
+{
+tcg_gen_andi_i32(QREG_CC_C, val, 0x0ff);
+tcg_gen_or_i32(QREG_CC_Z, QREG_CC_Z, QREG_CC_C);
+
+tcg_gen_movi_i32(QREG_CC_X, 0);
+tcg_gen_andi_i32(val, val, 0xf00);
+tcg_gen_setcond_i32(TCG_COND_NE, QREG_CC_C, val, QREG_CC_X);


Surely 0x100 is the carry.  I don't see how you could produce 0x2xx from 
addition.  For subtraction, I think we got things other than 0/1 in the third 
nibble simply because we started with 0xf99 instead of 0x199.



r~

Re: [Qemu-devel] [PATCH v4 2/3] nvdimm acpi: introduce _FIT

[Igor Mammedov]

On Thu, 3 Nov 2016 22:53:43 +0800
Xiao Guangrong  wrote:

> 
> 
> On 11/03/2016 10:49 PM, Igor Mammedov wrote:
> > On Thu, 3 Nov 2016 21:02:22 +0800
> > Xiao Guangrong  wrote:
> >
> >>
> >>
> >> On 11/03/2016 09:00 PM, Igor Mammedov wrote:
> >>
> >>
> >>
> >>
> > just drop this and describe properly 'len' in spec section
> > i.e. len: length of entire returned data (including the header)
> 
>  Okay, i will change the spec like this:
> 
>  QEMU Writes Output Data (based on the offset in the page):
>  [0x0 - 0x3]: 4 bytes, length of entire returned data
>  (including the header)
> 
>  And drop the length field in Read_Fit return buffer, doc
>  the fit buffer like this:
> 
>  
>  +--+++---+
>  |  Field   | Length | Offset |
>  Description   |
>  +--+++---+
> >>> you need to add length here, otherwise this table is not correct
> >>
> >> Ah, so i am confused.
> >>
> >> struct NvdimmFuncReadFITOut definition is based on the layout of
> >> Read_FI output. You suggested to drop the length filed in
> >> NvdimmFuncReadFITOut but keep it in the layout, it is not
> >> consistent.
> >>
> >> I missed something?
> >
> > +struct NvdimmFuncReadFITOut {
> > +/* the size of buffer filled by QEMU. */
> > +uint32_t len;
> > +uint32_t func_ret_status; /* return status code. */
> > +uint8_t fit[0]; /* the FIT data. */
> > +} QEMU_PACKED;
> >
> > 
> > | field   | len | off | desc...
> > 
> > | length  |  4  |  0  | 
> > 
> > | status  |  4  |  4  | 
> > 
> > | fit data| 
> >
> > i.e. you were forgetting to add length in spec so offsets were wrong
> > even for described fields.
> 
> 
> We can not do this.
> 
> @len is used by QEMU emulation to count the size of the buffer that
> _DSM should return. It's only used in NVDIMM_COMMON_DSM method which
> is shared by the DSM method from VM and Read_Fit.
spec describes buffer layout independently from AML that uses it,
so it should describe whole data structure.

Then it's upto guest how to read this data, it could be QEMU generated
AML (as it's here) or some other driver or even BIOS.

Re: [Qemu-devel] [PULL 0/2] M68k for 2.8 patches

[Stefan Hajnoczi]

On Wed, Nov 02, 2016 at 06:26:20PM +0100, Laurent Vivier wrote:
> Le 02/11/2016 à 18:23, Stefan Hajnoczi a écrit :
> > On Wed, Nov 2, 2016 at 5:17 PM, Stefan Hajnoczi  wrote:
> >> On Wed, Nov 2, 2016 at 5:12 PM, Laurent Vivier  wrote:
> >>> Le 02/11/2016 à 18:07, Stefan Hajnoczi a écrit :
>  On Mon, Oct 31, 2016 at 10:50:29AM +0100, Laurent Vivier wrote:
> > The following changes since commit 
> > 5b2ecabaeabc17f032197246c4846b9ba95ba8a6:
> >
> >   Merge remote-tracking branch 'remotes/kraxel/tags/pull-ui-20161028-1' 
> > into staging (2016-10-28 17:59:04 +0100)
> >
> > are available in the git repository at:
> >
> >   g...@github.com:vivier/qemu-m68k.git tags/m68k-for-2.8-pull-request
> 
>  This URI is not publicly accessible.  Some tools will fail to apply your
>  pull request because of this.
> 
>  Please adjust your .gitconfig:
> 
>  [remote "origin"]
>  url = git://github.com/vivier/qemu.git
>  pushurl = g...@github.com:vivier/qemu.git
> >>>
> >>> Thank you Stefan.
> >>>
> >>> I'm using your tool "git-publish", is there a way to detect this problem
> >>> automatically?
> >>
> >> Right now git-publish doesn't check the generated URI.  In some use
> >> cases it's reasonable to use an SSH URI so adding an error or even
> >> warning to git-publish isn't ideal.
> >>
> >> I am modifying the patches tool (https://github.com/stefanha/patches)
> >> to automatically translate GitHub URIs since they are so prevalent...
> >> This will allow me to apply pull requests that have GitHub SSH URIs.
> > 
> > On second thought, even that isn't a general solution.  If people are
> > collaborating on private GitHub repos then translating URIs to HTTPS
> > is not correct either.
> > 
> > Instead of trying to do magic I'll ask pull request submitters to fix
> > their .gitconfig.
> 
> Perhaps you can also update git-publish README.rst?

Good idea, I'll add info on how to set up separate url and pushurl
fields.

Stefan


signature.asc
Description: PGP signature

Re: [Qemu-devel] [PATCH v2] target-sh4: add atomic tas

[Paolo Bonzini]

On 03/11/2016 15:07, Laurent Vivier wrote:
> Implement real atomic tas:
> 
> When (Rn) = 0, 1 -> T
> Otherwise, 0 -> T
> In both cases, 1 -> MSB of (Rn)
> 
> using atomic_fetch_or_i32() and setcondi_i32().
> 
> Tested with image from:
> http://wiki.qemu.org/download/sh-test-0.2.tar.bz2
> 
> This image contains a "tas_test" that runs without
> error with this change.
> 
> Signed-off-by: Laurent Vivier 
> ---
> v2:
> - don't use helper but atomic_fetch_or_i32
>   Thank you Paolo!
> 
>  target-sh4/translate.c | 19 ---
>  1 file changed, 8 insertions(+), 11 deletions(-)
> 
> diff --git a/target-sh4/translate.c b/target-sh4/translate.c
> index c89a147..1b83d59 100644
> --- a/target-sh4/translate.c
> +++ b/target-sh4/translate.c
> @@ -1640,18 +1640,15 @@ static void _decode_opc(DisasContext * ctx)
>   tcg_gen_shri_i32(REG(B11_8), REG(B11_8), 16);
>   return;
>  case 0x401b: /* tas.b @Rn */
> - {
> - TCGv addr, val;
> - addr = tcg_temp_local_new();
> - tcg_gen_mov_i32(addr, REG(B11_8));
> - val = tcg_temp_local_new();
> -tcg_gen_qemu_ld_i32(val, addr, ctx->memidx, MO_UB);
> +{
> +TCGv val = tcg_temp_new();
> +TCGv msb = tcg_const_i32(0x80);
> +tcg_gen_atomic_fetch_or_i32(val, REG(B11_8), msb,
> +ctx->memidx, MO_UB);
> +tcg_temp_free(msb);
>  tcg_gen_setcondi_i32(TCG_COND_EQ, cpu_sr_t, val, 0);
> - tcg_gen_ori_i32(val, val, 0x80);
> -tcg_gen_qemu_st_i32(val, addr, ctx->memidx, MO_UB);
> - tcg_temp_free(val);
> - tcg_temp_free(addr);
> - }
> +tcg_temp_free(val);
> +}
>   return;
>  case 0xf00d: /* fsts FPUL,FRn - FPSCR: Nothing */
>   CHECK_FPU_ENABLED
> 

For 2.8?

Paolo

Re: [Qemu-devel] [PATCH v2] target-sh4: add atomic tas

[Laurent Vivier]

Le 03/11/2016 à 16:32, Paolo Bonzini a écrit :
> 
> 
> On 03/11/2016 15:07, Laurent Vivier wrote:
>> Implement real atomic tas:
>>
>> When (Rn) = 0, 1 -> T
>> Otherwise, 0 -> T
>> In both cases, 1 -> MSB of (Rn)
>>
>> using atomic_fetch_or_i32() and setcondi_i32().
>>
>> Tested with image from:
>> http://wiki.qemu.org/download/sh-test-0.2.tar.bz2
>>
>> This image contains a "tas_test" that runs without
>> error with this change.
>>
>> Signed-off-by: Laurent Vivier 
>> ---
>> v2:
>> - don't use helper but atomic_fetch_or_i32
>>   Thank you Paolo!
>>
>>  target-sh4/translate.c | 19 ---
>>  1 file changed, 8 insertions(+), 11 deletions(-)
>>
>> diff --git a/target-sh4/translate.c b/target-sh4/translate.c
>> index c89a147..1b83d59 100644
>> --- a/target-sh4/translate.c
>> +++ b/target-sh4/translate.c
>> @@ -1640,18 +1640,15 @@ static void _decode_opc(DisasContext * ctx)
>>  tcg_gen_shri_i32(REG(B11_8), REG(B11_8), 16);
>>  return;
>>  case 0x401b:/* tas.b @Rn */
>> -{
>> -TCGv addr, val;
>> -addr = tcg_temp_local_new();
>> -tcg_gen_mov_i32(addr, REG(B11_8));
>> -val = tcg_temp_local_new();
>> -tcg_gen_qemu_ld_i32(val, addr, ctx->memidx, MO_UB);
>> +{
>> +TCGv val = tcg_temp_new();
>> +TCGv msb = tcg_const_i32(0x80);
>> +tcg_gen_atomic_fetch_or_i32(val, REG(B11_8), msb,
>> +ctx->memidx, MO_UB);
>> +tcg_temp_free(msb);
>>  tcg_gen_setcondi_i32(TCG_COND_EQ, cpu_sr_t, val, 0);
>> -tcg_gen_ori_i32(val, val, 0x80);
>> -tcg_gen_qemu_st_i32(val, addr, ctx->memidx, MO_UB);
>> -tcg_temp_free(val);
>> -tcg_temp_free(addr);
>> -}
>> +tcg_temp_free(val);
>> +}
>>  return;
>>  case 0xf00d: /* fsts FPUL,FRn - FPSCR: Nothing */
>>  CHECK_FPU_ENABLED
>>
> 
> For 2.8?

Is it possible?

Otherwise, can it be stored on a maintainer branch waiting the end of
the freeze?

Thanks,
Laurent

Re: [Qemu-devel] [kvm-unit-tests PATCHv7 1/3] arm: Add PMU test

[cov]

On 2016-11-03 09:04, Andrew Jones wrote:

On Thu, Nov 03, 2016 at 08:29:57AM -0600, c...@codeaurora.org wrote:

On 2016-11-03 04:14, Andrew Jones wrote:
> On Wed, Nov 02, 2016 at 05:22:15PM -0500, Wei Huang wrote:
>
> Missing
>  From: Christopher Covington 
>
>
> > Beginning with a simple sanity check of the control register, add
> > a unit test for the ARM Performance Monitors Unit (PMU).
> >
> > Signed-off-by: Christopher Covington 
>
> Missing
>   Signed-off-by: Wei Huang 
>
> > ---
> >  arm/Makefile.common |  3 +-
> >  arm/pmu.c   | 82
> > +
> >  arm/unittests.cfg   | 20 +
> >  3 files changed, 104 insertions(+), 1 deletion(-)
> >  create mode 100644 arm/pmu.c
> >
> > diff --git a/arm/Makefile.common b/arm/Makefile.common
> > index ccb554d..f98f422 100644
> > --- a/arm/Makefile.common
> > +++ b/arm/Makefile.common
> > @@ -11,7 +11,8 @@ endif
> >
> >  tests-common = \
> >   $(TEST_DIR)/selftest.flat \
> > - $(TEST_DIR)/spinlock-test.flat
> > + $(TEST_DIR)/spinlock-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..42d0ee1
> > --- /dev/null
> > +++ b/arm/pmu.c
> > @@ -0,0 +1,82 @@
> > +/*
> > + * Test the ARM Performance Monitors Unit (PMU).
> > + *
> > + * Copyright 2015 The Linux Foundation. All rights reserved.
>
> Is the Linux Foundation correct for codeaurora patches? Should bump
> the year to 2016.
>
> > + *
> > + * 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"
> > +
> > +#if defined(__arm__)
> > +static inline uint32_t get_pmcr(void)
> > +{
> > + uint32_t ret;
> > +
> > + asm volatile("mrc p15, 0, %0, c9, c12, 0" : "=r" (ret));
> > + return ret;
> > +}
> > +#elif defined(__aarch64__)
> > +static inline uint32_t get_pmcr(void)
> > +{
> > + uint32_t ret;
> > +
> > + asm volatile("mrs %0, pmcr_el0" : "=r" (ret));
> > + return ret;
> > +}
> > +#endif
> > +
> > +struct pmu_data {
> > + union {
> > + uint32_t pmcr_el0;
> > + struct {
> > + uint32_t enable:1;
> > + uint32_t event_counter_reset:1;
> > + uint32_t cycle_counter_reset:1;
> > + uint32_t cycle_counter_clock_divider:1;
> > + uint32_t event_counter_export:1;
> > + uint32_t cycle_counter_disable_when_prohibited:1;
> > + uint32_t cycle_counter_long:1;
> > + uint32_t reserved:4;
> > + uint32_t counters:5;
> > + uint32_t identification_code:8;
> > + uint32_t implementer:8;
> > + };
> > + };
> > +};
>
> I know I already reviewed/agreed to this bitfield, but I'm having second
> thoughts. I think I'd prefer a bunch of defined shifts like the kernel
> uses.
>
> > +
> > +/*
> > + * 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 2015, QEMU TCG mode doesn't
> > implement
>
> s/2015/2016/   how time flies...
>
> > + * 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)
> > +{
> > + struct pmu_data pmu;
> > +
> > + pmu.pmcr_el0 = get_pmcr();
> > +
> > + printf("PMU implementer: %c\n", pmu.implementer);
> > + printf("Identification code: 0x%x\n", pmu.identification_code);
> > + printf("Event counters:  %d\n", pmu.counters);
> > +
> > + return pmu.implementer != 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 3f6fa45..b647b69 100644
> > --- a/arm/unittests.cfg
> > +++ b/arm/unittests.cfg
> > @@ -54,3 +54,23 @@ file = selftest.flat
> >  smp = $MAX_SMP
> >  extra_params = -append 'smp'
> >  groups = selftest
> > +
> > +# Test PMU support (KVM)
> > +[pmu-kvm]
> > +file = pmu.flat
> > +groups = pmu
> > +accel = kvm
>
> No need to 

Re: [Qemu-devel] [PATCH] hw/pci: disable pci-bridge's shpc by default

[Laine Stump]

On 11/03/2016 07:08 AM, Marcel Apfelbaum wrote:

On 11/02/2016 06:01 PM, Laine Stump wrote:

On 11/02/2016 11:16 AM, Marcel Apfelbaum wrote:

The shpc component is optional while  ACPI hotplug is used
for hot-plugging PCI devices into a PCI-PCI bridge.
Disabling the shpc by default will make slot 0 usable at boot time
and not only for hot-plug, without loosing any functionality.
Older machines will have shpc enabled for compatibility reasons.


From libvirt's POV, changing qemu's default for shpc in qemu only
serves to confuse; since we have no way to discover what is the
default setting (especially problematic since it is different for
different machinetype versions), we now either need to keep a table of
what the setting is for various machinetypes, or we need to just
always set it whether it's on or off.

So for us, the simplest thing is for the default to remain the same
(since for so long we haven't set this option as we didn't even know
what it did, or indeed even that it existed), and for libvirt
to learn about the option, make its default in the config files "on",
but begin setting it to "off" in all newly defined machines.



Hi Laine,

Please see my reply to Michael regarding the "why", anyway, can't
libvirt deal with it?
Start use the shpc parameter no matter what QEMU does by default while
keeping it 'on' for machines < 2.8.
(this is only a suggestion, of course...)



We greatly dislike coding in behavior changes to libvirt based on 
machinetype/version or qemu version since a version number is a very 
broad and inaccurate sword. The best behavior changes are those that can 
be discovered by querying something specific to that behavior, which 
can't be done in this case, as there is no way to query *anything* 
specific to a machinetype without instantiating a virtual machine of 
that machinetype (if it's even queryable then, which is anyway 
irrelevant to libvirt, since our queries to qemu are done with -machine 
none).


libvirt can of course deal with such a change in default behavior by 
qemu, but the way it will deal with it is by removing all assumptions 
about the default of shpc from the code, and replacing those assumptions 
with explicit setting of the option in the xml and on the qemu command 
line all the time.


In the end, libvirt wouldn't gain anything from this change in qemu's 
default behavior - it would be more work than just adding a setting for 
shpc to libvirt and having *libvirt* change its default setting (which 
has the same ultimate results). Of course that's a relatively selfish 
(libvirt-centric) view, and I suppose direct users of the qemu 
commandline might get some benefit from changing the qemu default, but 
anyone concerned enough about the exact commandline contents to be 
running qemu directly would probably also not have a problem adding an 
option to the commandline if they really wanted a 1/32 increase in the 
number of available slots.






Thanks,
Marcel


(The change to the default for virtio devices' disable-legacy
depending on where the device was connected could also have been
problematic, except that the change in default value of that has no
direct consequences on the rest of the configuration - libvirt will
still use the controllers in exactly the same way, and the same
commandlines for the same machinetype/versions will still result in
identical behavior (so it's not possible for libvirt to know whether
or not IO is enabled for the virtio device, nor to know what is the
device's . In the case of pci-bridge's shpc though, the whole
point of disabling shpc is to make another slot available for libvirt
to use for a device, so presumably the config *beyond the pci-bridge
device* needs to change as a result of this change in default
setting, so libvirt needs to know the setting and behave differently.)



Signed-off-by: Marcel Apfelbaum 
---
 hw/pci-bridge/pci_bridge_dev.c | 2 +-
 include/hw/compat.h| 4 
 2 files changed, 5 insertions(+), 1 deletion(-)

diff --git a/hw/pci-bridge/pci_bridge_dev.c
b/hw/pci-bridge/pci_bridge_dev.c
index 5dbd933..647ad80 100644
--- a/hw/pci-bridge/pci_bridge_dev.c
+++ b/hw/pci-bridge/pci_bridge_dev.c
@@ -163,7 +163,7 @@ static Property pci_bridge_dev_properties[] = {
 DEFINE_PROP_ON_OFF_AUTO(PCI_BRIDGE_DEV_PROP_MSI, PCIBridgeDev, msi,
 ON_OFF_AUTO_AUTO),
 DEFINE_PROP_BIT(PCI_BRIDGE_DEV_PROP_SHPC, PCIBridgeDev, flags,
-PCI_BRIDGE_DEV_F_SHPC_REQ, true),
+PCI_BRIDGE_DEV_F_SHPC_REQ, false),
 DEFINE_PROP_END_OF_LIST(),
 };

diff --git a/include/hw/compat.h b/include/hw/compat.h
index 0f06e11..388b7ec 100644
--- a/include/hw/compat.h
+++ b/include/hw/compat.h
@@ -18,6 +18,10 @@
 .driver   = "intel-iommu",\
 .property = "x-buggy-eim",\
 .value= "true",\
+},{\
+.driver   = "pci-bridge",\
+.property = "shpc",\
+.value= "on",\
 },

 #define 

Re: [Qemu-devel] [kvm-unit-tests PATCHv7 1/3] arm: Add PMU test

[Andrew Jones]

On Thu, Nov 03, 2016 at 08:29:57AM -0600, c...@codeaurora.org wrote:
> On 2016-11-03 04:14, Andrew Jones wrote:
> > On Wed, Nov 02, 2016 at 05:22:15PM -0500, Wei Huang wrote:
> > 
> > Missing
> >  From: Christopher Covington 
> > 
> > 
> > > Beginning with a simple sanity check of the control register, add
> > > a unit test for the ARM Performance Monitors Unit (PMU).
> > > 
> > > Signed-off-by: Christopher Covington 
> > 
> > Missing
> >   Signed-off-by: Wei Huang 
> > 
> > > ---
> > >  arm/Makefile.common |  3 +-
> > >  arm/pmu.c   | 82
> > > +
> > >  arm/unittests.cfg   | 20 +
> > >  3 files changed, 104 insertions(+), 1 deletion(-)
> > >  create mode 100644 arm/pmu.c
> > > 
> > > diff --git a/arm/Makefile.common b/arm/Makefile.common
> > > index ccb554d..f98f422 100644
> > > --- a/arm/Makefile.common
> > > +++ b/arm/Makefile.common
> > > @@ -11,7 +11,8 @@ endif
> > > 
> > >  tests-common = \
> > >   $(TEST_DIR)/selftest.flat \
> > > - $(TEST_DIR)/spinlock-test.flat
> > > + $(TEST_DIR)/spinlock-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..42d0ee1
> > > --- /dev/null
> > > +++ b/arm/pmu.c
> > > @@ -0,0 +1,82 @@
> > > +/*
> > > + * Test the ARM Performance Monitors Unit (PMU).
> > > + *
> > > + * Copyright 2015 The Linux Foundation. All rights reserved.
> > 
> > Is the Linux Foundation correct for codeaurora patches? Should bump
> > the year to 2016.
> > 
> > > + *
> > > + * 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"
> > > +
> > > +#if defined(__arm__)
> > > +static inline uint32_t get_pmcr(void)
> > > +{
> > > + uint32_t ret;
> > > +
> > > + asm volatile("mrc p15, 0, %0, c9, c12, 0" : "=r" (ret));
> > > + return ret;
> > > +}
> > > +#elif defined(__aarch64__)
> > > +static inline uint32_t get_pmcr(void)
> > > +{
> > > + uint32_t ret;
> > > +
> > > + asm volatile("mrs %0, pmcr_el0" : "=r" (ret));
> > > + return ret;
> > > +}
> > > +#endif
> > > +
> > > +struct pmu_data {
> > > + union {
> > > + uint32_t pmcr_el0;
> > > + struct {
> > > + uint32_t enable:1;
> > > + uint32_t event_counter_reset:1;
> > > + uint32_t cycle_counter_reset:1;
> > > + uint32_t cycle_counter_clock_divider:1;
> > > + uint32_t event_counter_export:1;
> > > + uint32_t cycle_counter_disable_when_prohibited:1;
> > > + uint32_t cycle_counter_long:1;
> > > + uint32_t reserved:4;
> > > + uint32_t counters:5;
> > > + uint32_t identification_code:8;
> > > + uint32_t implementer:8;
> > > + };
> > > + };
> > > +};
> > 
> > I know I already reviewed/agreed to this bitfield, but I'm having second
> > thoughts. I think I'd prefer a bunch of defined shifts like the kernel
> > uses.
> > 
> > > +
> > > +/*
> > > + * 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 2015, QEMU TCG mode doesn't
> > > implement
> > 
> > s/2015/2016/   how time flies...
> > 
> > > + * 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)
> > > +{
> > > + struct pmu_data pmu;
> > > +
> > > + pmu.pmcr_el0 = get_pmcr();
> > > +
> > > + printf("PMU implementer: %c\n", pmu.implementer);
> > > + printf("Identification code: 0x%x\n", pmu.identification_code);
> > > + printf("Event counters:  %d\n", pmu.counters);
> > > +
> > > + return pmu.implementer != 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 3f6fa45..b647b69 100644
> > > --- a/arm/unittests.cfg
> > > +++ b/arm/unittests.cfg
> > > @@ -54,3 +54,23 @@ file = selftest.flat
> > >  smp = $MAX_SMP
> > >  extra_params = -append 'smp'
> > > 

Re: [Qemu-devel] [PATCH v2] scripts: qmp: Introduce vcpu pinning helper script

[Maxime Coquelin]

Hi Peter,

On 10/04/2016 01:22 PM, Maxime Coquelin wrote:

This python script calls 'query-cpus' QMP command to retrieve
vCPUs thread IDs.
Thread IDs are then used by taskset to pin vCPUs to physical
CPUs passed in command line.

In case more vCPUs are present than the number of CPUs assigned
in command line, multiple vCPUs get pinned to physical CPUs.

If multiple vCPUs share a same thread ID (e.g. with TCG), the
thread ID is pinned a single time.

Signed-off-by: Maxime Coquelin 
---
Changes since RFC:
==
 - If vCPUs share a same TID, don't pin them multiple times (peterx)

 scripts/qmp/qmp-vcpu-pin | 45 +
 1 file changed, 45 insertions(+)
 create mode 100755 scripts/qmp/qmp-vcpu-pin


I added your proposed change not to pin same TID multiple time,
does it look good to you?

Thanks,
Maxime

Re: [Qemu-devel] [PATCH v4 2/3] nvdimm acpi: introduce _FIT

[Xiao Guangrong]

On 11/03/2016 10:49 PM, Igor Mammedov wrote:

On Thu, 3 Nov 2016 21:02:22 +0800
Xiao Guangrong  wrote:




On 11/03/2016 09:00 PM, Igor Mammedov wrote:





just drop this and describe properly 'len' in spec section
i.e. len: length of entire returned data (including the header)


Okay, i will change the spec like this:

QEMU Writes Output Data (based on the offset in the page):
[0x0 - 0x3]: 4 bytes, length of entire returned data
(including the header)

And drop the length field in Read_Fit return buffer, doc
the fit buffer like this:

+--+++---+
|  Field   | Length | Offset |
Description   |
+--+++---+

you need to add length here, otherwise this table is not correct


Ah, so i am confused.

struct NvdimmFuncReadFITOut definition is based on the layout of
Read_FI output. You suggested to drop the length filed in
NvdimmFuncReadFITOut but keep it in the layout, it is not consistent.

I missed something?


+struct NvdimmFuncReadFITOut {
+/* the size of buffer filled by QEMU. */
+uint32_t len;
+uint32_t func_ret_status; /* return status code. */
+uint8_t fit[0]; /* the FIT data. */
+} QEMU_PACKED;


| field   | len | off | desc...

| length  |  4  |  0  | 

| status  |  4  |  4  | 

| fit data| 

i.e. you were forgetting to add length in spec so offsets were wrong
even for described fields.



We can not do this.

@len is used by QEMU emulation to count the size of the buffer that
_DSM should return. It's only used in NVDIMM_COMMON_DSM method which
is shared by the DSM method from VM and Read_Fit.

Re: [Qemu-devel] [PATCH v2] target-sh4: add atomic tas

[Richard Henderson]

On 11/03/2016 08:07 AM, Laurent Vivier wrote:

Implement real atomic tas:

When (Rn) = 0, 1 -> T
Otherwise, 0 -> T
In both cases, 1 -> MSB of (Rn)

using atomic_fetch_or_i32() and setcondi_i32().

Tested with image from:
http://wiki.qemu.org/download/sh-test-0.2.tar.bz2

This image contains a "tas_test" that runs without
error with this change.

Signed-off-by: Laurent Vivier 
---
v2:
- don't use helper but atomic_fetch_or_i32
  Thank yo


Reviewed-by: Richard Henderson 


r~

Re: [Qemu-devel] [PATCH v4 2/3] nvdimm acpi: introduce _FIT

[Igor Mammedov]

On Thu, 3 Nov 2016 21:02:22 +0800
Xiao Guangrong  wrote:

> 
> 
> On 11/03/2016 09:00 PM, Igor Mammedov wrote:
> 
> 
> 
> 
> >>> just drop this and describe properly 'len' in spec section
> >>> i.e. len: length of entire returned data (including the header)
> >>
> >> Okay, i will change the spec like this:
> >>
> >> QEMU Writes Output Data (based on the offset in the page):
> >> [0x0 - 0x3]: 4 bytes, length of entire returned data
> >> (including the header)
> >>
> >> And drop the length field in Read_Fit return buffer, doc
> >> the fit buffer like this:
> >>
> >> 
> >> +--+++---+
> >> |  Field   | Length | Offset |
> >> Description   |
> >> +--+++---+
> > you need to add length here, otherwise this table is not correct
> 
> Ah, so i am confused.
> 
> struct NvdimmFuncReadFITOut definition is based on the layout of
> Read_FI output. You suggested to drop the length filed in
> NvdimmFuncReadFITOut but keep it in the layout, it is not consistent.
> 
> I missed something?

+struct NvdimmFuncReadFITOut {
+/* the size of buffer filled by QEMU. */
+uint32_t len;
+uint32_t func_ret_status; /* return status code. */
+uint8_t fit[0]; /* the FIT data. */
+} QEMU_PACKED;


| field   | len | off | desc...

| length  |  4  |  0  | 

| status  |  4  |  4  | 

| fit data| 

i.e. you were forgetting to add length in spec so offsets were wrong
even for described fields.

> 
> >
> >
> >> |  ||| return status
> >> codes   | |  ||| 0x100
> >> - error caused by NFIT update while | | status   |   4|   0
> >> | read by _FIT wasn't completed, other  | |  |
> >> || codes follow Chapter 3 in DSM Spec Rev1   |
> >> +--+++---+
> >> | fit data | Varies |   8| FIT data, The remaining size in
> >> the   | |  ||| returned buffer is used
> >> by FIT|
> >> +--+++---+
> >>
> >>
> >>
>  +}
>  +
>  +static void nvdimm_dsm_reserved_root(AcpiNVDIMMState *state,
>  NvdimmDsmIn *in,
>  + hwaddr dsm_mem_addr)
> >>> function name doesn't make any sense to me
> >>
> >> As i explained above, handle 0x1 indicates the reserved _DSM
> >> method is called on the root device...
> >>
> >> It makes sense now? :)
> > function name should reflect what it does,
> > i.e use verb and I see only nouns here.
> 
> Got it, will change it to: nvdimm_handle_reserved_root_method().
> 

Re: [Qemu-devel] [kvm-unit-tests PATCHv7 1/3] arm: Add PMU test

[cov]

On 2016-11-03 04:14, Andrew Jones wrote:

On Wed, Nov 02, 2016 at 05:22:15PM -0500, Wei Huang wrote:

Missing
 From: Christopher Covington 



Beginning with a simple sanity check of the control register, add
a unit test for the ARM Performance Monitors Unit (PMU).

Signed-off-by: Christopher Covington 


Missing
  Signed-off-by: Wei Huang 


---
 arm/Makefile.common |  3 +-
 arm/pmu.c   | 82 
+

 arm/unittests.cfg   | 20 +
 3 files changed, 104 insertions(+), 1 deletion(-)
 create mode 100644 arm/pmu.c

diff --git a/arm/Makefile.common b/arm/Makefile.common
index ccb554d..f98f422 100644
--- a/arm/Makefile.common
+++ b/arm/Makefile.common
@@ -11,7 +11,8 @@ endif

 tests-common = \
$(TEST_DIR)/selftest.flat \
-   $(TEST_DIR)/spinlock-test.flat
+   $(TEST_DIR)/spinlock-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..42d0ee1
--- /dev/null
+++ b/arm/pmu.c
@@ -0,0 +1,82 @@
+/*
+ * Test the ARM Performance Monitors Unit (PMU).
+ *
+ * Copyright 2015 The Linux Foundation. All rights reserved.


Is the Linux Foundation correct for codeaurora patches? Should bump
the year to 2016.


+ *
+ * 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"
+
+#if defined(__arm__)
+static inline uint32_t get_pmcr(void)
+{
+   uint32_t ret;
+
+   asm volatile("mrc p15, 0, %0, c9, c12, 0" : "=r" (ret));
+   return ret;
+}
+#elif defined(__aarch64__)
+static inline uint32_t get_pmcr(void)
+{
+   uint32_t ret;
+
+   asm volatile("mrs %0, pmcr_el0" : "=r" (ret));
+   return ret;
+}
+#endif
+
+struct pmu_data {
+   union {
+   uint32_t pmcr_el0;
+   struct {
+   uint32_t enable:1;
+   uint32_t event_counter_reset:1;
+   uint32_t cycle_counter_reset:1;
+   uint32_t cycle_counter_clock_divider:1;
+   uint32_t event_counter_export:1;
+   uint32_t cycle_counter_disable_when_prohibited:1;
+   uint32_t cycle_counter_long:1;
+   uint32_t reserved:4;
+   uint32_t counters:5;
+   uint32_t identification_code:8;
+   uint32_t implementer:8;
+   };
+   };
+};


I know I already reviewed/agreed to this bitfield, but I'm having 
second
thoughts. I think I'd prefer a bunch of defined shifts like the kernel 
uses.



+
+/*
+ * 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 2015, QEMU TCG mode doesn't 
implement


s/2015/2016/   how time flies...

+ * 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)
+{
+   struct pmu_data pmu;
+
+   pmu.pmcr_el0 = get_pmcr();
+
+   printf("PMU implementer: %c\n", pmu.implementer);
+   printf("Identification code: 0x%x\n", pmu.identification_code);
+   printf("Event counters:  %d\n", pmu.counters);
+
+   return pmu.implementer != 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 3f6fa45..b647b69 100644
--- a/arm/unittests.cfg
+++ b/arm/unittests.cfg
@@ -54,3 +54,23 @@ file = selftest.flat
 smp = $MAX_SMP
 extra_params = -append 'smp'
 groups = selftest
+
+# Test PMU support (KVM)
+[pmu-kvm]
+file = pmu.flat
+groups = pmu
+accel = kvm


No need to specify kvm when it works for both. Both is assumed.
tcg-only or kvm-only tests are exceptions requiring the 'accel'
parameter and a comment explaining why it doesn't work on the
other.


+
+# Test PMU support (TCG) with -icount IPC=1
+[pmu-tcg-icount-1]
+file = pmu.flat
+extra_params = -icount 0 -append '1'
+groups = pmu
+accel = tcg
+
+# Test PMU support (TCG) with -icount IPC=256
+[pmu-tcg-icount-256]
+file = pmu.flat
+extra_params = -icount 8 -append '256'
+groups = pmu
+accel = tcg


Why are these entries added now. These tests aren't yet implemented.


What makes you say they aren't 

Re: [Qemu-devel] [kvm-unit-tests PATCHv7 2/3] arm: pmu: Check cycle count increases

[cov]

On 2016-11-03 04:35, Andrew Jones wrote:


+/*
+ * Ensure that the cycle counter progresses between back-to-back 
reads.

+ */
+static bool check_cycles_increase(void)
+{
+   struct pmu_data pmu = {{0}};
+
+   enable_counter(ARMV8_PMU_CYCLE_IDX);
+   set_pmccfiltr(0); /* count cycles in EL0, EL1, but not EL2 */
+
+   pmu.enable = 1;
+   set_pmcr(pmu.pmcr_el0);
+
+   for (int i = 0; i < NR_SAMPLES; i++) {
+   unsigned long a, b;
+
+   a = get_pmccntr();
+   b = get_pmccntr();
+
+   if (a >= b) {
+   printf("Read %ld then %ld.\n", a, b);
+   return false;
+   }
+   }
+
+   pmu.enable = 0;
+   set_pmcr(pmu.pmcr_el0);
+
+   return true;
+}
+
 int main(void)
 {
report_prefix_push("pmu");

report("Control register", check_pmcr());
+	report("Monotonically increasing cycle count", 
check_cycles_increase());


return report_summary();
 }


What happens with this test running on tcg? Do we just fail? Does it
explode? Is there a register we can probe and when it indicates things
won't work we can invoke a report_skip?


A monotonically increasing value (but not any attempt at approximating 
actual cycle
values) in cycle counter is pretty much the only piece of the PMU it's 
had implemented
for the past while. We'll have to check whether TCG can handle the 
filter and enable set

registers, but if it doesn't yet, that's something we can improve :).

Thanks,
Cov

[Qemu-devel] [PATCH v2] target-sh4: add atomic tas

[Laurent Vivier]

Implement real atomic tas:

When (Rn) = 0, 1 -> T
Otherwise, 0 -> T
In both cases, 1 -> MSB of (Rn)

using atomic_fetch_or_i32() and setcondi_i32().

Tested with image from:
http://wiki.qemu.org/download/sh-test-0.2.tar.bz2

This image contains a "tas_test" that runs without
error with this change.

Signed-off-by: Laurent Vivier 
---
v2:
- don't use helper but atomic_fetch_or_i32
  Thank you Paolo!

 target-sh4/translate.c | 19 ---
 1 file changed, 8 insertions(+), 11 deletions(-)

diff --git a/target-sh4/translate.c b/target-sh4/translate.c
index c89a147..1b83d59 100644
--- a/target-sh4/translate.c
+++ b/target-sh4/translate.c
@@ -1640,18 +1640,15 @@ static void _decode_opc(DisasContext * ctx)
tcg_gen_shri_i32(REG(B11_8), REG(B11_8), 16);
return;
 case 0x401b:   /* tas.b @Rn */
-   {
-   TCGv addr, val;
-   addr = tcg_temp_local_new();
-   tcg_gen_mov_i32(addr, REG(B11_8));
-   val = tcg_temp_local_new();
-tcg_gen_qemu_ld_i32(val, addr, ctx->memidx, MO_UB);
+{
+TCGv val = tcg_temp_new();
+TCGv msb = tcg_const_i32(0x80);
+tcg_gen_atomic_fetch_or_i32(val, REG(B11_8), msb,
+ctx->memidx, MO_UB);
+tcg_temp_free(msb);
 tcg_gen_setcondi_i32(TCG_COND_EQ, cpu_sr_t, val, 0);
-   tcg_gen_ori_i32(val, val, 0x80);
-tcg_gen_qemu_st_i32(val, addr, ctx->memidx, MO_UB);
-   tcg_temp_free(val);
-   tcg_temp_free(addr);
-   }
+tcg_temp_free(val);
+}
return;
 case 0xf00d: /* fsts FPUL,FRn - FPSCR: Nothing */
CHECK_FPU_ENABLED
-- 
2.7.4