Re: [Qemu-devel] [PATCH 0/4] Implements the Windows Hypervisor Platform accelerator

[Stefan Weil]

Am 18.01.2018 um 00:41 schrieb Justin Terry (VM) via Qemu-devel:
> Hey Paolo,
[...]
> 4. This will be supported on Windows 10 hosts (I don’t have the insider build 
> number yet) and it will require an Intel processor with VT-x and Unrestricted 
> Guest support. Will update the qemu-devel list once we have an insider build 
> that is public that has the platform bits.

Is it restricted to professional and enterprise versions of Windows
(that would be bad), or will it run on any Windows 10 host?

Stefan

Re: [Qemu-devel] [PATCH v2 2/3] s390x/kvm: Handle bpb feature

[Thomas Huth]

On 17.01.2018 22:12, David Hildenbrand wrote:
> On 17.01.2018 20:37, Christian Borntraeger wrote:
>> We need to handle the bpb control on reset and migration. Normally
>> stfle.82 is transparent (and the normal guest part works without
>> hypervisor activity). To prevent any issues we require full
>> host kernel support for this feature.
>>
>> Signed-off-by: Christian Borntraeger 
>> ---
>>  target/s390x/cpu.c  |  1 +
>>  target/s390x/cpu.h  |  1 +
>>  target/s390x/cpu_features.c |  1 +
>>  target/s390x/cpu_features_def.h |  1 +
>>  target/s390x/gen-features.c |  1 +
>>  target/s390x/kvm.c  | 14 ++
>>  target/s390x/machine.c  | 17 +
>>  7 files changed, 36 insertions(+)
>>
>> diff --git a/target/s390x/cpu.c b/target/s390x/cpu.c
>> index ae3cee9..1577b2c 100644
>> --- a/target/s390x/cpu.c
>> +++ b/target/s390x/cpu.c
>> @@ -89,6 +89,7 @@ static void s390_cpu_reset(CPUState *s)
>>  CPUS390XState *env = >env;
>>  
>>  env->pfault_token = -1UL;
>> +env->bpbc = 0;
> 
> As this is effectively only 1 bit, I wonder if we should also make that
> clear in QEMU
> 
> bool bpbc, VMSTATE_BOOL ...
> 
> Apart from that, looks sane.

I had the same thought when reading the patch ... apart from that, also
looks good to me.

 Thomas

Re: [Qemu-devel] [Qemu-ppc] [QEMU-PPC] [PATCH V3 6/6] target/ppc/spapr: Add H-Call H_GET_CPU_CHARACTERISTICS

[David Gibson]

On Thu, Jan 18, 2018 at 04:44:28PM +1100, Alexey Kardashevskiy wrote:
> On 18/01/18 16:20, David Gibson wrote:
> > On Mon, Jan 15, 2018 at 05:32:35PM +1100, Suraj Jitindar Singh wrote:
> >> The new H-Call H_GET_CPU_CHARACTERISTICS is used by the guest to query
> >> behaviours and available characteristics of the cpu.
> >>
> >> Implement the handler for this new H-Call which formulates its response
> >> based on the setting of the spapr_caps cap-cfpc, cap-sbbc and cap-ibs.
> >>
> >> Signed-off-by: Suraj Jitindar Singh 
> >> ---
> >>  hw/ppc/spapr_hcall.c   | 66 
> >> ++
> >>  include/hw/ppc/spapr.h |  1 +
> >>  2 files changed, 67 insertions(+)
> >>
> >> diff --git a/hw/ppc/spapr_hcall.c b/hw/ppc/spapr_hcall.c
> >> index 51eba52e86..a693d3b852 100644
> >> --- a/hw/ppc/spapr_hcall.c
> >> +++ b/hw/ppc/spapr_hcall.c
> >> @@ -1654,6 +1654,69 @@ static target_ulong 
> >> h_client_architecture_support(PowerPCCPU *cpu,
> >>  return H_SUCCESS;
> >>  }
> >>  
> >> +static target_ulong h_get_cpu_characteristics(PowerPCCPU *cpu,
> >> +  sPAPRMachineState *spapr,
> >> +  target_ulong opcode,
> >> +  target_ulong *args)
> >> +{
> >> +uint64_t characteristics = H_CPU_CHAR_HON_BRANCH_HINTS &
> >> + ~H_CPU_CHAR_THR_RECONF_TRIG;
> >> +uint64_t behaviour = H_CPU_BEHAV_FAVOUR_SECURITY;
> >> +uint8_t safe_cache = spapr_get_cap(spapr, SPAPR_CAP_CFPC);
> >> +uint8_t safe_bounds_check = spapr_get_cap(spapr, SPAPR_CAP_SBBC);
> >> +uint8_t safe_indirect_branch = spapr_get_cap(spapr, SPAPR_CAP_IBS);
> >> +
> >> +switch (safe_cache) {
> >> +case SPAPR_CAP_WORKAROUND:
> >> +characteristics |= H_CPU_CHAR_L1D_FLUSH_ORI30;
> >> +characteristics |= H_CPU_CHAR_L1D_FLUSH_TRIG2;
> >> +characteristics |= H_CPU_CHAR_L1D_THREAD_PRIV;
> >> +behaviour |= H_CPU_BEHAV_L1D_FLUSH_PR;
> >> +break;
> >> +case SPAPR_CAP_FIXED:
> >> +break;
> >> +default: /* broken */
> >> +if (safe_cache != SPAPR_CAP_BROKEN) {
> > 
> > I think you just assert() for this.  The only way these could get a
> > different value is if there's a bug elsewhere.
> 
> 
> Why not return H_HARDWARE or other error?

Because what's the guest supposed to do with it.  This is an internal
qemu problem, so it should be dealt with via an internal qemu
mechanism.

-- 
David Gibson| I'll have my music baroque, and my code
david AT gibson.dropbear.id.au  | minimalist, thank you.  NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson


signature.asc
Description: PGP signature

Re: [Qemu-devel] [PATCH qemu 0/3] spapr/iommu: Enable in-kernel TCE acceleration via VFIO KVM device

[David Gibson]

On Tue, Jan 16, 2018 at 01:46:14PM -0700, Alex Williamson wrote:
> On Mon, 15 Jan 2018 15:12:07 +1100
> Alexey Kardashevskiy  wrote:
> 
> > On 03/01/18 04:51, Paolo Bonzini wrote:
> > > On 02/01/2018 06:28, Alexey Kardashevskiy wrote:  
> > >> This is my current queue of the in-kernel TCE acceleration
> > >> enablement.
> > >>
> > >> Changes since 
> > >> https://lists.gnu.org/archive/html/qemu-devel/2017-12/msg01918.html :
> > >> * 3 patches instead of one, one per maintainership area;
> > >> * added memory_region_iommu_get_attr();
> > >> * removed set_attr() as there is no use for it now;
> > >> * folded the chunk in vfio_listener_region_add() under
> > >> VFIO_SPAPR_TCE_v2_IOMMU branch as the acceleration is only
> > >> enabled when DMA memory is preregistered and this is only supported
> > >> by the v2 IOMMU.
> > >>
> > >> This is based on sha1
> > >> ad59cde Cédric Le Goater "target/ppc: more use of the PPC_*() macros".
> > >>
> > >> Please comment. Thanks.
> > >>
> > >>
> > >>
> > >> Alexey Kardashevskiy (3):
> > >>   memory/iommu: Add get_attr()
> > >>   vfio/spapr: Use iommu memory region's get_attr()
> > >>   spapr/iommu: Enable in-kernel TCE acceleration via VFIO KVM device
> > >>
> > >>  include/exec/memory.h | 22 ++
> > >>  target/ppc/kvm_ppc.h  |  6 ++
> > >>  hw/ppc/spapr_iommu.c  | 19 +++
> > >>  hw/vfio/common.c  | 26 ++
> > >>  memory.c  | 13 +
> > >>  target/ppc/kvm.c  |  7 ++-
> > >>  hw/vfio/trace-events  |  1 +
> > >>  7 files changed, 93 insertions(+), 1 deletion(-)
> > >>  
> > > 
> > > Alex, if this is okay for you, please pick it up yourself.  
> > 
> > Alex, ping?
> 
> Yeah, I'll pick these up.  Paolo, do you want to throw an explicit Ack
> for the first patch?  David, R-b/A-b?  Thanks,

Sorry, I've been so buried in bugs that performance improvements just
haven't made my radar to look at.

From my first look these look workable, though somewhat uglier than
necessary.

-- 
David Gibson| I'll have my music baroque, and my code
david AT gibson.dropbear.id.au  | minimalist, thank you.  NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson


signature.asc
Description: PGP signature

Re: [Qemu-devel] [PATCH v1 1/1] linux-user: Fix webkitgtk hangs on 32-bit x86 target

[Alistair Francis]

On Wed, Jan 17, 2018 at 4:57 PM, Richard Henderson  wrote:
> On 01/17/2018 12:39 PM, Alistair Francis wrote:
>> Since commit "linux-user: Tidy and enforce reserved_va initialization"
>> (18e80c55bb6ec17c05ec0ba717ec83933c2bfc07) the Yocto webkitgtk build
>> hangs when cross compiling for 32-bit x86 on a 64-bit x86 machine using
>> musl.
>>
>> To fix the issue reduce the MAX_RESERVED_VA macro to be a closer match
>> to what it was before the problematic commit.
>>
>> Signed-off-by: Alistair Francis 
>> ---
>
> I don't like this at all.  You don't say why this hangs.
> What is the actual host, x86_64 or i686?

The host is x86_64 and the guest is i686. I'm not sure why it hangs,
I'll dig through and get the actual command Yocto is running when it
hangs.

Alistair

>
>
> r~

Re: [Qemu-devel] [Qemu-ppc] [QEMU-PPC] [PATCH V3 6/6] target/ppc/spapr: Add H-Call H_GET_CPU_CHARACTERISTICS

[Alexey Kardashevskiy]

On 18/01/18 16:20, David Gibson wrote:
> On Mon, Jan 15, 2018 at 05:32:35PM +1100, Suraj Jitindar Singh wrote:
>> The new H-Call H_GET_CPU_CHARACTERISTICS is used by the guest to query
>> behaviours and available characteristics of the cpu.
>>
>> Implement the handler for this new H-Call which formulates its response
>> based on the setting of the spapr_caps cap-cfpc, cap-sbbc and cap-ibs.
>>
>> Signed-off-by: Suraj Jitindar Singh 
>> ---
>>  hw/ppc/spapr_hcall.c   | 66 
>> ++
>>  include/hw/ppc/spapr.h |  1 +
>>  2 files changed, 67 insertions(+)
>>
>> diff --git a/hw/ppc/spapr_hcall.c b/hw/ppc/spapr_hcall.c
>> index 51eba52e86..a693d3b852 100644
>> --- a/hw/ppc/spapr_hcall.c
>> +++ b/hw/ppc/spapr_hcall.c
>> @@ -1654,6 +1654,69 @@ static target_ulong 
>> h_client_architecture_support(PowerPCCPU *cpu,
>>  return H_SUCCESS;
>>  }
>>  
>> +static target_ulong h_get_cpu_characteristics(PowerPCCPU *cpu,
>> +  sPAPRMachineState *spapr,
>> +  target_ulong opcode,
>> +  target_ulong *args)
>> +{
>> +uint64_t characteristics = H_CPU_CHAR_HON_BRANCH_HINTS &
>> +   ~H_CPU_CHAR_THR_RECONF_TRIG;
>> +uint64_t behaviour = H_CPU_BEHAV_FAVOUR_SECURITY;
>> +uint8_t safe_cache = spapr_get_cap(spapr, SPAPR_CAP_CFPC);
>> +uint8_t safe_bounds_check = spapr_get_cap(spapr, SPAPR_CAP_SBBC);
>> +uint8_t safe_indirect_branch = spapr_get_cap(spapr, SPAPR_CAP_IBS);
>> +
>> +switch (safe_cache) {
>> +case SPAPR_CAP_WORKAROUND:
>> +characteristics |= H_CPU_CHAR_L1D_FLUSH_ORI30;
>> +characteristics |= H_CPU_CHAR_L1D_FLUSH_TRIG2;
>> +characteristics |= H_CPU_CHAR_L1D_THREAD_PRIV;
>> +behaviour |= H_CPU_BEHAV_L1D_FLUSH_PR;
>> +break;
>> +case SPAPR_CAP_FIXED:
>> +break;
>> +default: /* broken */
>> +if (safe_cache != SPAPR_CAP_BROKEN) {
> 
> I think you just assert() for this.  The only way these could get a
> different value is if there's a bug elsewhere.


Why not return H_HARDWARE or other error?



-- 
Alexey



signature.asc
Description: OpenPGP digital signature

Re: [Qemu-devel] [PATCH RESEND v1 1/2] i386: Add Intel Processor Trace feature support

[Kang, Luwei]

> > > > > > On Mon, Jan 15, 2018 at 12:04:55 -0200, Eduardo Habkost wrote:
> > > > > > > CCing libvirt developers.
> > > > > > ...
> > > > > > > This case is slightly more problematic, however: the new
> > > > > > > feature is actually migratable (under very controlled
> > > > > > > circumstances) because of patch 2/2, but it is not
> > > > > > > migration-safe[1].  This means libvirt shouldn't include it
> > > > > > > in "host-model" expansion (which uses the
> > > > > > > query-cpu-model-expansion QMP command) until we make the feature 
> > > > > > > migration-safe.
> > > > > > >
> > > > > > > For QEMU, this means the feature shouldn't be returned by
> > > > > > > "query-cpu-model-expansion type=static model=max" (but it
> > > > > > > can be returned by "query-cpu-model-expansion type=full 
> > > > > > > model=max").
> > > > > > >
> > > > > > > Jiri, it looks like libvirt uses type=full on
> > > > > > > query-cpu-model-expansion on x86.  It needs to use
> > > > > > > type=static[2], or it will have no way to find out if a
> > > > > > > feature is migration-safe or not.
> > > > > > ...
> > > > > > > [2] It looks like libvirt uses type=full because it wants to get
> > > > > > > all QOM property aliases returned.  In this case, one
> > > > > > > solution for libvirt is to use:
> > > > > > >
> > > > > > > static_expansion = query_cpu_model_expansion(type=static, 
> > > > > > > model)
> > > > > > > all_props = query_cpu_model_expansion(type=full,
> > > > > > > static_expansion)
> > > > > >
> > > > > > This is exactly what libvirt is doing (with model = "host")
> > > > > > ever since query-cpu-model-expansion support was implemented for 
> > > > > > x86.
> > > > >
> > > > > Oh, now I see that the x86 code uses
> > > > > QEMU_MONITOR_CPU_MODEL_EXPANSION_STATIC_FULL and not just 
> > > > > QEMU_MONITOR_CPU_MODEL_EXPANSION_FULL.
> > > Nice!
> > > > >
> > > >
> > > > So, I need to add Intel PT feature in "X86CPUDefinition
> > > > builtin_x86_defs[]" so that we can get this CPUID in specific CPU
> > > > model not only "-cpu host". Is that right?
> > >
> > > The problem is that you won't be able to add intel-pt to any CPU
> > > model unless the feature is made migration-safe (by not calling
> > > kvm_arch_get_supported_cpuid() from cpu_x86_cpuid()).
> >
> > Hi Eduardo,
> > Have some question need you help clear. What is
> > "migration-safe" feature mean? I find all the feature which
> > included in CPU model (builtin_x86_defs[]) will make
> > "xcc->migration_safe = true;" in
> > x86_cpu_cpudef_class_init(). If create a Skylake guest on
> > Skylake HW and live migrate this guest to another machine
> > with old HW(e.g Haswell). Can we think the new feature or
> > cpu model(Skylake guest) which only supported in Skylake HW
> > is safe?
> 
> I mean matching the requirements so we can say the feature is migration-safe, 
> that means exposing the same CPUID data to the
> guest on any host, if the machine-type + command-line is the same.  The data 
> on CPUID[7] is OK (it changes according to the
> command-line options only), but the data exposed on CPUID[14h] on this patch 
> is not migration-safe (it changes depending on the
> host it is running).
> 

Many thanks for your clarification.  I think I have understood. But CPUID[14h] 
is depend on CPUID[7].EBX[bit25] and it would be zero if CPUID[7].EBX[bit25] is 
not set. Or what you concerned is make live migration on two different HW which 
all support Intel PT virtualization but have different  CPUID[14h] result? This 
may need to think about.

Thanks,
Luwei Kang

> 
> >
> > >
> > > What's missing here is to either: (a) make cpu_x86_cpuid() return
> > > host-independent data (it can be constant, or it can be configurable on 
> > > the command-line); or (b) add a mechanism to skip intel-
> pt from "query-cpu-model-expansion type=static".
> >
> > ==> it can be constant:
> > I think it shouldn't be constant because Intel PT virtualization can 
> > only supported in Ice Lake hardware now. Intel PT cpuid info
> would be mask off on old platform.
> > ==> or it can be configurable on the command-line:
> > Because of I didn't add this feature in any CPU model. We only can 
> > enable this feature by "-cpu Skylake-Server,+intel-pt" at
> present.
> 
> Note that I'm talking about CPUID[14h], not CPUID[7].  The CPUID[7] bits are 
> safe because they are set according to the CPU model
> + command-line options only.  The bits on CPUID[14h] change depending on the 
> host and are not migration-safe.  CPUID[7].EBX[bit
> 25] is just the (already configurable) bit that enables the migration-unsafe 
> code for CPUID[14h].
> 
> >
> > What about add a new cpu model name "Icelake" and add PT in this. Is that 
> > would be migration safe?
> 
> It won't, because of the CPUID[14h] code that makes it unsafe to migrate 
> between hosts with different Intel-PT capabilities (i.e.
> different data on CPUID[14h]).
> 
> 
> >
> > Thanks,
> > 

Re: [Qemu-devel] [PATCH qemu] spapr_pci: Alias MMIO windows to PHB address space

[Alexey Kardashevskiy]

On 18/01/18 14:47, Alexey Kardashevskiy wrote:
> At the moment the sPAPR PHB MMIO space does not have an address space
> object as it does not really need one - guest accesses it via virtual
> addresses (and we provide mappings to the CPU space), the device drivers
> in QEMU access MMIO directly (as they own MRs). The only case when
> a driver in QEMU might need an address space (AS) is DMA so we provide one
> with only IOMMUs on it.
> 
> So PHB AS looks like:
> address-space: pci@8002000
>   - (prio 0, i/o): 
> pci@8002000.iommu-root
> - (prio 0, i/o): tce-root-8001
>   0800-08007fff (prio 0, i/o): tce-iommu-8001
> - (prio 0, i/o): tce-root-8000
>   -3fff (prio 0, i/o): tce-iommu-8000
> 0400-0400 (prio 0, i/o): msi
> 
> with no mention of any PCI device, and so does the flatview:
> 
>  FlatView #2
>   AS "pci@8002000", root: pci@8002000.iommu-root
>   AS "nec-usb-xhci", root: bus master container
>   Root memory region: pci@8002000.iommu-root
>-3fff (prio 0, i/o): tce-iommu-8000
> 
> This adds 2 more aliases (for MMIO32 and MMIO64 windows) on PHB AS so
> whatever appears on the bus can be seen in "info mtree [-f]".
> 
> Here are the chunks from "diff" for a QEMU with an emulater XHCI adapter:
> 
>  address-space: pci@8002000
>- (prio 0, i/o): 
> pci@8002000.iommu-root
>  - (prio 0, i/o): tce-root-8001
>0800-08007fff (prio 0, i/o): tce-iommu-8001
>  - (prio 0, i/o): tce-root-8000
>-3fff (prio 0, i/o): tce-iommu-8000
> +8000- (prio 0, i/o): alias 
> pci@8002000.mmio32-alias-pci @pci@8002000.mmio3
> +2-alias -7fff
>  0400-0400 (prio 0, i/o): msi
> +2100-21ff (prio 0, i/o): alias 
> pci@8002000.mmio64-alias-pci @pci@8002000.mmio6
> +4-alias -00ff
> 
> 
>  FlatView #2
>   AS "pci@8002000", root: pci@8002000.iommu-root
>   AS "nec-usb-xhci", root: bus master container
>   Root memory region: pci@8002000.iommu-root
>-3fff (prio 0, i/o): tce-iommu-8000
> +  8000-803f (prio 0, i/o): capabilities
> +  8040-843f (prio 0, i/o): operational
> +  8440-844f (prio 0, i/o): usb3 port #1
> +  8450-845f (prio 0, i/o): usb3 port #2
> +  8460-846f (prio 0, i/o): usb3 port #3
> +  8470-847f (prio 0, i/o): usb3 port #4
> +  8480-848f (prio 0, i/o): usb2 port #1
> +  8490-849f (prio 0, i/o): usb2 port #2
> +  84a0-84af (prio 0, i/o): usb2 port #3
> +  84b0-84bf (prio 0, i/o): usb2 port #4
> +  80001000-8000121f (prio 0, i/o): runtime
> +  80002000-8000281f (prio 0, i/o): doorbell
> +  80003000-800030ff (prio 0, i/o): msix-table
> +  80003800-80003807 (prio 0, i/o): msix-pba
>0400-0400 (prio 0, i/o): msi
>0800-08007fff (prio 0, i/o): tce-iommu-8001
> 
> The major point for this is to help debugging overlapped regions.
> 
> Signed-off-by: Alexey Kardashevskiy 
> ---
> 
> Should not we do this in the common code really?


By this I meant not literally map memory space from pci_register_root_bus()
(as it is 64bit wide, subregions are the windows) but still do something to
see devices on a PCI AS. Now PHB does not have an AS on my x86 setup.


and ...



> Does this look useful at all? I was quite confused when I realized that
> I do not see an AS with DMA windows and MMIO while they co-exist
> on a bus.
> 
> 
> ---
>  include/hw/pci-host/spapr.h |  1 +
>  hw/ppc/spapr_pci.c  | 12 
>  2 files changed, 13 insertions(+)
> 
> diff --git a/include/hw/pci-host/spapr.h b/include/hw/pci-host/spapr.h
> index 0fae4fc..4550192 100644
> --- a/include/hw/pci-host/spapr.h
> +++ b/include/hw/pci-host/spapr.h
> @@ -57,6 +57,7 @@ struct sPAPRPHBState {
>  uint64_t mem64_win_pciaddr;
>  hwaddr io_win_addr, io_win_size;
>  MemoryRegion mem32window, mem64window, iowindow, msiwindow;
> +MemoryRegion mem32windowpci, mem64windowpci;
>  
>  uint32_t dma_liobn[SPAPR_PCI_DMA_MAX_WINDOWS];
>  hwaddr dma_win_addr, dma_win_size;
> diff --git a/hw/ppc/spapr_pci.c b/hw/ppc/spapr_pci.c
> index 37f18b3..d142f74 100644
> --- a/hw/ppc/spapr_pci.c
> 

Re: [Qemu-devel] [QEMU-PPC] [PATCH V4 1/6] target/ppc/kvm: Add cap_ppc_safe_[cache/bounds_check/indirect_branch]

[David Gibson]

On Mon, Jan 15, 2018 at 05:58:37PM +1100, Suraj Jitindar Singh wrote:
> Add three new kvm capabilities used to represent the level of host support
> for three corresponding workarounds.
> 
> Host support for each of the capabilities is queried through the
> new ioctl KVM_PPC_GET_CPU_CHAR which returns four uint64 quantities. The
> first two, character and behaviour, represent the available
> characteristics of the cpu and the behaviour of the cpu respectively.
> The second two, c_mask and b_mask, represent the mask of known bits for
> the character and beheviour dwords respectively.
> 
> Signed-off-by: Suraj Jitindar Singh 

Reviewed-by: David Gibson 

Waiting for the kernel part to go in before merging, though.

> ---
> 
> V3 -> V4:
> - Move kvmppc_get_cpu_characteristics() function implementation to fix
>   compilation on some targets.
> 
> ---
>  include/hw/ppc/spapr.h  | 12 +
>  linux-headers/asm-powerpc/kvm.h |  8 ++
>  linux-headers/linux/kvm.h   |  3 +++
>  target/ppc/kvm.c| 58 
> +
>  target/ppc/kvm_ppc.h| 18 +
>  5 files changed, 99 insertions(+)
> 
> diff --git a/include/hw/ppc/spapr.h b/include/hw/ppc/spapr.h
> index 0f5628f22e..eded0ea57d 100644
> --- a/include/hw/ppc/spapr.h
> +++ b/include/hw/ppc/spapr.h
> @@ -295,6 +295,18 @@ struct sPAPRMachineState {
>  #define H_DABRX_KERNEL (1ULL<<(63-62))
>  #define H_DABRX_USER   (1ULL<<(63-63))
>  
> +/* Values for KVM_PPC_GET_CPU_CHAR & H_GET_CPU_CHARACTERISTICS */
> +#define H_CPU_CHAR_SPEC_BAR_ORI31   PPC_BIT(0)
> +#define H_CPU_CHAR_BCCTRL_SERIALISEDPPC_BIT(1)
> +#define H_CPU_CHAR_L1D_FLUSH_ORI30  PPC_BIT(2)
> +#define H_CPU_CHAR_L1D_FLUSH_TRIG2  PPC_BIT(3)
> +#define H_CPU_CHAR_L1D_THREAD_PRIV  PPC_BIT(4)
> +#define H_CPU_CHAR_HON_BRANCH_HINTS PPC_BIT(5)
> +#define H_CPU_CHAR_THR_RECONF_TRIG  PPC_BIT(6)
> +#define H_CPU_BEHAV_FAVOUR_SECURITY PPC_BIT(0)
> +#define H_CPU_BEHAV_L1D_FLUSH_PRPPC_BIT(1)
> +#define H_CPU_BEHAV_BNDS_CHK_SPEC_BAR   PPC_BIT(2)
> +
>  /* Each control block has to be on a 4K boundary */
>  #define H_CB_ALIGNMENT 4096
>  
> diff --git a/linux-headers/asm-powerpc/kvm.h b/linux-headers/asm-powerpc/kvm.h
> index 61d6049f4c..5d2cb26848 100644
> --- a/linux-headers/asm-powerpc/kvm.h
> +++ b/linux-headers/asm-powerpc/kvm.h
> @@ -443,6 +443,14 @@ struct kvm_ppc_rmmu_info {
>   __u32   ap_encodings[8];
>  };
>  
> +/* For KVM_PPC_GET_CPU_CHAR */
> +struct kvm_ppc_cpu_char {
> +__u64   character;  /* characteristics of the CPU */
> +__u64   behaviour;  /* recommended software behaviour */
> +__u64   c_mask; /* valid bits in character */
> +__u64   b_mask; /* valid bits in behaviour */
> +};
> +
>  /* Per-vcpu XICS interrupt controller state */
>  #define KVM_REG_PPC_ICP_STATE(KVM_REG_PPC | KVM_REG_SIZE_U64 | 0x8c)
>  
> diff --git a/linux-headers/linux/kvm.h b/linux-headers/linux/kvm.h
> index ce6c2f11f4..c35f1bd363 100644
> --- a/linux-headers/linux/kvm.h
> +++ b/linux-headers/linux/kvm.h
> @@ -932,6 +932,7 @@ struct kvm_ppc_resize_hpt {
>  #define KVM_CAP_HYPERV_SYNIC2 148
>  #define KVM_CAP_HYPERV_VP_INDEX 149
>  #define KVM_CAP_S390_AIS_MIGRATION 150
> +#define KVM_CAP_PPC_GET_CPU_CHAR 151
>  
>  #ifdef KVM_CAP_IRQ_ROUTING
>  
> @@ -1261,6 +1262,8 @@ struct kvm_s390_ucas_mapping {
>  #define KVM_PPC_CONFIGURE_V3_MMU  _IOW(KVMIO,  0xaf, struct 
> kvm_ppc_mmuv3_cfg)
>  /* Available with KVM_CAP_PPC_RADIX_MMU */
>  #define KVM_PPC_GET_RMMU_INFO  _IOW(KVMIO,  0xb0, struct 
> kvm_ppc_rmmu_info)
> +/* Available with KVM_CAP_PPC_GET_CPU_CHAR */
> +#define KVM_PPC_GET_CPU_CHAR  _IOR(KVMIO,  0xb1, struct kvm_ppc_cpu_char)
>  
>  /* ioctl for vm fd */
>  #define KVM_CREATE_DEVICE  _IOWR(KVMIO,  0xe0, struct kvm_create_device)
> diff --git a/target/ppc/kvm.c b/target/ppc/kvm.c
> index 914be687e7..b16f731522 100644
> --- a/target/ppc/kvm.c
> +++ b/target/ppc/kvm.c
> @@ -89,6 +89,9 @@ static int cap_mmu_radix;
>  static int cap_mmu_hash_v3;
>  static int cap_resize_hpt;
>  static int cap_ppc_pvr_compat;
> +static int cap_ppc_safe_cache;
> +static int cap_ppc_safe_bounds_check;
> +static int cap_ppc_safe_indirect_branch;
>  
>  static uint32_t debug_inst_opcode;
>  
> @@ -121,6 +124,7 @@ static bool kvmppc_is_pr(KVMState *ks)
>  }
>  
>  static int kvm_ppc_register_host_cpu_type(MachineState *ms);
> +static void kvmppc_get_cpu_characteristics(KVMState *s);
>  
>  int kvm_arch_init(MachineState *ms, KVMState *s)
>  {
> @@ -147,6 +151,7 @@ int kvm_arch_init(MachineState *ms, KVMState *s)
>  cap_mmu_radix = kvm_vm_check_extension(s, KVM_CAP_PPC_MMU_RADIX);
>  cap_mmu_hash_v3 = kvm_vm_check_extension(s, KVM_CAP_PPC_MMU_HASH_V3);
>  cap_resize_hpt = 

Re: [Qemu-devel] [QEMU-PPC] [PATCH V3 5/6] target/ppc/spapr_caps: Add new tristate cap safe_indirect_branch

[David Gibson]

On Mon, Jan 15, 2018 at 05:32:34PM +1100, Suraj Jitindar Singh wrote:
> Add new tristate cap cap-ibs to represent the indirect branch
> serialisation capability.
> 
> Signed-off-by: Suraj Jitindar Singh 

Reviewed-by: David Gibson 

> ---
>  hw/ppc/spapr.c |  2 ++
>  hw/ppc/spapr_caps.c| 39 +++
>  include/hw/ppc/spapr.h |  5 -
>  3 files changed, 45 insertions(+), 1 deletion(-)
> 
> diff --git a/hw/ppc/spapr.c b/hw/ppc/spapr.c
> index 02a0cb656b..269c1c7857 100644
> --- a/hw/ppc/spapr.c
> +++ b/hw/ppc/spapr.c
> @@ -1793,6 +1793,7 @@ static const VMStateDescription vmstate_spapr = {
>  _spapr_cap_dfp,
>  _spapr_cap_cfpc,
>  _spapr_cap_sbbc,
> +_spapr_cap_ibs,
>  NULL
>  }
>  };
> @@ -3867,6 +3868,7 @@ static void spapr_machine_class_init(ObjectClass *oc, 
> void *data)
>  smc->default_caps.caps[SPAPR_CAP_DFP] = SPAPR_CAP_ON;
>  smc->default_caps.caps[SPAPR_CAP_CFPC] = SPAPR_CAP_BROKEN;
>  smc->default_caps.caps[SPAPR_CAP_SBBC] = SPAPR_CAP_BROKEN;
> +smc->default_caps.caps[SPAPR_CAP_IBS] = SPAPR_CAP_BROKEN;
>  spapr_caps_add_properties(smc, _abort);
>  }
>  
> diff --git a/hw/ppc/spapr_caps.c b/hw/ppc/spapr_caps.c
> index 518e019cf7..0b36333a85 100644
> --- a/hw/ppc/spapr_caps.c
> +++ b/hw/ppc/spapr_caps.c
> @@ -202,6 +202,17 @@ static void 
> cap_safe_bounds_check_apply(sPAPRMachineState *spapr, uint8_t val,
>  }
>  }
>  
> +static void cap_safe_indirect_branch_apply(sPAPRMachineState *spapr,
> +   uint8_t val, Error **errp)
> +{
> +if (tcg_enabled() && val) {
> +/* TODO - for now only allow broken for TCG */
> +error_setg(errp, "Requested safe indirect branch capability level 
> not supported by tcg, try a different value for cap-ibs");
> +} else if (kvm_enabled() && (val > 
> kvmppc_get_cap_safe_indirect_branch())) {
> +error_setg(errp, "Requested safe indirect branch capability level 
> not supported by kvm, try a different value for cap-ibs");
> +}
> +}
> +
>  #define VALUE_DESC_TRISTATE " (broken, workaround, fixed)"
>  
>  sPAPRCapabilityInfo capability_table[SPAPR_CAP_NUM] = {
> @@ -250,6 +261,15 @@ sPAPRCapabilityInfo capability_table[SPAPR_CAP_NUM] = {
>  .type = "string",
>  .apply = cap_safe_bounds_check_apply,
>  },
> +[SPAPR_CAP_IBS] = {
> +.name = "ibs",
> +.description = "Indirect Branch Serialisation" VALUE_DESC_TRISTATE,
> +.index = SPAPR_CAP_IBS,
> +.get = spapr_cap_get_tristate,
> +.set = spapr_cap_set_tristate,
> +.type = "string",
> +.apply = cap_safe_indirect_branch_apply,
> +},
>  };
>  
>  static sPAPRCapabilities default_caps_with_cpu(sPAPRMachineState *spapr,
> @@ -424,6 +444,25 @@ const VMStateDescription vmstate_spapr_cap_sbbc = {
>  },
>  };
>  
> +static bool spapr_cap_ibs_needed(void *opaque)
> +{
> +sPAPRMachineState *spapr = opaque;
> +
> +return spapr->cmd_line_caps[SPAPR_CAP_IBS] &&
> +   (spapr->eff.caps[SPAPR_CAP_IBS] != 
> spapr->def.caps[SPAPR_CAP_IBS]);
> +}
> +
> +const VMStateDescription vmstate_spapr_cap_ibs = {
> +.name = "spapr/cap/ibs",
> +.version_id = 1,
> +.minimum_version_id = 1,
> +.needed = spapr_cap_ibs_needed,
> +.fields = (VMStateField[]) {
> +VMSTATE_UINT8(mig.caps[SPAPR_CAP_IBS], sPAPRMachineState),
> +VMSTATE_END_OF_LIST()
> +},
> +};
> +
>  void spapr_caps_reset(sPAPRMachineState *spapr)
>  {
>  sPAPRCapabilities default_caps;
> diff --git a/include/hw/ppc/spapr.h b/include/hw/ppc/spapr.h
> index c65be62e92..549d7a4134 100644
> --- a/include/hw/ppc/spapr.h
> +++ b/include/hw/ppc/spapr.h
> @@ -64,8 +64,10 @@ typedef enum {
>  #define SPAPR_CAP_CFPC  0x03
>  /* Speculation Barrier Bounds Checking */
>  #define SPAPR_CAP_SBBC  0x04
> +/* Indirect Branch Serialisation */
> +#define SPAPR_CAP_IBS   0x05
>  /* Num Caps */
> -#define SPAPR_CAP_NUM   (SPAPR_CAP_SBBC + 1)
> +#define SPAPR_CAP_NUM   (SPAPR_CAP_IBS + 1)
>  
>  /*
>   * Capability Values
> @@ -785,6 +787,7 @@ extern const VMStateDescription vmstate_spapr_cap_vsx;
>  extern const VMStateDescription vmstate_spapr_cap_dfp;
>  extern const VMStateDescription vmstate_spapr_cap_cfpc;
>  extern const VMStateDescription vmstate_spapr_cap_sbbc;
> +extern const VMStateDescription vmstate_spapr_cap_ibs;
>  
>  static inline uint8_t spapr_get_cap(sPAPRMachineState *spapr, int cap)
>  {

-- 
David Gibson| I'll have my music baroque, and my code
david AT gibson.dropbear.id.au  | minimalist, thank you.  NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson


signature.asc
Description: PGP signature

Re: [Qemu-devel] [QEMU-PPC] [PATCH V3 6/6] target/ppc/spapr: Add H-Call H_GET_CPU_CHARACTERISTICS

[David Gibson]

On Mon, Jan 15, 2018 at 05:32:35PM +1100, Suraj Jitindar Singh wrote:
> The new H-Call H_GET_CPU_CHARACTERISTICS is used by the guest to query
> behaviours and available characteristics of the cpu.
> 
> Implement the handler for this new H-Call which formulates its response
> based on the setting of the spapr_caps cap-cfpc, cap-sbbc and cap-ibs.
> 
> Signed-off-by: Suraj Jitindar Singh 
> ---
>  hw/ppc/spapr_hcall.c   | 66 
> ++
>  include/hw/ppc/spapr.h |  1 +
>  2 files changed, 67 insertions(+)
> 
> diff --git a/hw/ppc/spapr_hcall.c b/hw/ppc/spapr_hcall.c
> index 51eba52e86..a693d3b852 100644
> --- a/hw/ppc/spapr_hcall.c
> +++ b/hw/ppc/spapr_hcall.c
> @@ -1654,6 +1654,69 @@ static target_ulong 
> h_client_architecture_support(PowerPCCPU *cpu,
>  return H_SUCCESS;
>  }
>  
> +static target_ulong h_get_cpu_characteristics(PowerPCCPU *cpu,
> +  sPAPRMachineState *spapr,
> +  target_ulong opcode,
> +  target_ulong *args)
> +{
> +uint64_t characteristics = H_CPU_CHAR_HON_BRANCH_HINTS &
> +~H_CPU_CHAR_THR_RECONF_TRIG;
> +uint64_t behaviour = H_CPU_BEHAV_FAVOUR_SECURITY;
> +uint8_t safe_cache = spapr_get_cap(spapr, SPAPR_CAP_CFPC);
> +uint8_t safe_bounds_check = spapr_get_cap(spapr, SPAPR_CAP_SBBC);
> +uint8_t safe_indirect_branch = spapr_get_cap(spapr, SPAPR_CAP_IBS);
> +
> +switch (safe_cache) {
> +case SPAPR_CAP_WORKAROUND:
> +characteristics |= H_CPU_CHAR_L1D_FLUSH_ORI30;
> +characteristics |= H_CPU_CHAR_L1D_FLUSH_TRIG2;
> +characteristics |= H_CPU_CHAR_L1D_THREAD_PRIV;
> +behaviour |= H_CPU_BEHAV_L1D_FLUSH_PR;
> +break;
> +case SPAPR_CAP_FIXED:
> +break;
> +default: /* broken */
> +if (safe_cache != SPAPR_CAP_BROKEN) {

I think you just assert() for this.  The only way these could get a
different value is if there's a bug elsewhere.

> +error_report("Invalid value for cap-cfpc (%d), assuming broken",
> + safe_cache);
> +}
> +behaviour |= H_CPU_BEHAV_L1D_FLUSH_PR;
> +break;
> +}
> +
> +switch (safe_bounds_check) {
> +case SPAPR_CAP_WORKAROUND:
> +characteristics |= H_CPU_CHAR_SPEC_BAR_ORI31;
> +behaviour |= H_CPU_BEHAV_BNDS_CHK_SPEC_BAR;
> +break;
> +case SPAPR_CAP_FIXED:
> +break;
> +default: /* broken */
> +if (safe_bounds_check != SPAPR_CAP_BROKEN) {
> +error_report("Invalid value for cap-sbbc (%d), assuming broken",
> + safe_bounds_check);
> +}
> +behaviour |= H_CPU_BEHAV_BNDS_CHK_SPEC_BAR;
> +break;
> +}
> +
> +switch (safe_indirect_branch) {
> +case SPAPR_CAP_FIXED:
> +characteristics |= H_CPU_CHAR_BCCTRL_SERIALISED;
> +default: /* broken */
> +if (safe_indirect_branch != SPAPR_CAP_BROKEN) {
> +error_report("Invalid value for cap-ibs (%d), assuming broken",
> + safe_indirect_branch);
> +}
> +break;
> +}
> +
> +args[0] = characteristics;
> +args[1] = behaviour;
> +
> +return H_SUCCESS;
> +}
> +
>  static spapr_hcall_fn papr_hypercall_table[(MAX_HCALL_OPCODE / 4) + 1];
>  static spapr_hcall_fn kvmppc_hypercall_table[KVMPPC_HCALL_MAX - 
> KVMPPC_HCALL_BASE + 1];
>  
> @@ -1733,6 +1796,9 @@ static void hypercall_register_types(void)
>  spapr_register_hypercall(H_INVALIDATE_PID, h_invalidate_pid);
>  spapr_register_hypercall(H_REGISTER_PROC_TBL, h_register_process_table);
>  
> +/* hcall-get-cpu-characteristics */
> +spapr_register_hypercall(H_GET_CPU_CHARACTERISTICS, 
> h_get_cpu_characteristics);
> +
>  /* "debugger" hcalls (also used by SLOF). Note: We do -not- differenciate
>   * here between the "CI" and the "CACHE" variants, they will use whatever
>   * mapping attributes qemu is using. When using KVM, the kernel will
> diff --git a/include/hw/ppc/spapr.h b/include/hw/ppc/spapr.h
> index 549d7a4134..62c077ac20 100644
> --- a/include/hw/ppc/spapr.h
> +++ b/include/hw/ppc/spapr.h
> @@ -404,6 +404,7 @@ struct sPAPRMachineState {
>  #define H_GET_HCA_INFO  0x1B8
>  #define H_GET_PERF_COUNT0x1BC
>  #define H_MANAGE_TRACE  0x1C0
> +#define H_GET_CPU_CHARACTERISTICS 0x1C8
>  #define H_FREE_LOGICAL_LAN_BUFFER 0x1D4
>  #define H_QUERY_INT_STATE   0x1E4
>  #define H_POLL_PENDING  0x1D8

-- 
David Gibson| I'll have my music baroque, and my code
david AT gibson.dropbear.id.au  | minimalist, thank you.  NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson


signature.asc
Description: PGP signature

Re: [Qemu-devel] [QEMU-PPC] [PATCH V3 3/6] target/ppc/spapr_caps: Add new tristate cap safe_cache

[David Gibson]

On Mon, Jan 15, 2018 at 05:32:32PM +1100, Suraj Jitindar Singh wrote:
> Add new tristate cap cap-cfpc to represent the cache flush on privilege
> change capability.
> 
> Signed-off-by: Suraj Jitindar Singh 

Reviewed-by: David Gibson 

> ---
>  hw/ppc/spapr.c |  2 ++
>  hw/ppc/spapr_caps.c| 40 
>  include/hw/ppc/spapr.h |  5 -
>  3 files changed, 46 insertions(+), 1 deletion(-)
> 
> diff --git a/hw/ppc/spapr.c b/hw/ppc/spapr.c
> index 3e528fe91e..5d62dc9968 100644
> --- a/hw/ppc/spapr.c
> +++ b/hw/ppc/spapr.c
> @@ -1791,6 +1791,7 @@ static const VMStateDescription vmstate_spapr = {
>  _spapr_cap_htm,
>  _spapr_cap_vsx,
>  _spapr_cap_dfp,
> +_spapr_cap_cfpc,
>  NULL
>  }
>  };
> @@ -3863,6 +3864,7 @@ static void spapr_machine_class_init(ObjectClass *oc, 
> void *data)
>  smc->default_caps.caps[SPAPR_CAP_HTM] = SPAPR_CAP_OFF;
>  smc->default_caps.caps[SPAPR_CAP_VSX] = SPAPR_CAP_ON;
>  smc->default_caps.caps[SPAPR_CAP_DFP] = SPAPR_CAP_ON;
> +smc->default_caps.caps[SPAPR_CAP_CFPC] = SPAPR_CAP_BROKEN;
>  spapr_caps_add_properties(smc, _abort);
>  }
>  
> diff --git a/hw/ppc/spapr_caps.c b/hw/ppc/spapr_caps.c
> index 436250d77b..bc2b2c3590 100644
> --- a/hw/ppc/spapr_caps.c
> +++ b/hw/ppc/spapr_caps.c
> @@ -180,6 +180,18 @@ static void cap_dfp_apply(sPAPRMachineState *spapr, 
> uint8_t val, Error **errp)
>  }
>  }
>  
> +static void cap_safe_cache_apply(sPAPRMachineState *spapr, uint8_t val,
> + Error **errp)
> +{
> +if (tcg_enabled() && val) {
> +/* TODO - for now only allow broken for TCG */
> +error_setg(errp, "Requested safe cache capability level not 
> supported by tcg, try a different value for cap-cfpc");
> +} else if (kvm_enabled() && (val > kvmppc_get_cap_safe_cache())) {
> +error_setg(errp, "Requested safe cache capability level not 
> supported by kvm, try a different value for cap-cfpc");
> +}
> +}
> +
> +#define VALUE_DESC_TRISTATE " (broken, workaround, fixed)"
>  
>  sPAPRCapabilityInfo capability_table[SPAPR_CAP_NUM] = {
>  [SPAPR_CAP_HTM] = {
> @@ -209,6 +221,15 @@ sPAPRCapabilityInfo capability_table[SPAPR_CAP_NUM] = {
>  .type = "bool",
>  .apply = cap_dfp_apply,
>  },
> +[SPAPR_CAP_CFPC] = {
> +.name = "cfpc",
> +.description = "Cache Flush on Privilege Change" VALUE_DESC_TRISTATE,
> +.index = SPAPR_CAP_CFPC,
> +.get = spapr_cap_get_tristate,
> +.set = spapr_cap_set_tristate,
> +.type = "string",
> +.apply = cap_safe_cache_apply,
> +},
>  };
>  
>  static sPAPRCapabilities default_caps_with_cpu(sPAPRMachineState *spapr,
> @@ -345,6 +366,25 @@ const VMStateDescription vmstate_spapr_cap_dfp = {
>  },
>  };
>  
> +static bool spapr_cap_cfpc_needed(void *opaque)
> +{
> +sPAPRMachineState *spapr = opaque;
> +
> +return spapr->cmd_line_caps[SPAPR_CAP_CFPC] &&
> +   (spapr->eff.caps[SPAPR_CAP_CFPC] != 
> spapr->def.caps[SPAPR_CAP_CFPC]);
> +}
> +
> +const VMStateDescription vmstate_spapr_cap_cfpc = {
> +.name = "spapr/cap/cfpc",
> +.version_id = 1,
> +.minimum_version_id = 1,
> +.needed = spapr_cap_cfpc_needed,
> +.fields = (VMStateField[]) {
> +VMSTATE_UINT8(mig.caps[SPAPR_CAP_CFPC], sPAPRMachineState),
> +VMSTATE_END_OF_LIST()
> +},
> +};

Hrm, some macros to build these would probably be a good idea..

>  void spapr_caps_reset(sPAPRMachineState *spapr)
>  {
>  sPAPRCapabilities default_caps;
> diff --git a/include/hw/ppc/spapr.h b/include/hw/ppc/spapr.h
> index 61bb3632c4..ff476693d1 100644
> --- a/include/hw/ppc/spapr.h
> +++ b/include/hw/ppc/spapr.h
> @@ -60,8 +60,10 @@ typedef enum {
>  #define SPAPR_CAP_VSX   0x01
>  /* Decimal Floating Point */
>  #define SPAPR_CAP_DFP   0x02
> +/* Cache Flush on Privilege Change */
> +#define SPAPR_CAP_CFPC  0x03
>  /* Num Caps */
> -#define SPAPR_CAP_NUM   (SPAPR_CAP_DFP + 1)
> +#define SPAPR_CAP_NUM   (SPAPR_CAP_CFPC + 1)
>  
>  /*
>   * Capability Values
> @@ -779,6 +781,7 @@ int spapr_caps_pre_save(void *opaque);
>  extern const VMStateDescription vmstate_spapr_cap_htm;
>  extern const VMStateDescription vmstate_spapr_cap_vsx;
>  extern const VMStateDescription vmstate_spapr_cap_dfp;
> +extern const VMStateDescription vmstate_spapr_cap_cfpc;
>  
>  static inline uint8_t spapr_get_cap(sPAPRMachineState *spapr, int cap)
>  {

-- 
David Gibson| I'll have my music baroque, and my code
david AT gibson.dropbear.id.au  | minimalist, thank you.  NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson


signature.asc
Description: PGP signature

Re: [Qemu-devel] [QEMU-PPC] [PATCH V3 4/6] target/ppc/spapr_caps: Add new tristate cap safe_bounds_check

[David Gibson]

On Mon, Jan 15, 2018 at 05:32:33PM +1100, Suraj Jitindar Singh wrote:
> Add new tristate cap cap-sbbc to represent the speculation barrier
> bounds checking capability.
> 
> Signed-off-by: Suraj Jitindar Singh 

Reviewed-by: David Gibson 

> ---
>  hw/ppc/spapr.c |  2 ++
>  hw/ppc/spapr_caps.c| 39 +++
>  include/hw/ppc/spapr.h |  5 -
>  3 files changed, 45 insertions(+), 1 deletion(-)
> 
> diff --git a/hw/ppc/spapr.c b/hw/ppc/spapr.c
> index 5d62dc9968..02a0cb656b 100644
> --- a/hw/ppc/spapr.c
> +++ b/hw/ppc/spapr.c
> @@ -1792,6 +1792,7 @@ static const VMStateDescription vmstate_spapr = {
>  _spapr_cap_vsx,
>  _spapr_cap_dfp,
>  _spapr_cap_cfpc,
> +_spapr_cap_sbbc,
>  NULL
>  }
>  };
> @@ -3865,6 +3866,7 @@ static void spapr_machine_class_init(ObjectClass *oc, 
> void *data)
>  smc->default_caps.caps[SPAPR_CAP_VSX] = SPAPR_CAP_ON;
>  smc->default_caps.caps[SPAPR_CAP_DFP] = SPAPR_CAP_ON;
>  smc->default_caps.caps[SPAPR_CAP_CFPC] = SPAPR_CAP_BROKEN;
> +smc->default_caps.caps[SPAPR_CAP_SBBC] = SPAPR_CAP_BROKEN;
>  spapr_caps_add_properties(smc, _abort);
>  }
>  
> diff --git a/hw/ppc/spapr_caps.c b/hw/ppc/spapr_caps.c
> index bc2b2c3590..518e019cf7 100644
> --- a/hw/ppc/spapr_caps.c
> +++ b/hw/ppc/spapr_caps.c
> @@ -191,6 +191,17 @@ static void cap_safe_cache_apply(sPAPRMachineState 
> *spapr, uint8_t val,
>  }
>  }
>  
> +static void cap_safe_bounds_check_apply(sPAPRMachineState *spapr, uint8_t 
> val,
> +Error **errp)
> +{
> +if (tcg_enabled() && val) {
> +/* TODO - for now only allow broken for TCG */
> +error_setg(errp, "Requested safe bounds check capability level not 
> supported by tcg, try a different value for cap-sbbc");
> +} else if (kvm_enabled() && (val > kvmppc_get_cap_safe_bounds_check())) {
> +error_setg(errp, "Requested safe bounds check capability level not 
> supported by kvm, try a different value for cap-sbbc");
> +}
> +}
> +
>  #define VALUE_DESC_TRISTATE " (broken, workaround, fixed)"
>  
>  sPAPRCapabilityInfo capability_table[SPAPR_CAP_NUM] = {
> @@ -230,6 +241,15 @@ sPAPRCapabilityInfo capability_table[SPAPR_CAP_NUM] = {
>  .type = "string",
>  .apply = cap_safe_cache_apply,
>  },
> +[SPAPR_CAP_SBBC] = {
> +.name = "sbbc",
> +.description = "Speculation Barrier Bounds Checking" 
> VALUE_DESC_TRISTATE,
> +.index = SPAPR_CAP_SBBC,
> +.get = spapr_cap_get_tristate,
> +.set = spapr_cap_set_tristate,
> +.type = "string",
> +.apply = cap_safe_bounds_check_apply,
> +},
>  };
>  
>  static sPAPRCapabilities default_caps_with_cpu(sPAPRMachineState *spapr,
> @@ -385,6 +405,25 @@ const VMStateDescription vmstate_spapr_cap_cfpc = {
>  },
>  };
>  
> +static bool spapr_cap_sbbc_needed(void *opaque)
> +{
> +sPAPRMachineState *spapr = opaque;
> +
> +return spapr->cmd_line_caps[SPAPR_CAP_SBBC] &&
> +   (spapr->eff.caps[SPAPR_CAP_SBBC] != 
> spapr->def.caps[SPAPR_CAP_SBBC]);
> +}
> +
> +const VMStateDescription vmstate_spapr_cap_sbbc = {
> +.name = "spapr/cap/sbbc",
> +.version_id = 1,
> +.minimum_version_id = 1,
> +.needed = spapr_cap_sbbc_needed,
> +.fields = (VMStateField[]) {
> +VMSTATE_UINT8(mig.caps[SPAPR_CAP_SBBC], sPAPRMachineState),
> +VMSTATE_END_OF_LIST()
> +},
> +};
> +
>  void spapr_caps_reset(sPAPRMachineState *spapr)
>  {
>  sPAPRCapabilities default_caps;
> diff --git a/include/hw/ppc/spapr.h b/include/hw/ppc/spapr.h
> index ff476693d1..c65be62e92 100644
> --- a/include/hw/ppc/spapr.h
> +++ b/include/hw/ppc/spapr.h
> @@ -62,8 +62,10 @@ typedef enum {
>  #define SPAPR_CAP_DFP   0x02
>  /* Cache Flush on Privilege Change */
>  #define SPAPR_CAP_CFPC  0x03
> +/* Speculation Barrier Bounds Checking */
> +#define SPAPR_CAP_SBBC  0x04
>  /* Num Caps */
> -#define SPAPR_CAP_NUM   (SPAPR_CAP_CFPC + 1)
> +#define SPAPR_CAP_NUM   (SPAPR_CAP_SBBC + 1)
>  
>  /*
>   * Capability Values
> @@ -782,6 +784,7 @@ extern const VMStateDescription vmstate_spapr_cap_htm;
>  extern const VMStateDescription vmstate_spapr_cap_vsx;
>  extern const VMStateDescription vmstate_spapr_cap_dfp;
>  extern const VMStateDescription vmstate_spapr_cap_cfpc;
> +extern const VMStateDescription vmstate_spapr_cap_sbbc;
>  
>  static inline uint8_t spapr_get_cap(sPAPRMachineState *spapr, int cap)
>  {

-- 
David Gibson| I'll have my music baroque, and my code
david AT gibson.dropbear.id.au  | minimalist, thank you.  NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson


signature.asc
Description: PGP signature

Re: [Qemu-devel] [QEMU-PPC] [PATCH V3 2/6] target/ppc/spapr_caps: Add support for tristate spapr_capabilities

[David Gibson]

On Mon, Jan 15, 2018 at 05:32:31PM +1100, Suraj Jitindar Singh wrote:
> spapr_caps are used to represent the level of support for various
> capabilities related to the spapr machine type. Currently there is
> only support for boolean capabilities.
> 
> Add support for tristate capabilities by implementing their get/set
> functions. These capabilities can have the values 0, 1 or 2
> corresponding to broken, workaround and fixed.
> 
> Signed-off-by: Suraj Jitindar Singh 

Applied to ppc-for-2.12.

> ---
>  hw/ppc/spapr_caps.c| 60 
> ++
>  include/hw/ppc/spapr.h |  4 
>  2 files changed, 64 insertions(+)
> 
> diff --git a/hw/ppc/spapr_caps.c b/hw/ppc/spapr_caps.c
> index d5c9ce774a..436250d77b 100644
> --- a/hw/ppc/spapr_caps.c
> +++ b/hw/ppc/spapr_caps.c
> @@ -73,6 +73,66 @@ static void spapr_cap_set_bool(Object *obj, Visitor *v, 
> const char *name,
>  spapr->eff.caps[cap->index] = value ? SPAPR_CAP_ON : SPAPR_CAP_OFF;
>  }
>  
> +static void spapr_cap_get_tristate(Object *obj, Visitor *v, const char *name,
> +   void *opaque, Error **errp)
> +{
> +sPAPRCapabilityInfo *cap = opaque;
> +sPAPRMachineState *spapr = SPAPR_MACHINE(obj);
> +char *val = NULL;
> +uint8_t value = spapr_get_cap(spapr, cap->index);
> +
> +switch (value) {
> +case SPAPR_CAP_BROKEN:
> +val = g_strdup("broken");
> +break;
> +case SPAPR_CAP_WORKAROUND:
> +val = g_strdup("workaround");
> +break;
> +case SPAPR_CAP_FIXED:
> +val = g_strdup("fixed");
> +break;
> +default:
> +error_setg(errp, "Invalid value (%d) for cap-%s", value, cap->name);
> +return;
> +}
> +
> +visit_type_str(v, name, , errp);
> +g_free(val);
> +}
> +
> +static void spapr_cap_set_tristate(Object *obj, Visitor *v, const char *name,
> +   void *opaque, Error **errp)
> +{
> +sPAPRCapabilityInfo *cap = opaque;
> +sPAPRMachineState *spapr = SPAPR_MACHINE(obj);
> +char *val;
> +Error *local_err = NULL;
> +uint8_t value;
> +
> +visit_type_str(v, name, , _err);
> +if (local_err) {
> +error_propagate(errp, local_err);
> +return;
> +}
> +
> +if (!strcasecmp(val, "broken")) {
> +value = SPAPR_CAP_BROKEN;
> +} else if (!strcasecmp(val, "workaround")) {
> +value = SPAPR_CAP_WORKAROUND;
> +} else if (!strcasecmp(val, "fixed")) {
> +value = SPAPR_CAP_FIXED;
> +} else {
> +error_setg(errp, "Invalid capability mode \"%s\" for cap-%s", val,
> +   cap->name);
> +goto out;
> +}
> +
> +spapr->cmd_line_caps[cap->index] = true;
> +spapr->eff.caps[cap->index] = value;
> +out:
> +g_free(val);
> +}
> +
>  static void cap_htm_apply(sPAPRMachineState *spapr, uint8_t val, Error 
> **errp)
>  {
>  if (!val) {
> diff --git a/include/hw/ppc/spapr.h b/include/hw/ppc/spapr.h
> index eded0ea57d..61bb3632c4 100644
> --- a/include/hw/ppc/spapr.h
> +++ b/include/hw/ppc/spapr.h
> @@ -69,6 +69,10 @@ typedef enum {
>  /* Bool Caps */
>  #define SPAPR_CAP_OFF   0x00
>  #define SPAPR_CAP_ON0x01
> +/* Broken | Workaround | Fixed Caps */
> +#define SPAPR_CAP_BROKEN0x00
> +#define SPAPR_CAP_WORKAROUND0x01
> +#define SPAPR_CAP_FIXED 0x02
>  
>  typedef struct sPAPRCapabilities sPAPRCapabilities;
>  struct sPAPRCapabilities {

-- 
David Gibson| I'll have my music baroque, and my code
david AT gibson.dropbear.id.au  | minimalist, thank you.  NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson


signature.asc
Description: PGP signature

[Qemu-devel] [PATCH] chardev: fix incorrect unref of source

[Peter Xu]

glib reported error when pty chardev used:

$ ./qemu-system-x86_64 -chardev pty,id=foo -device isa-serial,chardev=foo
qemu-system-x86_64: -chardev pty,id=foo: char device redirected to /dev/pts/2 
(label foo)
(qemu-system-x86_64:27885): GLib-CRITICAL **: g_source_unref: assertion 'source 
!= NULL' failed
(qemu-system-x86_64:27885): GLib-CRITICAL **: g_source_unref: assertion 'source 
!= NULL' failed

This patch fixes that.

Fixes: 2c716ba150 ("chardev: introduce qemu_chr_timeout_add_ms()")
CC: Paolo Bonzini 
Reported-by: Marc-André Lureau 
Signed-off-by: Peter Xu 
---
 chardev/char-pty.c | 38 +-
 1 file changed, 21 insertions(+), 17 deletions(-)

diff --git a/chardev/char-pty.c b/chardev/char-pty.c
index 89315e6807..68fd4e20c3 100644
--- a/chardev/char-pty.c
+++ b/chardev/char-pty.c
@@ -51,15 +51,32 @@ typedef struct {
 static void pty_chr_update_read_handler_locked(Chardev *chr);
 static void pty_chr_state(Chardev *chr, int connected);
 
+static void pty_chr_timer_cancel(PtyChardev *s)
+{
+if (s->timer_src) {
+g_source_destroy(s->timer_src);
+g_source_unref(s->timer_src);
+s->timer_src = NULL;
+}
+}
+
+static void pty_chr_open_src_cancel(PtyChardev *s)
+{
+if (s->open_source) {
+g_source_destroy(s->open_source);
+g_source_unref(s->open_source);
+s->open_source = NULL;
+}
+}
+
 static gboolean pty_chr_timer(gpointer opaque)
 {
 struct Chardev *chr = CHARDEV(opaque);
 PtyChardev *s = PTY_CHARDEV(opaque);
 
 qemu_mutex_lock(>chr_write_lock);
-s->timer_src = NULL;
-g_source_unref(s->open_source);
-s->open_source = NULL;
+pty_chr_timer_cancel(s);
+pty_chr_open_src_cancel(s);
 if (!s->connected) {
 /* Next poll ... */
 pty_chr_update_read_handler_locked(chr);
@@ -68,15 +85,6 @@ static gboolean pty_chr_timer(gpointer opaque)
 return FALSE;
 }
 
-static void pty_chr_timer_cancel(PtyChardev *s)
-{
-if (s->timer_src) {
-g_source_destroy(s->timer_src);
-g_source_unref(s->timer_src);
-s->timer_src = NULL;
-}
-}
-
 /* Called with chr_write_lock held.  */
 static void pty_chr_rearm_timer(Chardev *chr, int ms)
 {
@@ -195,11 +203,7 @@ static void pty_chr_state(Chardev *chr, int connected)
 PtyChardev *s = PTY_CHARDEV(chr);
 
 if (!connected) {
-if (s->open_source) {
-g_source_destroy(s->open_source);
-g_source_unref(s->open_source);
-s->open_source = NULL;
-}
+pty_chr_open_src_cancel(s);
 remove_fd_in_watch(chr);
 s->connected = 0;
 /* (re-)connect poll interval for idle guests: once per second.
-- 
2.14.3

Re: [Qemu-devel] [PULL 08/51] chardev: introduce qemu_chr_timeout_add_ms()

[Peter Xu]

On Wed, Jan 17, 2018 at 05:21:40PM +0100, Marc-André Lureau wrote:
> Hi
> 
> On Tue, Jan 16, 2018 at 3:16 PM, Paolo Bonzini  wrote:
> > From: Peter Xu 
> >
> > It's a replacement of g_timeout_add[_seconds]() for chardevs.  Chardevs
> > now can have dedicated gcontext, we should always bind chardev tasks
> > onto those gcontext rather than the default main context.  Since there
> > are quite a few of g_timeout_add[_seconds]() callers, a new function
> > qemu_chr_timeout_add_ms() is introduced.
> >
> > One thing to mention is that, terminal3270 is still always running on
> > main gcontext.  However let's convert that as well since it's still part
> > of chardev codes and in case one day we'll miss that when we move it out
> > of main gcontext too.
> >
> > Also, convert all the timers from GSource tags into GSource pointers.
> > Gsource tag IDs and g_source_remove()s can only work with default
> > gcontext, while now these GSources can logically be attached to other
> > contexts.  So let's use explicit g_source_destroy() plus another
> > g_source_unref() to remove a timer.
> >
> > Note: when in the timer handler, we don't need the g_source_destroy()
> > any more since that'll be done automatically if the timer handler
> > returns false (and that's what all the current handlers do).
> >
> > Yet another note: in pty_chr_rearm_timer() we take special care for
> > ms=1000.  This patch merged the two cases into one.
> >
> > Signed-off-by: Peter Xu 
> > Message-Id: <20180104141835.17987-4-pet...@redhat.com>
> > Signed-off-by: Paolo Bonzini 
> > ---
> >  chardev/char-pty.c | 43 +++
> >  chardev/char-socket.c  | 28 ++--
> >  chardev/char.c | 18 ++
> >  hw/char/terminal3270.c | 28 
> >  include/chardev/char.h |  3 +++
> >  5 files changed, 74 insertions(+), 46 deletions(-)
> >
> > diff --git a/chardev/char-pty.c b/chardev/char-pty.c
> > index 8248e36..89315e6 100644
> > --- a/chardev/char-pty.c
> > +++ b/chardev/char-pty.c
> > @@ -42,7 +42,7 @@ typedef struct {
> >
> >  /* Protected by the Chardev chr_write_lock.  */
> >  int connected;
> > -guint timer_tag;
> > +GSource *timer_src;
> >  GSource *open_source;
> >  } PtyChardev;
> >
> > @@ -57,7 +57,8 @@ static gboolean pty_chr_timer(gpointer opaque)
> >  PtyChardev *s = PTY_CHARDEV(opaque);
> >
> >  qemu_mutex_lock(>chr_write_lock);
> > -s->timer_tag = 0;
> > +s->timer_src = NULL;
> > +g_source_unref(s->open_source);
> 
> why that line ^ ? It adds criticals every second (for ex with -chardev
> pty,id=foo -device isa-serial,chardev=foo).

My fault.  I must have had a wrong rebase somehow after switching to
GSource pointers while kept the compiling happy.  I'll post a fix
soon.  Sorry!

-- 
Peter Xu

Re: [Qemu-devel] [Qemu-ppc] [QEMU-PPC] [PATCH V3 0/6] target/ppc: Rework spapr_caps

[David Gibson]

On Wed, Jan 17, 2018 at 09:54:57AM +0100, Andrea Bolognani wrote:
> On Wed, 2018-01-17 at 10:26 +1100, Alexey Kardashevskiy wrote:
> > On 17/01/18 09:34, David Gibson wrote:
> > > On Tue, Jan 16, 2018 at 03:46:20PM +0100, Andrea Bolognani wrote:
> > > > On Wed, 2018-01-17 at 00:54 +1100, David Gibson wrote:
> > > > > > Correct me if I'm wrong, but it seems to me like there's no way
> > > > > > to figure out through QMP whether these new machine options can be
> > > > > > used for a given QEMU binary.
> > > > > 
> > > > > Uh, I don't think so.  These are machine options like any other (just
> > > > > constructed a bit differently).  So they'll appear in qemu -machine
> > > > > pseries,? and I believe that info can also be retrieved with QMP.
> > > > 
> > > > Yes, they will indeed show up in the output of -machine pseries,?
> > > > but there's AFAICT no way to retrieve them via QMP.
> > > 
> > > Really!?  I thought introspecting object properties was QMP's bread
> > > and butter.
> > 
> > On a guest started with '-S':
> > {"execute": "qom-list", "arguments": {"path": "/machine"}}
> > 
> > returns:
> > {   'return': [   {'name': 'graphics', 'type': 'bool'},
> [...]
> >   {'name': 'cap-dfp', 'type': 'bool'},
> >   {'name': 'cap-htm', 'type': 'bool'},
> >   {'name': 'cap-vsx', 'type': 'bool'},
> >   {'name': 'vfio-no-msix-emulation', 'type': 'bool'},
> >   {'name': 'kvm-type', 'type': 'string'},
> >   {'name': 'max-cpu-compat', 'type': 'string'},
> [...]
> >   {'name': 'resize-hpt', 'type': 'string'}]}
> > 
> > but still requires a running qemu, yes.
> 
> That's not a problem in itself; however, AFAICT the guest in
> question also needs to be started with -machine pseries in order
> for the above to work, which means it's not usable due to the
> scalability issues mentioned earlier in the thread. We run QEMU
> with -machine none, a single time, to probe for capabilities.
> 
> I looked further and device-list-properties looks like it would
> do the trick; however it doesn't seem to work for machines:
> 
>   {"execute": "device-list-properties",
>"arguments": {"typename": "spapr-2.11-machine"}}
>   {"error": {"class": "GenericError",
>  "desc": "Parameter 'typename' expects device"}}
> 
> It works fine for the likes of virtio-scsi-pci and even
> power9_v2.0-powerpc64-cpu, though. Any ideas? :)

I'm guessing it's because machines aren't descended from TYPE_DEVICE.

Dammit.  I really can't see a reasonable way of addressing this other
than improving qapi in general to have a way of reporting machine
class properties.  Adding something ad-hoc for just these properties
of this machine seems like madness.

Nor can I think of a place to put these that would be both sensible
and more discoverable with existing mechanisms.

-- 
David Gibson| I'll have my music baroque, and my code
david AT gibson.dropbear.id.au  | minimalist, thank you.  NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson


signature.asc
Description: PGP signature

Re: [Qemu-devel] [PATCH] scsi-generic: Simplify error handling code

[Philippe Mathieu-Daudé]

On 01/17/2018 11:52 PM, Fam Zheng wrote:
> Coverity doesn't like the ignored return value introduced in
> 9d3b155186c278 (hw/block: Fix the return type), and other callers are
> converted already in ceff3e1f01.
> 
> This one was added lately in d9bcd6f7f23a and missed the train. Do it
> now.
> 
> Signed-off-by: Fam Zheng 

Reviewed-by: Philippe Mathieu-Daudé 

> ---
>  hw/scsi/scsi-generic.c | 9 +++--
>  1 file changed, 3 insertions(+), 6 deletions(-)
> 
> diff --git a/hw/scsi/scsi-generic.c b/hw/scsi/scsi-generic.c
> index ba70c0dc19..7414fe2d67 100644
> --- a/hw/scsi/scsi-generic.c
> +++ b/hw/scsi/scsi-generic.c
> @@ -482,7 +482,6 @@ static void scsi_generic_realize(SCSIDevice *s, Error 
> **errp)
>  int rc;
>  int sg_version;
>  struct sg_scsi_id scsiid;
> -Error *local_err = NULL;
>  
>  if (!s->conf.blk) {
>  error_setg(errp, "drive property not set");
> @@ -516,11 +515,9 @@ static void scsi_generic_realize(SCSIDevice *s, Error 
> **errp)
>  error_setg(errp, "SG_GET_SCSI_ID ioctl failed");
>  return;
>  }
> -blkconf_apply_backend_options(>conf,
> -  blk_is_read_only(s->conf.blk),
> -  true, _err);
> -if (local_err) {
> -error_propagate(errp, local_err);
> +if (!blkconf_apply_backend_options(>conf,
> +   blk_is_read_only(s->conf.blk),
> +   true, errp)) {
>  return;
>  }
>  
> 

Re: [Qemu-devel] [PATCH 3/3] target/ppc: add support for hypervisor doorbells on book3s CPUs

[David Gibson]

On Tue, Jan 16, 2018 at 08:41:57AM +0100, Cédric Le Goater wrote:
> The hypervisor doorbells are used by skiboot and Linux on POWER9
> processors to wake up secondaries.
> 
> This adds processor control support to the Server architecture by
> reusing the Embedded support. They are very similar, only the bits
> definition of the CPU identifier differ.
> 
> Still to be done is message broadcast to all threads of the same
> processor.
> 
> Signed-off-by: Cédric Le Goater 
> ---
>  target/ppc/cpu.h|  8 ++--
>  target/ppc/excp_helper.c| 39 ---
>  target/ppc/helper.h |  2 +-
>  target/ppc/translate.c  | 13 -
>  target/ppc/translate_init.c |  2 +-
>  5 files changed, 52 insertions(+), 12 deletions(-)
> 
> diff --git a/target/ppc/cpu.h b/target/ppc/cpu.h
> index b8f4dfc1084a..603a38cae83f 100644
> --- a/target/ppc/cpu.h
> +++ b/target/ppc/cpu.h
> @@ -930,7 +930,7 @@ enum {
>  #define BOOKE206_MAX_TLBN  4
>  
>  
> /*/
> -/* Embedded.Processor Control */
> +/* Server and Embedded Processor Control */
>  
>  #define DBELL_TYPE_SHIFT   27
>  #define DBELL_TYPE_MASK(0x1f << DBELL_TYPE_SHIFT)
> @@ -940,11 +940,15 @@ enum {
>  #define DBELL_TYPE_G_DBELL_CRIT(0x03 << DBELL_TYPE_SHIFT)
>  #define DBELL_TYPE_G_DBELL_MC  (0x04 << DBELL_TYPE_SHIFT)
>  
> -#define DBELL_BRDCAST  (1 << 26)
> +#define DBELL_TYPE_DBELL_SERVER(0x05 << DBELL_TYPE_SHIFT)
> +
> +#define DBELL_BRDCAST  PPC_BIT(37)
>  #define DBELL_LPIDTAG_SHIFT14
>  #define DBELL_LPIDTAG_MASK (0xfff << DBELL_LPIDTAG_SHIFT)
>  #define DBELL_PIRTAG_MASK  0x3fff
>  
> +#define DBELL_PROCIDTAG_MASK   PPC_BITMASK(44, 63)
> +
>  
> /*/
>  /* Segment page size information, used by recent hash MMUs
>   * The format of this structure mirrors kvm_ppc_smmu_info
> diff --git a/target/ppc/excp_helper.c b/target/ppc/excp_helper.c
> index 4e548a448747..0f32cab1ff57 100644
> --- a/target/ppc/excp_helper.c
> +++ b/target/ppc/excp_helper.c
> @@ -417,6 +417,7 @@ static inline void powerpc_excp(PowerPCCPU *cpu, int 
> excp_model, int excp)
>  case POWERPC_EXCP_HISI:  /* Hypervisor instruction storage exception 
> */
>  case POWERPC_EXCP_HDSEG: /* Hypervisor data segment exception
> */
>  case POWERPC_EXCP_HISEG: /* Hypervisor instruction segment exception 
> */
> +case POWERPC_EXCP_SDOOR_HV:  /* Hypervisor Doorbell interrupt
> */
>  case POWERPC_EXCP_HV_EMU:
>  srr0 = SPR_HSRR0;
>  srr1 = SPR_HSRR1;
> @@ -846,6 +847,11 @@ static void ppc_hw_interrupt(CPUPPCState *env)
>  powerpc_excp(cpu, env->excp_model, POWERPC_EXCP_DOORI);
>  return;
>  }
> +if (env->pending_interrupts & (1 << PPC_INTERRUPT_HDOORBELL)) {
> +env->pending_interrupts &= ~(1 << PPC_INTERRUPT_HDOORBELL);
> +powerpc_excp(cpu, env->excp_model, POWERPC_EXCP_SDOOR_HV);
> +return;
> +}
>  if (env->pending_interrupts & (1 << PPC_INTERRUPT_PERFM)) {
>  env->pending_interrupts &= ~(1 << PPC_INTERRUPT_PERFM);
>  powerpc_excp(cpu, env->excp_model, POWERPC_EXCP_PERFM);
> @@ -1088,8 +1094,8 @@ void helper_rfsvc(CPUPPCState *env)
>  do_rfi(env, env->lr, env->ctr & 0x);
>  }
>  
> -/* Embedded.Processor Control */
> -static int dbell2irq(target_ulong rb)
> +/* Server and Embedded Processor Control */
> +static int dbell2irq(target_ulong rb, bool book3s)
>  {
>  int msg = rb & DBELL_TYPE_MASK;
>  int irq = -1;
> @@ -1109,12 +1115,21 @@ static int dbell2irq(target_ulong rb)
>  break;
>  }
>  
> +/* A Directed Hypervisor Doorbell message is sent only if the
> + * message type is 5. All other types are reserved and the
> + * instruction is a no-op */

I don't see that the logic here accomplishes that.  Other types will
return the same value as for embedded - that doesn't seem like it will
result in a no-op.

> +if (book3s && msg == DBELL_TYPE_DBELL_SERVER) {
> +irq = PPC_INTERRUPT_HDOORBELL;
> +}
> +
>  return irq;
>  }
>  
>  void helper_msgclr(CPUPPCState *env, target_ulong rb)
>  {
> -int irq = dbell2irq(rb);
> +/* 64-bit server processors compliant with arch 2.x */
> +bool book3s = (env->insns_flags & PPC_SEGMENT_64B);

Keying off an otherwise unrelated instruction bit seems bogus to me.

> +int irq = dbell2irq(rb, book3s);
>  
>  if (irq < 0) {
>  return;
> @@ -1123,10 +1138,11 @@ void helper_msgclr(CPUPPCState *env, target_ulong rb)
>  env->pending_interrupts &= ~(1 << irq);
>  }
>  
> -void helper_msgsnd(target_ulong rb)
> +void helper_msgsnd(CPUPPCState *env, target_ulong rb)
>  {
> - 

Re: [Qemu-devel] [PATCH 3/3] spapr: fix device tree properties when using compatibility mode

[David Gibson]

On Wed, Jan 17, 2018 at 10:20:42AM +0100, Greg Kurz wrote:
> Commit 51f84465dd98 changed the compatility mode setting logic:
> - machine reset only sets compatibility mode for the boot CPU
> - compatibility mode is set for other CPUs when they are put online
>   by the guest with the "start-cpu" RTAS call
> 
> This causes a regression for machines started with max-compat-cpu:
> the device tree nodes related to secondary CPU cores contain wrong
> "cpu-version" and "ibm,pa-features" values, as shown below.
> 
> Guest started on a POWER8 host with:
>  -smp cores=2 -machine pseries,max-cpu-compat=compat7
> 
> # dtc -f -I fs -O dts /proc/device-tree | egrep 'cpu-version|pa-features'
> ibm,pa-features = [18 00 f6 3f c7 c0 80 f0 80 00
>  00 00 00 00 00 00 00 00 80 00 80 00 80 00 00 00];
> cpu-version = <0x4d0200>;
> 
>^^^
> second CPU core
> 
> ibm,pa-features = <0x600f63f 0xc70080c0>;
> cpu-version = <0xf03>;
> 
>^^^
>   boot CPU core
> 
> The second core is advertised in raw POWER8 mode. This happens because
> CAS assumes all CPUs to have the same compatibility mode. Since the
> boot CPU already has the requested compatibility mode, the CAS code
> does not set it for the secondary one, and exposes the bogus device
> tree properties in in the CAS response to the guest.
> 
> A similar situation is observed when hot-plugging a CPU core. The
> related device tree properties are generated and exposed to guest
> with the "ibm,configure-connector" RTAS before "start-cpu" is called.
> The CPU core is advertised to the guest in raw mode as well.
> 
> It both cases, it boils down to the fact that "start-cpu" happens too
> late. This can be fixed globally by propagating the compatibility mode
> of the boot CPU to the other CPUs during reset.  For this to work, the
> compatibility mode of the boot CPU must be set before the machine code
> actually resets all CPUs.
> 
> It is not needed to set the compatibility mode in "start-cpu" anymore,
> so the code is dropped.
> 
> Signed-off-by: Greg Kurz 

Applied to ppc-for-2.12.

I forgot that the RTAS call came after constructing the device tree
fragment, and is therefore too late to set the compatibility mode.

> ---
>  hw/ppc/spapr.c  |   18 +-
>  hw/ppc/spapr_cpu_core.c |7 +++
>  hw/ppc/spapr_rtas.c |9 -
>  3 files changed, 16 insertions(+), 18 deletions(-)
> 
> diff --git a/hw/ppc/spapr.c b/hw/ppc/spapr.c
> index a2ff401f738a..a00bff823f95 100644
> --- a/hw/ppc/spapr.c
> +++ b/hw/ppc/spapr.c
> @@ -1484,6 +1484,15 @@ static void spapr_machine_reset(void)
>  spapr_setup_hpt_and_vrma(spapr);
>  }
>  
> +/* if this reset wasn't generated by CAS, we should reset our
> + * negotiated options and start from scratch */
> +if (!spapr->cas_reboot) {
> +spapr_ovec_cleanup(spapr->ov5_cas);
> +spapr->ov5_cas = spapr_ovec_new();
> +
> +ppc_set_compat(first_ppc_cpu, spapr->max_compat_pvr, _fatal);
> +}
> +
>  qemu_devices_reset();
>  
>  /* DRC reset may cause a device to be unplugged. This will cause troubles
> @@ -1504,15 +1513,6 @@ static void spapr_machine_reset(void)
>  rtas_addr = rtas_limit - RTAS_MAX_SIZE;
>  fdt_addr = rtas_addr - FDT_MAX_SIZE;
>  
> -/* if this reset wasn't generated by CAS, we should reset our
> - * negotiated options and start from scratch */
> -if (!spapr->cas_reboot) {
> -spapr_ovec_cleanup(spapr->ov5_cas);
> -spapr->ov5_cas = spapr_ovec_new();
> -
> -ppc_set_compat(first_ppc_cpu, spapr->max_compat_pvr, _fatal);
> -}
> -
>  fdt = spapr_build_fdt(spapr, rtas_addr, spapr->rtas_size);
>  
>  spapr_load_rtas(spapr, fdt, rtas_addr);
> diff --git a/hw/ppc/spapr_cpu_core.c b/hw/ppc/spapr_cpu_core.c
> index 268be7784efb..f5e5ead5f4b0 100644
> --- a/hw/ppc/spapr_cpu_core.c
> +++ b/hw/ppc/spapr_cpu_core.c
> @@ -44,6 +44,13 @@ void spapr_cpu_reset(void *opaque)
>  if (cs != first_cpu) {
>  env->spr[SPR_LPCR] &= ~pcc->lpcr_pm;
>  }
> +
> +/* Set compatibility mode to match the boot CPU, which was either set
> + * by the machine reset code or by CAS. This should never fail.
> + */
> +if (cs != first_cpu) {
> +ppc_set_compat(cpu, POWERPC_CPU(first_cpu)->compat_pvr, 
> _abort);
> +}
>  }
>  
>  static void spapr_cpu_destroy(PowerPCCPU *cpu)
> diff --git a/hw/ppc/spapr_rtas.c b/hw/ppc/spapr_rtas.c
> index 2b89e1d448e4..4bb939d3d111 100644
> --- a/hw/ppc/spapr_rtas.c
> +++ b/hw/ppc/spapr_rtas.c
> @@ -163,7 +163,6 @@ static void rtas_start_cpu(PowerPCCPU *cpu_, 
> sPAPRMachineState *spapr,
>  CPUState *cs = CPU(cpu);
>  CPUPPCState *env = >env;
>  PowerPCCPUClass *pcc = POWERPC_CPU_GET_CLASS(cpu);
> -Error 

Re: [Qemu-devel] [PATCH 2/3] spapr_cpu_core: don't reset CPUs during realization

[David Gibson]

On Wed, Jan 17, 2018 at 10:20:35AM +0100, Greg Kurz wrote:
> When QEMU is started, all cold-plugged CPUs are reset twice: first
> during initialization and then during machine reset. This is sub-
> optimal.
> 
> The first reset is only needed for hot-plugged CPUs because the CPU
> hotplug code doesn't reset them. This patch adds the necessary code
> to reset hot-plugged CPUs on the CPU core hotplug path, and removes
> the now useless initial CPU reset.
> 
> We just need to mark the newly created CPU as halted to prevent it
> to run until it is put online later.
> 
> Full CPU reset is now explicitely triggered from the machine code
> only, either during system reset or during CPU hotplug.
> 
> Signed-off-by: Greg Kurz 

Hrm, this looks ok in outline, but makes me nervous in a couple of
ways.


> ---
>  hw/ppc/spapr.c  |8 
>  hw/ppc/spapr_cpu_core.c |8 ++--
>  include/hw/ppc/spapr_cpu_core.h |2 ++
>  3 files changed, 16 insertions(+), 2 deletions(-)
> 
> diff --git a/hw/ppc/spapr.c b/hw/ppc/spapr.c
> index bca838fce638..a2ff401f738a 100644
> --- a/hw/ppc/spapr.c
> +++ b/hw/ppc/spapr.c
> @@ -3336,6 +3336,14 @@ static void spapr_core_plug(HotplugHandler 
> *hotplug_dev, DeviceState *dev,
>  void *fdt;
>  int fdt_offset;
>  
> +if (hotplugged) {

First, I'm always wary of using the hotplugged parameter, because what
qemu means by it often doesn't line up with what PAPR means by it.

> +int i;
> +
> +for (i = 0; i < cc->nr_threads; i++) {
> +spapr_cpu_reset(core->threads[i]);
> +}
> +}
> +
>  fdt = spapr_populate_hotplug_cpu_dt(cs, _offset, spapr);
>  
>  spapr_drc_attach(drc, dev, fdt, fdt_offset, _err);
> diff --git a/hw/ppc/spapr_cpu_core.c b/hw/ppc/spapr_cpu_core.c
> index ac19b2e0b72c..268be7784efb 100644
> --- a/hw/ppc/spapr_cpu_core.c
> +++ b/hw/ppc/spapr_cpu_core.c
> @@ -22,7 +22,7 @@
>  #include "sysemu/hw_accel.h"
>  #include "qemu/error-report.h"
>  
> -static void spapr_cpu_reset(void *opaque)
> +void spapr_cpu_reset(void *opaque)
>  {
>  PowerPCCPU *cpu = opaque;
>  CPUState *cs = CPU(cpu);
> @@ -63,7 +63,11 @@ static void spapr_cpu_init(sPAPRMachineState *spapr, 
> PowerPCCPU *cpu,
>  cpu_ppc_set_papr(cpu, PPC_VIRTUAL_HYPERVISOR(spapr));
>  
>  qemu_register_reset(spapr_cpu_reset, cpu);
> -spapr_cpu_reset(cpu);
> +
> +/* CPU must not execute anything until explicitely started otherwise the
> + * guest will crash.
> + */
> +CPU(cpu)->halted = 1;

And poking specifics in a CPU that hasn't already been set to a known
state by a reset also worries me.

>  }
>  
>  /*
> diff --git a/include/hw/ppc/spapr_cpu_core.h b/include/hw/ppc/spapr_cpu_core.h
> index 1129f344aa0c..763a2168461e 100644
> --- a/include/hw/ppc/spapr_cpu_core.h
> +++ b/include/hw/ppc/spapr_cpu_core.h
> @@ -38,4 +38,6 @@ typedef struct sPAPRCPUCoreClass {
>  } sPAPRCPUCoreClass;
>  
>  const char *spapr_get_cpu_core_type(const char *cpu_type);
> +void spapr_cpu_reset(void *opaque);
> +
>  #endif
> 

-- 
David Gibson| I'll have my music baroque, and my code
david AT gibson.dropbear.id.au  | minimalist, thank you.  NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson


signature.asc
Description: PGP signature

[Qemu-devel] [PATCH qemu] spapr_pci: Alias MMIO windows to PHB address space

[Alexey Kardashevskiy]

At the moment the sPAPR PHB MMIO space does not have an address space
object as it does not really need one - guest accesses it via virtual
addresses (and we provide mappings to the CPU space), the device drivers
in QEMU access MMIO directly (as they own MRs). The only case when
a driver in QEMU might need an address space (AS) is DMA so we provide one
with only IOMMUs on it.

So PHB AS looks like:
address-space: pci@8002000
  - (prio 0, i/o): 
pci@8002000.iommu-root
- (prio 0, i/o): tce-root-8001
  0800-08007fff (prio 0, i/o): tce-iommu-8001
- (prio 0, i/o): tce-root-8000
  -3fff (prio 0, i/o): tce-iommu-8000
0400-0400 (prio 0, i/o): msi

with no mention of any PCI device, and so does the flatview:

 FlatView #2
  AS "pci@8002000", root: pci@8002000.iommu-root
  AS "nec-usb-xhci", root: bus master container
  Root memory region: pci@8002000.iommu-root
   -3fff (prio 0, i/o): tce-iommu-8000

This adds 2 more aliases (for MMIO32 and MMIO64 windows) on PHB AS so
whatever appears on the bus can be seen in "info mtree [-f]".

Here are the chunks from "diff" for a QEMU with an emulater XHCI adapter:

 address-space: pci@8002000
   - (prio 0, i/o): 
pci@8002000.iommu-root
 - (prio 0, i/o): tce-root-8001
   0800-08007fff (prio 0, i/o): tce-iommu-8001
 - (prio 0, i/o): tce-root-8000
   -3fff (prio 0, i/o): tce-iommu-8000
+8000- (prio 0, i/o): alias 
pci@8002000.mmio32-alias-pci @pci@8002000.mmio3
+2-alias -7fff
 0400-0400 (prio 0, i/o): msi
+2100-21ff (prio 0, i/o): alias 
pci@8002000.mmio64-alias-pci @pci@8002000.mmio6
+4-alias -00ff


 FlatView #2
  AS "pci@8002000", root: pci@8002000.iommu-root
  AS "nec-usb-xhci", root: bus master container
  Root memory region: pci@8002000.iommu-root
   -3fff (prio 0, i/o): tce-iommu-8000
+  8000-803f (prio 0, i/o): capabilities
+  8040-843f (prio 0, i/o): operational
+  8440-844f (prio 0, i/o): usb3 port #1
+  8450-845f (prio 0, i/o): usb3 port #2
+  8460-846f (prio 0, i/o): usb3 port #3
+  8470-847f (prio 0, i/o): usb3 port #4
+  8480-848f (prio 0, i/o): usb2 port #1
+  8490-849f (prio 0, i/o): usb2 port #2
+  84a0-84af (prio 0, i/o): usb2 port #3
+  84b0-84bf (prio 0, i/o): usb2 port #4
+  80001000-8000121f (prio 0, i/o): runtime
+  80002000-8000281f (prio 0, i/o): doorbell
+  80003000-800030ff (prio 0, i/o): msix-table
+  80003800-80003807 (prio 0, i/o): msix-pba
   0400-0400 (prio 0, i/o): msi
   0800-08007fff (prio 0, i/o): tce-iommu-8001

The major point for this is to help debugging overlapped regions.

Signed-off-by: Alexey Kardashevskiy 
---

Should not we do this in the common code really?
Does this look useful at all? I was quite confused when I realized that
I do not see an AS with DMA windows and MMIO while they co-exist
on a bus.


---
 include/hw/pci-host/spapr.h |  1 +
 hw/ppc/spapr_pci.c  | 12 
 2 files changed, 13 insertions(+)

diff --git a/include/hw/pci-host/spapr.h b/include/hw/pci-host/spapr.h
index 0fae4fc..4550192 100644
--- a/include/hw/pci-host/spapr.h
+++ b/include/hw/pci-host/spapr.h
@@ -57,6 +57,7 @@ struct sPAPRPHBState {
 uint64_t mem64_win_pciaddr;
 hwaddr io_win_addr, io_win_size;
 MemoryRegion mem32window, mem64window, iowindow, msiwindow;
+MemoryRegion mem32windowpci, mem64windowpci;
 
 uint32_t dma_liobn[SPAPR_PCI_DMA_MAX_WINDOWS];
 hwaddr dma_win_addr, dma_win_size;
diff --git a/hw/ppc/spapr_pci.c b/hw/ppc/spapr_pci.c
index 37f18b3..d142f74 100644
--- a/hw/ppc/spapr_pci.c
+++ b/hw/ppc/spapr_pci.c
@@ -1642,6 +1642,18 @@ static void spapr_phb_realize(DeviceState *dev, Error 
**errp)
 address_space_init(>iommu_as, >iommu_root,
sphb->dtbusname);
 
+/* Map memory space onto the PHB address space */
+namebuf = g_strdup_printf("%s.mmio32-alias-pci", sphb->dtbusname);
+memory_region_init_alias(>mem32windowpci, OBJECT(sphb), namebuf,
+ >mem32window, 0, sphb->mem_win_size);
+

[Qemu-devel] [PATCH] scsi-generic: Simplify error handling code

[Fam Zheng]

Coverity doesn't like the ignored return value introduced in
9d3b155186c278 (hw/block: Fix the return type), and other callers are
converted already in ceff3e1f01.

This one was added lately in d9bcd6f7f23a and missed the train. Do it
now.

Signed-off-by: Fam Zheng 
---
 hw/scsi/scsi-generic.c | 9 +++--
 1 file changed, 3 insertions(+), 6 deletions(-)

diff --git a/hw/scsi/scsi-generic.c b/hw/scsi/scsi-generic.c
index ba70c0dc19..7414fe2d67 100644
--- a/hw/scsi/scsi-generic.c
+++ b/hw/scsi/scsi-generic.c
@@ -482,7 +482,6 @@ static void scsi_generic_realize(SCSIDevice *s, Error 
**errp)
 int rc;
 int sg_version;
 struct sg_scsi_id scsiid;
-Error *local_err = NULL;
 
 if (!s->conf.blk) {
 error_setg(errp, "drive property not set");
@@ -516,11 +515,9 @@ static void scsi_generic_realize(SCSIDevice *s, Error 
**errp)
 error_setg(errp, "SG_GET_SCSI_ID ioctl failed");
 return;
 }
-blkconf_apply_backend_options(>conf,
-  blk_is_read_only(s->conf.blk),
-  true, _err);
-if (local_err) {
-error_propagate(errp, local_err);
+if (!blkconf_apply_backend_options(>conf,
+   blk_is_read_only(s->conf.blk),
+   true, errp)) {
 return;
 }
 
-- 
2.14.3

Re: [Qemu-devel] [PATCH RESEND v1 1/2] i386: Add Intel Processor Trace feature support

[Eduardo Habkost]

On Wed, Jan 17, 2018 at 10:32:56AM +, Kang, Luwei wrote:
> > > > > On Mon, Jan 15, 2018 at 12:04:55 -0200, Eduardo Habkost wrote:
> > > > > > CCing libvirt developers.
> > > > > ...
> > > > > > This case is slightly more problematic, however: the new feature
> > > > > > is actually migratable (under very controlled circumstances)
> > > > > > because of patch 2/2, but it is not migration-safe[1].  This
> > > > > > means libvirt shouldn't include it in "host-model" expansion
> > > > > > (which uses the query-cpu-model-expansion QMP command) until we
> > > > > > make the feature migration-safe.
> > > > > >
> > > > > > For QEMU, this means the feature shouldn't be returned by
> > > > > > "query-cpu-model-expansion type=static model=max" (but it can be
> > > > > > returned by "query-cpu-model-expansion type=full model=max").
> > > > > >
> > > > > > Jiri, it looks like libvirt uses type=full on
> > > > > > query-cpu-model-expansion on x86.  It needs to use
> > > > > > type=static[2], or it will have no way to find out if a feature
> > > > > > is migration-safe or not.
> > > > > ...
> > > > > > [2] It looks like libvirt uses type=full because it wants to get
> > > > > > all QOM property aliases returned.  In this case, one
> > > > > > solution for libvirt is to use:
> > > > > >
> > > > > > static_expansion = query_cpu_model_expansion(type=static, model)
> > > > > > all_props = query_cpu_model_expansion(type=full,
> > > > > > static_expansion)
> > > > >
> > > > > This is exactly what libvirt is doing (with model = "host") ever
> > > > > since query-cpu-model-expansion support was implemented for x86.
> > > >
> > > > Oh, now I see that the x86 code uses
> > > > QEMU_MONITOR_CPU_MODEL_EXPANSION_STATIC_FULL and not just 
> > > > QEMU_MONITOR_CPU_MODEL_EXPANSION_FULL.
> > Nice!
> > > >
> > >
> > > So, I need to add Intel PT feature in "X86CPUDefinition
> > > builtin_x86_defs[]" so that we can get this CPUID in specific CPU
> > > model not only "-cpu host". Is that right?
> > 
> > The problem is that you won't be able to add intel-pt to any CPU model 
> > unless the feature is made migration-safe (by not calling
> > kvm_arch_get_supported_cpuid() from cpu_x86_cpuid()).
> 
> Hi Eduardo,
> Have some question need you help clear. What is
> "migration-safe" feature mean? I find all the feature which
> included in CPU model (builtin_x86_defs[]) will make
> "xcc->migration_safe = true;" in
> x86_cpu_cpudef_class_init(). If create a Skylake guest on
> Skylake HW and live migrate this guest to another machine
> with old HW(e.g Haswell). Can we think the new feature or
> cpu model(Skylake guest) which only supported in Skylake HW
> is safe?

I mean matching the requirements so we can say the feature is migration-safe,
that means exposing the same CPUID data to the guest on any host, if the
machine-type + command-line is the same.  The data on CPUID[7] is OK (it
changes according to the command-line options only), but the data exposed on
CPUID[14h] on this patch is not migration-safe (it changes depending on the
host it is running).


> 
> > 
> > What's missing here is to either: (a) make cpu_x86_cpuid() return 
> > host-independent data (it can be constant, or it can be
> > configurable on the command-line); or (b) add a mechanism to skip intel-pt 
> > from "query-cpu-model-expansion type=static".
> 
> ==> it can be constant:
> I think it shouldn't be constant because Intel PT virtualization can only 
> supported in Ice Lake hardware now. Intel PT cpuid info would be mask off on 
> old platform.
> ==> or it can be configurable on the command-line:
> Because of I didn't add this feature in any CPU model. We only can enable 
> this feature by "-cpu Skylake-Server,+intel-pt" at present.

Note that I'm talking about CPUID[14h], not CPUID[7].  The CPUID[7] bits are
safe because they are set according to the CPU model + command-line options
only.  The bits on CPUID[14h] change depending on the host and are not
migration-safe.  CPUID[7].EBX[bit 25] is just the (already configurable) bit
that enables the migration-unsafe code for CPUID[14h].

> 
> What about add a new cpu model name "Icelake" and add PT in this. Is that 
> would be migration safe?

It won't, because of the CPUID[14h] code that makes it unsafe to migrate
between hosts with different Intel-PT capabilities (i.e. different data on
CPUID[14h]).


> 
> Thanks,
> Luwei Kang
> 
> > Probably
> > (a) is easier to implement, and it also makes the feature more useful (by 
> > making it migration-safe).
> > 
> > >
> > > Intel PT is first supported in Intel Core M and 5th generation Intel
> > > Core processors that are based on the Intel micro-architecture code
> > > name Broadwell but Intel PT use EPT is first supported in Ice Lake.
> > > Intel PT virtualization depend on PT use EPT.  I will add Intel PT to
> > > "Broadwell" CPU model and later to make sure a "Broadwell" guest can
> > > use Intel PT if the host is Ice 

[Qemu-devel] [PULL 6/6] nbd/server: structurize option reply sending

[Eric Blake]

From: Vladimir Sementsov-Ogievskiy 

Signed-off-by: Vladimir Sementsov-Ogievskiy 
Reviewed-by: Eric Blake 
Message-Id: <20171122101958.17065-6-vsement...@virtuozzo.com>
Signed-off-by: Eric Blake 
---
 nbd/server.c | 40 +---
 1 file changed, 13 insertions(+), 27 deletions(-)

diff --git a/nbd/server.c b/nbd/server.c
index 78b08f58913..6caa8d17be7 100644
--- a/nbd/server.c
+++ b/nbd/server.c
@@ -137,43 +137,29 @@ static void nbd_client_receive_next_request(NBDClient 
*client);

 */

+static inline void set_be_option_rep(NBDOptionReply *rep, uint32_t option,
+ uint32_t type, uint32_t length)
+{
+stq_be_p(>magic, NBD_REP_MAGIC);
+stl_be_p(>option, option);
+stl_be_p(>type, type);
+stl_be_p(>length, length);
+}
+
 /* Send a reply header, including length, but no payload.
  * Return -errno on error, 0 on success. */
 static int nbd_negotiate_send_rep_len(NBDClient *client, uint32_t type,
   uint32_t len, Error **errp)
 {
-uint64_t magic;
-QIOChannel *ioc = client->ioc;
-uint32_t opt = client->opt;
+NBDOptionReply rep;

-trace_nbd_negotiate_send_rep_len(opt, nbd_opt_lookup(opt),
+trace_nbd_negotiate_send_rep_len(client->opt, nbd_opt_lookup(client->opt),
  type, nbd_rep_lookup(type), len);

 assert(len < NBD_MAX_BUFFER_SIZE);
-magic = cpu_to_be64(NBD_REP_MAGIC);
-if (nbd_write(ioc, , sizeof(magic), errp) < 0) {
-error_prepend(errp, "write failed (rep magic): ");
-return -EINVAL;
-}

-opt = cpu_to_be32(opt);
-if (nbd_write(ioc, , sizeof(opt), errp) < 0) {
-error_prepend(errp, "write failed (rep opt): ");
-return -EINVAL;
-}
-
-type = cpu_to_be32(type);
-if (nbd_write(ioc, , sizeof(type), errp) < 0) {
-error_prepend(errp, "write failed (rep type): ");
-return -EINVAL;
-}
-
-len = cpu_to_be32(len);
-if (nbd_write(ioc, , sizeof(len), errp) < 0) {
-error_prepend(errp, "write failed (rep data length): ");
-return -EINVAL;
-}
-return 0;
+set_be_option_rep(, client->opt, type, len);
+return nbd_write(client->ioc, , sizeof(rep), errp);
 }

 /* Send a reply header with default 0 length.
-- 
2.14.3

[Qemu-devel] [PULL 4/6] nbd/server: Add va_list form of nbd_negotiate_send_rep_err()

[Eric Blake]

This will be useful for the next patch.

Based on a patch by Vladimir Sementsov-Ogievskiy

Signed-off-by: Eric Blake 
Reviewed-by: Vladimir Sementsov-Ogievskiy 
Message-Id: <20180110230825.18321-5-ebl...@redhat.com>
---
 nbd/server.c | 24 ++--
 1 file changed, 18 insertions(+), 6 deletions(-)

diff --git a/nbd/server.c b/nbd/server.c
index 31c1d324297..04da1c2f1e1 100644
--- a/nbd/server.c
+++ b/nbd/server.c
@@ -186,18 +186,15 @@ static int nbd_negotiate_send_rep(NBDClient *client, 
uint32_t type,

 /* Send an error reply.
  * Return -errno on error, 0 on success. */
-static int GCC_FMT_ATTR(4, 5)
-nbd_negotiate_send_rep_err(NBDClient *client, uint32_t type,
-   Error **errp, const char *fmt, ...)
+static int GCC_FMT_ATTR(4, 0)
+nbd_negotiate_send_rep_verr(NBDClient *client, uint32_t type,
+Error **errp, const char *fmt, va_list va)
 {
-va_list va;
 char *msg;
 int ret;
 size_t len;

-va_start(va, fmt);
 msg = g_strdup_vprintf(fmt, va);
-va_end(va);
 len = strlen(msg);
 assert(len < 4096);
 trace_nbd_negotiate_send_rep_err(msg);
@@ -217,6 +214,21 @@ out:
 return ret;
 }

+/* Send an error reply.
+ * Return -errno on error, 0 on success. */
+static int GCC_FMT_ATTR(4, 5)
+nbd_negotiate_send_rep_err(NBDClient *client, uint32_t type,
+   Error **errp, const char *fmt, ...)
+{
+va_list va;
+int ret;
+
+va_start(va, fmt);
+ret = nbd_negotiate_send_rep_verr(client, type, errp, fmt, va);
+va_end(va);
+return ret;
+}
+
 /* Send a single NBD_REP_SERVER reply to NBD_OPT_LIST, including payload.
  * Return -errno on error, 0 on success. */
 static int nbd_negotiate_send_rep_list(NBDClient *client, NBDExport *exp,
-- 
2.14.3

[Qemu-devel] [PULL 1/6] nbd/server: Hoist nbd_reject_length() earlier

[Eric Blake]

No semantic change, but will make it easier for an upcoming patch
to refactor code without having to add forward declarations.  Fix
a poor comment while at it.

Signed-off-by: Eric Blake 
Reviewed-by: Vladimir Sementsov-Ogievskiy 
Message-Id: <20180110230825.18321-2-ebl...@redhat.com>
---
 nbd/server.c | 58 +-
 1 file changed, 29 insertions(+), 29 deletions(-)

diff --git a/nbd/server.c b/nbd/server.c
index 6cf2eeb2c1a..5ba12f3c0b3 100644
--- a/nbd/server.c
+++ b/nbd/server.c
@@ -1,5 +1,5 @@
 /*
- *  Copyright (C) 2016-2017 Red Hat, Inc.
+ *  Copyright (C) 2016-2018 Red Hat, Inc.
  *  Copyright (C) 2005  Anthony Liguori 
  *
  *  Network Block Device Server Side
@@ -348,6 +348,34 @@ static int nbd_negotiate_send_info(NBDClient *client, 
uint32_t opt,
 return 0;
 }

+/* nbd_reject_length: Handle any unexpected payload.
+ * @fatal requests that we quit talking to the client, even if we are able
+ * to successfully send an error reply.
+ * Return:
+ * -errno  transmission error occurred or @fatal was requested, errp is set
+ * 0   error message successfully sent to client, errp is not set
+ */
+static int nbd_reject_length(NBDClient *client, uint32_t length,
+ uint32_t option, bool fatal, Error **errp)
+{
+int ret;
+
+assert(length);
+if (nbd_drop(client->ioc, length, errp) < 0) {
+return -EIO;
+}
+ret = nbd_negotiate_send_rep_err(client->ioc, NBD_REP_ERR_INVALID,
+ option, errp,
+ "option '%s' should have zero length",
+ nbd_opt_lookup(option));
+if (fatal && !ret) {
+error_setg(errp, "option '%s' should have zero length",
+   nbd_opt_lookup(option));
+return -EINVAL;
+}
+return ret;
+}
+
 /* Handle NBD_OPT_INFO and NBD_OPT_GO.
  * Return -errno on error, 0 if ready for next option, and 1 to move
  * into transmission phase.  */
@@ -570,34 +598,6 @@ static QIOChannel *nbd_negotiate_handle_starttls(NBDClient 
*client,
 return QIO_CHANNEL(tioc);
 }

-/* nbd_reject_length: Handle any unexpected payload.
- * @fatal requests that we quit talking to the client, even if we are able
- * to successfully send an error to the guest.
- * Return:
- * -errno  transmission error occurred or @fatal was requested, errp is set
- * 0   error message successfully sent to client, errp is not set
- */
-static int nbd_reject_length(NBDClient *client, uint32_t length,
- uint32_t option, bool fatal, Error **errp)
-{
-int ret;
-
-assert(length);
-if (nbd_drop(client->ioc, length, errp) < 0) {
-return -EIO;
-}
-ret = nbd_negotiate_send_rep_err(client->ioc, NBD_REP_ERR_INVALID,
- option, errp,
- "option '%s' should have zero length",
- nbd_opt_lookup(option));
-if (fatal && !ret) {
-error_setg(errp, "option '%s' should have zero length",
-   nbd_opt_lookup(option));
-return -EINVAL;
-}
-return ret;
-}
-
 /* nbd_negotiate_options
  * Process all NBD_OPT_* client option commands, during fixed newstyle
  * negotiation.
-- 
2.14.3

[Qemu-devel] [PULL 5/6] nbd/server: Add helper functions for parsing option payload

[Eric Blake]

Rather than making every callsite perform length sanity checks
and error reporting, add the helper functions nbd_opt_read()
and nbd_opt_drop() that use the length stored in the client
struct; also add an assertion that optlen is 0 before any
option (ie. any previous option was fully handled), complementing
the assertion added in an earlier patch that optlen is 0 after
all negotiation completes.

Note that the call in nbd_negotiate_handle_export_name() does
not use the new helper (in part because the server cannot
reply to NBD_OPT_EXPORT_NAME - it either succeeds or the
connection drops).

Based on patches by Vladimir Sementsov-Ogievskiy.

Signed-off-by: Eric Blake 
Reviewed-by: Vladimir Sementsov-Ogievskiy 
Message-Id: <20180110230825.18321-6-ebl...@redhat.com>
---
 nbd/server.c | 122 ++-
 1 file changed, 62 insertions(+), 60 deletions(-)

diff --git a/nbd/server.c b/nbd/server.c
index 04da1c2f1e1..78b08f58913 100644
--- a/nbd/server.c
+++ b/nbd/server.c
@@ -229,6 +229,40 @@ nbd_negotiate_send_rep_err(NBDClient *client, uint32_t 
type,
 return ret;
 }

+/* Drop remainder of the current option, and send a reply with the
+ * given error type and message. Return -errno on read or write
+ * failure; or 0 if connection is still live. */
+static int GCC_FMT_ATTR(4, 5)
+nbd_opt_drop(NBDClient *client, uint32_t type, Error **errp,
+ const char *fmt, ...)
+{
+int ret = nbd_drop(client->ioc, client->optlen, errp);
+va_list va;
+
+client->optlen = 0;
+if (!ret) {
+va_start(va, fmt);
+ret = nbd_negotiate_send_rep_verr(client, type, errp, fmt, va);
+va_end(va);
+}
+return ret;
+}
+
+/* Read size bytes from the unparsed payload of the current option.
+ * Return -errno on I/O error, 0 if option was completely handled by
+ * sending a reply about inconsistent lengths, or 1 on success. */
+static int nbd_opt_read(NBDClient *client, void *buffer, size_t size,
+Error **errp)
+{
+if (size > client->optlen) {
+return nbd_opt_drop(client, NBD_REP_ERR_INVALID, errp,
+"Inconsistent lengths in option %s",
+nbd_opt_lookup(client->opt));
+}
+client->optlen -= size;
+return qio_channel_read_all(client->ioc, buffer, size, errp) < 0 ? -EIO : 
1;
+}
+
 /* Send a single NBD_REP_SERVER reply to NBD_OPT_LIST, including payload.
  * Return -errno on error, 0 on success. */
 static int nbd_negotiate_send_rep_list(NBDClient *client, NBDExport *exp,
@@ -378,14 +412,11 @@ static int nbd_reject_length(NBDClient *client, bool 
fatal, Error **errp)
 int ret;

 assert(client->optlen);
-if (nbd_drop(client->ioc, client->optlen, errp) < 0) {
-return -EIO;
-}
-ret = nbd_negotiate_send_rep_err(client, NBD_REP_ERR_INVALID, errp,
- "option '%s' should have zero length",
- nbd_opt_lookup(client->opt));
+ret = nbd_opt_drop(client, NBD_REP_ERR_INVALID, errp,
+   "option '%s' has unexpected length",
+   nbd_opt_lookup(client->opt));
 if (fatal && !ret) {
-error_setg(errp, "option '%s' should have zero length",
+error_setg(errp, "option '%s' has unexpected length",
nbd_opt_lookup(client->opt));
 return -EINVAL;
 }
@@ -408,7 +439,6 @@ static int nbd_negotiate_handle_info(NBDClient *client, 
uint16_t myflags,
 bool blocksize = false;
 uint32_t sizes[3];
 char buf[sizeof(uint64_t) + sizeof(uint16_t)];
-const char *msg;

 /* Client sends:
 4 bytes: L, name length (can be 0)
@@ -416,48 +446,34 @@ static int nbd_negotiate_handle_info(NBDClient *client, 
uint16_t myflags,
 2 bytes: N, number of requests (can be 0)
 N * 2 bytes: N requests
 */
-if (client->optlen < sizeof(namelen) + sizeof(requests)) {
-msg = "overall request too short";
-goto invalid;
-}
-if (nbd_read(client->ioc, , sizeof(namelen), errp) < 0) {
-return -EIO;
+rc = nbd_opt_read(client, , sizeof(namelen), errp);
+if (rc <= 0) {
+return rc;
 }
 be32_to_cpus();
-client->optlen -= sizeof(namelen);
-if (namelen > client->optlen - sizeof(requests) ||
-(client->optlen - namelen) % 2)
-{
-msg = "name length is incorrect";
-goto invalid;
-}
 if (namelen >= sizeof(name)) {
-msg = "name too long for qemu";
-goto invalid;
+return nbd_opt_drop(client, NBD_REP_ERR_INVALID, errp,
+"name too long for qemu");
 }
-if (nbd_read(client->ioc, name, namelen, errp) < 0) {
-return -EIO;
+rc = nbd_opt_read(client, name, namelen, errp);
+if (rc <= 0) {
+return rc;
 }
 name[namelen] = '\0';
-client->optlen -= namelen;
 

[Qemu-devel] [PULL 15/19] hostmem-file: add "align" option

[Eduardo Habkost]

From: Haozhong Zhang 

When mmap(2) the backend files, QEMU uses the host page size
(getpagesize(2)) by default as the alignment of mapping address.
However, some backends may require alignments different than the page
size. For example, mmap a device DAX (e.g., /dev/dax0.0) on Linux
kernel 4.13 to an address, which is 4K-aligned but not 2M-aligned,
fails with a kernel message like

[617494.969768] dax dax0.0: qemu-system-x86: dax_mmap: fail, unaligned vma 
(0x7fa37c579000 - 0x7fa43c579000, 0x1f)

Because there is no common approach to get such alignment requirement,
we add the 'align' option to 'memory-backend-file', so that users or
management utils, which have enough knowledge about the backend, can
specify a proper alignment via this option.

Signed-off-by: Haozhong Zhang 
Message-Id: <20171211072806.2812-2-haozhong.zh...@intel.com>
Reviewed-by: Michael S. Tsirkin 
Reviewed-by: Stefan Hajnoczi 
Signed-off-by: Eduardo Habkost 
---
 docs/nvdimm.txt | 16 
 include/exec/memory.h   |  3 +++
 backends/hostmem-file.c | 41 -
 exec.c  |  8 +++-
 memory.c|  2 ++
 numa.c  |  2 +-
 qemu-options.hx |  9 -
 7 files changed, 77 insertions(+), 4 deletions(-)

diff --git a/docs/nvdimm.txt b/docs/nvdimm.txt
index 2d9f8c0e8c..21249dd062 100644
--- a/docs/nvdimm.txt
+++ b/docs/nvdimm.txt
@@ -122,3 +122,19 @@ Note:
  M >= size of RAM devices +
   size of statically plugged vNVDIMM devices +
   size of hotplugged vNVDIMM devices
+
+Alignment
+-
+
+QEMU uses mmap(2) to maps vNVDIMM backends and aligns the mapping
+address to the page size (getpagesize(2)) by default. However, some
+types of backends may require an alignment different than the page
+size. In that case, QEMU v2.12.0 and later provide 'align' option to
+memory-backend-file to allow users to specify the proper alignment.
+
+For example, device dax require the 2 MB alignment, so we can use
+following QEMU command line options to use it (/dev/dax0.0) as the
+backend of vNVDIMM:
+
+ -object 
memory-backend-file,id=mem1,share=on,mem-path=/dev/dax0.0,size=4G,align=2M
+ -device nvdimm,id=nvdimm1,memdev=mem1
diff --git a/include/exec/memory.h b/include/exec/memory.h
index a4cabdf44c..07c5d6d597 100644
--- a/include/exec/memory.h
+++ b/include/exec/memory.h
@@ -465,6 +465,8 @@ void memory_region_init_resizeable_ram(MemoryRegion *mr,
  * @name: Region name, becomes part of RAMBlock name used in migration stream
  *must be unique within any device
  * @size: size of the region.
+ * @align: alignment of the region base address; if 0, the default alignment
+ * (getpagesize()) will be used.
  * @share: %true if memory must be mmaped with the MAP_SHARED flag
  * @path: the path in which to allocate the RAM.
  * @errp: pointer to Error*, to store an error if it happens.
@@ -476,6 +478,7 @@ void memory_region_init_ram_from_file(MemoryRegion *mr,
   struct Object *owner,
   const char *name,
   uint64_t size,
+  uint64_t align,
   bool share,
   const char *path,
   Error **errp);
diff --git a/backends/hostmem-file.c b/backends/hostmem-file.c
index e44c319915..e319ec1ad8 100644
--- a/backends/hostmem-file.c
+++ b/backends/hostmem-file.c
@@ -34,6 +34,7 @@ struct HostMemoryBackendFile {
 bool share;
 bool discard_data;
 char *mem_path;
+uint64_t align;
 };
 
 static void
@@ -58,7 +59,7 @@ file_backend_memory_alloc(HostMemoryBackend *backend, Error 
**errp)
 path = object_get_canonical_path(OBJECT(backend));
 memory_region_init_ram_from_file(>mr, OBJECT(backend),
  path,
- backend->size, fb->share,
+ backend->size, fb->align, fb->share,
  fb->mem_path, errp);
 g_free(path);
 }
@@ -115,6 +116,40 @@ static void file_memory_backend_set_discard_data(Object 
*o, bool value,
 MEMORY_BACKEND_FILE(o)->discard_data = value;
 }
 
+static void file_memory_backend_get_align(Object *o, Visitor *v,
+  const char *name, void *opaque,
+  Error **errp)
+{
+HostMemoryBackendFile *fb = MEMORY_BACKEND_FILE(o);
+uint64_t val = fb->align;
+
+visit_type_size(v, name, , errp);
+}
+
+static void file_memory_backend_set_align(Object *o, Visitor *v,
+  const char *name, void *opaque,
+  Error **errp)
+{
+HostMemoryBackend 

[Qemu-devel] [PULL 12/19] qdev_monitor: Simplify error handling in qdev_device_add()

[Eduardo Habkost]

From: Thomas Huth 

Instead of doing the clean-ups on errors multiple times, introduce
a jump label at the end of the function that can be used by all
error paths that need this cleanup.

Suggested-by: Igor Mammedov 
Signed-off-by: Thomas Huth 
Message-Id: <1509617407-21191-2-git-send-email-th...@redhat.com>
Reviewed-by: Cornelia Huck 
Signed-off-by: Eduardo Habkost 
---
 qdev-monitor.c | 16 
 1 file changed, 8 insertions(+), 8 deletions(-)

diff --git a/qdev-monitor.c b/qdev-monitor.c
index b4abb4b5ea..2abb80d7e4 100644
--- a/qdev-monitor.c
+++ b/qdev-monitor.c
@@ -619,22 +619,22 @@ DeviceState *qdev_device_add(QemuOpts *opts, Error **errp)
 
 /* set properties */
 if (qemu_opt_foreach(opts, set_property, dev, )) {
-error_propagate(errp, err);
-object_unparent(OBJECT(dev));
-object_unref(OBJECT(dev));
-return NULL;
+goto err_del_dev;
 }
 
 dev->opts = opts;
 object_property_set_bool(OBJECT(dev), true, "realized", );
 if (err != NULL) {
-error_propagate(errp, err);
 dev->opts = NULL;
-object_unparent(OBJECT(dev));
-object_unref(OBJECT(dev));
-return NULL;
+goto err_del_dev;
 }
 return dev;
+
+err_del_dev:
+error_propagate(errp, err);
+object_unparent(OBJECT(dev));
+object_unref(OBJECT(dev));
+return NULL;
 }
 
 
-- 
2.14.3

[Qemu-devel] [PULL 3/6] nbd/server: Better error for NBD_OPT_EXPORT_NAME failure

[Eric Blake]

When a client abruptly disconnects before we've finished reading
the name sent with NBD_OPT_EXPORT_NAME, we are better off logging
the failure as EIO (we can't communicate with the client), rather
than EINVAL (the client sent bogus data).

Signed-off-by: Eric Blake 
Reviewed-by: Vladimir Sementsov-Ogievskiy 
Message-Id: <20180110230825.18321-4-ebl...@redhat.com>
---
 nbd/server.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/nbd/server.c b/nbd/server.c
index b9efdcc605d..31c1d324297 100644
--- a/nbd/server.c
+++ b/nbd/server.c
@@ -299,7 +299,7 @@ static int nbd_negotiate_handle_export_name(NBDClient 
*client,
 }
 if (nbd_read(client->ioc, name, client->optlen, errp) < 0) {
 error_prepend(errp, "read failed: ");
-return -EINVAL;
+return -EIO;
 }
 name[client->optlen] = '\0';
 client->optlen = 0;
-- 
2.14.3

[Qemu-devel] [PULL 13/19] qdev: Check for the availability of a hotplug controller before adding a device

[Eduardo Habkost]

From: Thomas Huth 

The qdev_unplug() function contains a g_assert(hotplug_ctrl) statement,
so QEMU crashes when the user tries to device_add + device_del a device
that does not have a corresponding hotplug controller. This could be
provoked for a couple of devices in the past (see commit 4c93950659487c7ad
or 84ebd3e8c7d4fe955 for example), and can currently for example also be
triggered like this:

$ s390x-softmmu/qemu-system-s390x -M none -nographic
QEMU 2.10.50 monitor - type 'help' for more information
(qemu) device_add qemu-s390x-cpu,id=x
(qemu) device_del x
**
ERROR:qemu/qdev-monitor.c:872:qdev_unplug: assertion failed: (hotplug_ctrl)
Aborted (core dumped)

So devices clearly need a hotplug controller when they should be usable
with device_add.
The code in qdev_device_add() already checks whether the bus has a proper
hotplug controller, but for devices that do not have a corresponding bus,
there is no appropriate check available yet. In that case we should check
whether the machine itself provides a suitable hotplug controller and
refuse to plug the device if none is available.

Reviewed-by: Igor Mammedov 
Signed-off-by: Thomas Huth 
Message-Id: <1509617407-21191-3-git-send-email-th...@redhat.com>
Reviewed-by: Cornelia Huck 
Signed-off-by: Eduardo Habkost 
---
 include/hw/qdev-core.h |  1 +
 hw/core/qdev.c | 28 
 qdev-monitor.c |  5 +
 3 files changed, 26 insertions(+), 8 deletions(-)

diff --git a/include/hw/qdev-core.h b/include/hw/qdev-core.h
index 0a71bf83f0..51473eee7b 100644
--- a/include/hw/qdev-core.h
+++ b/include/hw/qdev-core.h
@@ -286,6 +286,7 @@ DeviceState *qdev_try_create(BusState *bus, const char 
*name);
 void qdev_init_nofail(DeviceState *dev);
 void qdev_set_legacy_instance_id(DeviceState *dev, int alias_id,
  int required_for_version);
+HotplugHandler *qdev_get_machine_hotplug_handler(DeviceState *dev);
 HotplugHandler *qdev_get_hotplug_handler(DeviceState *dev);
 void qdev_unplug(DeviceState *dev, Error **errp);
 void qdev_simple_device_unplug_cb(HotplugHandler *hotplug_dev,
diff --git a/hw/core/qdev.c b/hw/core/qdev.c
index 2951a5..f739753e3a 100644
--- a/hw/core/qdev.c
+++ b/hw/core/qdev.c
@@ -253,19 +253,31 @@ void qdev_set_legacy_instance_id(DeviceState *dev, int 
alias_id,
 dev->alias_required_for_version = required_for_version;
 }
 
+HotplugHandler *qdev_get_machine_hotplug_handler(DeviceState *dev)
+{
+MachineState *machine;
+MachineClass *mc;
+Object *m_obj = qdev_get_machine();
+
+if (object_dynamic_cast(m_obj, TYPE_MACHINE)) {
+machine = MACHINE(m_obj);
+mc = MACHINE_GET_CLASS(machine);
+if (mc->get_hotplug_handler) {
+return mc->get_hotplug_handler(machine, dev);
+}
+}
+
+return NULL;
+}
+
 HotplugHandler *qdev_get_hotplug_handler(DeviceState *dev)
 {
-HotplugHandler *hotplug_ctrl = NULL;
+HotplugHandler *hotplug_ctrl;
 
 if (dev->parent_bus && dev->parent_bus->hotplug_handler) {
 hotplug_ctrl = dev->parent_bus->hotplug_handler;
-} else if (object_dynamic_cast(qdev_get_machine(), TYPE_MACHINE)) {
-MachineState *machine = MACHINE(qdev_get_machine());
-MachineClass *mc = MACHINE_GET_CLASS(machine);
-
-if (mc->get_hotplug_handler) {
-hotplug_ctrl = mc->get_hotplug_handler(machine, dev);
-}
+} else {
+hotplug_ctrl = qdev_get_machine_hotplug_handler(dev);
 }
 return hotplug_ctrl;
 }
diff --git a/qdev-monitor.c b/qdev-monitor.c
index 2abb80d7e4..c436616446 100644
--- a/qdev-monitor.c
+++ b/qdev-monitor.c
@@ -613,6 +613,11 @@ DeviceState *qdev_device_add(QemuOpts *opts, Error **errp)
 
 if (bus) {
 qdev_set_parent_bus(dev, bus);
+} else if (qdev_hotplug && !qdev_get_machine_hotplug_handler(dev)) {
+/* No bus, no machine hotplug handler --> device is not hotpluggable */
+error_setg(, "Device '%s' can not be hotplugged on this machine",
+   driver);
+goto err_del_dev;
 }
 
 qdev_set_id(dev, qemu_opts_id(opts));
-- 
2.14.3

[Qemu-devel] [PULL 2/6] nbd/server: refactor negotiation functions parameters

[Eric Blake]

From: Vladimir Sementsov-Ogievskiy 

Instead of passing currently negotiating option and its length to
many of negotiation functions let's just store them on NBDClient
struct to be state-variables of negotiation phase.

This unifies semantics of negotiation functions and allows
tracking changes of remaining option length in future patches.

Asssert that optlen is back to 0 after negotiation (including
old-style connections which don't negotiate), although we need
more patches before we can assert optlen is 0 between options
during negotiation.

Signed-off-by: Vladimir Sementsov-Ogievskiy 
Reviewed-by: Eric Blake 
Message-Id: <20171122101958.17065-2-vsement...@virtuozzo.com>
[eblake: rebase, commit message tweak, assert !optlen after
negotiation completes]
Signed-off-by: Eric Blake 
---
 nbd/server.c | 168 +--
 1 file changed, 84 insertions(+), 84 deletions(-)

diff --git a/nbd/server.c b/nbd/server.c
index 5ba12f3c0b3..b9efdcc605d 100644
--- a/nbd/server.c
+++ b/nbd/server.c
@@ -102,9 +102,11 @@ struct NBDClient {
 bool closing;

 bool structured_reply;
-};

-/* That's all folks */
+uint32_t opt; /* Current option being negotiated */
+uint32_t optlen; /* remaining length of data in ioc for the option being
+negotiated now */
+};

 static void nbd_client_receive_next_request(NBDClient *client);

@@ -137,10 +139,12 @@ static void nbd_client_receive_next_request(NBDClient 
*client);

 /* Send a reply header, including length, but no payload.
  * Return -errno on error, 0 on success. */
-static int nbd_negotiate_send_rep_len(QIOChannel *ioc, uint32_t type,
-  uint32_t opt, uint32_t len, Error **errp)
+static int nbd_negotiate_send_rep_len(NBDClient *client, uint32_t type,
+  uint32_t len, Error **errp)
 {
 uint64_t magic;
+QIOChannel *ioc = client->ioc;
+uint32_t opt = client->opt;

 trace_nbd_negotiate_send_rep_len(opt, nbd_opt_lookup(opt),
  type, nbd_rep_lookup(type), len);
@@ -174,17 +178,17 @@ static int nbd_negotiate_send_rep_len(QIOChannel *ioc, 
uint32_t type,

 /* Send a reply header with default 0 length.
  * Return -errno on error, 0 on success. */
-static int nbd_negotiate_send_rep(QIOChannel *ioc, uint32_t type, uint32_t opt,
+static int nbd_negotiate_send_rep(NBDClient *client, uint32_t type,
   Error **errp)
 {
-return nbd_negotiate_send_rep_len(ioc, type, opt, 0, errp);
+return nbd_negotiate_send_rep_len(client, type, 0, errp);
 }

 /* Send an error reply.
  * Return -errno on error, 0 on success. */
-static int GCC_FMT_ATTR(5, 6)
-nbd_negotiate_send_rep_err(QIOChannel *ioc, uint32_t type,
-   uint32_t opt, Error **errp, const char *fmt, ...)
+static int GCC_FMT_ATTR(4, 5)
+nbd_negotiate_send_rep_err(NBDClient *client, uint32_t type,
+   Error **errp, const char *fmt, ...)
 {
 va_list va;
 char *msg;
@@ -197,11 +201,11 @@ nbd_negotiate_send_rep_err(QIOChannel *ioc, uint32_t type,
 len = strlen(msg);
 assert(len < 4096);
 trace_nbd_negotiate_send_rep_err(msg);
-ret = nbd_negotiate_send_rep_len(ioc, type, opt, len, errp);
+ret = nbd_negotiate_send_rep_len(client, type, len, errp);
 if (ret < 0) {
 goto out;
 }
-if (nbd_write(ioc, msg, len, errp) < 0) {
+if (nbd_write(client->ioc, msg, len, errp) < 0) {
 error_prepend(errp, "write failed (error message): ");
 ret = -EIO;
 } else {
@@ -215,21 +219,21 @@ out:

 /* Send a single NBD_REP_SERVER reply to NBD_OPT_LIST, including payload.
  * Return -errno on error, 0 on success. */
-static int nbd_negotiate_send_rep_list(QIOChannel *ioc, NBDExport *exp,
+static int nbd_negotiate_send_rep_list(NBDClient *client, NBDExport *exp,
Error **errp)
 {
 size_t name_len, desc_len;
 uint32_t len;
 const char *name = exp->name ? exp->name : "";
 const char *desc = exp->description ? exp->description : "";
+QIOChannel *ioc = client->ioc;
 int ret;

 trace_nbd_negotiate_send_rep_list(name, desc);
 name_len = strlen(name);
 desc_len = strlen(desc);
 len = name_len + desc_len + sizeof(len);
-ret = nbd_negotiate_send_rep_len(ioc, NBD_REP_SERVER, NBD_OPT_LIST, len,
- errp);
+ret = nbd_negotiate_send_rep_len(client, NBD_REP_SERVER, len, errp);
 if (ret < 0) {
 return ret;
 }
@@ -258,20 +262,21 @@ static int nbd_negotiate_send_rep_list(QIOChannel *ioc, 
NBDExport *exp,
 static int nbd_negotiate_handle_list(NBDClient *client, Error **errp)
 {
 NBDExport *exp;
+assert(client->opt == NBD_OPT_LIST);

 /* For each export, send a NBD_REP_SERVER reply. */
 

[Qemu-devel] [PULL 0/6] NBD patches through 17 Jan

[Eric Blake]

The following changes since commit 8e5dc9ba49743b46d955ec7dacb04e42ae7ada7c:

  Merge remote-tracking branch 'remotes/rth/tags/pull-tcg-20180116' into 
staging (2018-01-16 17:36:39 +)

are available in the Git repository at:

  git://repo.or.cz/qemu/ericb.git tags/pull-nbd-2018-01-17

for you to fetch changes up to 1d17922a28f5b9a8adcea3c93f49086e0a751e86:

  nbd/server: structurize option reply sending (2018-01-17 20:14:12 -0600)

I'm still waiting for v3 of Vladimir's "0/6 nbd export qmp interface",
but it's been a week since my last pull, so it's worth flushing the queue.


pull-nbd-2018-01-17

- Vladimir Sementsov-Ogievskiy/Eric Blake: 0/6 NBD server refactoring


Eric Blake (4):
  nbd/server: Hoist nbd_reject_length() earlier
  nbd/server: Better error for NBD_OPT_EXPORT_NAME failure
  nbd/server: Add va_list form of nbd_negotiate_send_rep_err()
  nbd/server: Add helper functions for parsing option payload

Vladimir Sementsov-Ogievskiy (2):
  nbd/server: refactor negotiation functions parameters
  nbd/server: structurize option reply sending

 nbd/server.c | 342 +--
 1 file changed, 171 insertions(+), 171 deletions(-)

-- 
2.14.3

[Qemu-devel] [PULL 18/19] possible_cpus: add CPUArchId::type field

[Eduardo Habkost]

From: Igor Mammedov 

Remove dependency of possible_cpus on 1st CPU instance,
which decouples configuration data from CPU instances that
are created using that data.

Also later it would be used for enabling early cpu to numa node
configuration at runtime qmp_query_hotpluggable_cpus() should
provide a list of available cpu slots at early stage,
before machine_init() is called and the 1st cpu is created,
so that mgmt might be able to call it and use output to set
numa mapping.

Use MachineClass::possible_cpu_arch_ids() callback to set
cpu type info, along with the rest of possible cpu properties,
to let machine define which cpu type* will be used.

* for SPAPR it will be a spapr core type and for ARM/s390x/x86
  a respective descendant of CPUClass.

Move parse_numa_opts() in vl.c after cpu_model is parsed into
cpu_type so that possible_cpu_arch_ids() would know which
cpu_type to use during layout initialization.

Signed-off-by: Igor Mammedov 
Reviewed-by: David Gibson 
Message-Id: <1515597770-268979-1-git-send-email-imamm...@redhat.com>
Signed-off-by: Eduardo Habkost 
---
 include/hw/boards.h|  2 ++
 hw/arm/virt.c  |  3 ++-
 hw/core/machine.c  | 12 ++--
 hw/i386/pc.c   |  4 +++-
 hw/ppc/spapr.c | 13 -
 hw/s390x/s390-virtio-ccw.c |  1 +
 vl.c   |  3 +--
 7 files changed, 23 insertions(+), 15 deletions(-)

diff --git a/include/hw/boards.h b/include/hw/boards.h
index 041bc08971..efb0a9edfd 100644
--- a/include/hw/boards.h
+++ b/include/hw/boards.h
@@ -83,6 +83,7 @@ void machine_class_allow_dynamic_sysbus_dev(MachineClass *mc, 
const char *type);
  * CPUArchId:
  * @arch_id - architecture-dependent CPU ID of present or possible CPU
  * @cpu - pointer to corresponding CPU object if it's present on NULL otherwise
+ * @type - QOM class name of possible @cpu object
  * @props - CPU object properties, initialized by board
  * #vcpus_count - number of threads provided by @cpu object
  */
@@ -91,6 +92,7 @@ typedef struct {
 int64_t vcpus_count;
 CpuInstanceProperties props;
 Object *cpu;
+const char *type;
 } CPUArchId;
 
 /**
diff --git a/hw/arm/virt.c b/hw/arm/virt.c
index 4a6fdcc4f5..a4537af400 100644
--- a/hw/arm/virt.c
+++ b/hw/arm/virt.c
@@ -1359,7 +1359,7 @@ static void machvirt_init(MachineState *machine)
 break;
 }
 
-cpuobj = object_new(machine->cpu_type);
+cpuobj = object_new(possible_cpus->cpus[n].type);
 object_property_set_int(cpuobj, possible_cpus->cpus[n].arch_id,
 "mp-affinity", NULL);
 
@@ -1575,6 +1575,7 @@ static const CPUArchIdList 
*virt_possible_cpu_arch_ids(MachineState *ms)
   sizeof(CPUArchId) * max_cpus);
 ms->possible_cpus->len = max_cpus;
 for (n = 0; n < ms->possible_cpus->len; n++) {
+ms->possible_cpus->cpus[n].type = ms->cpu_type;
 ms->possible_cpus->cpus[n].arch_id =
 virt_cpu_mp_affinity(vms, n);
 ms->possible_cpus->cpus[n].props.has_thread_id = true;
diff --git a/hw/core/machine.c b/hw/core/machine.c
index 0320a8efa1..cdc1163dc6 100644
--- a/hw/core/machine.c
+++ b/hw/core/machine.c
@@ -377,18 +377,18 @@ static void machine_init_notify(Notifier *notifier, void 
*data)
 HotpluggableCPUList *machine_query_hotpluggable_cpus(MachineState *machine)
 {
 int i;
-Object *cpu;
 HotpluggableCPUList *head = NULL;
-const char *cpu_type;
+MachineClass *mc = MACHINE_GET_CLASS(machine);
+
+/* force board to initialize possible_cpus if it hasn't been done yet */
+mc->possible_cpu_arch_ids(machine);
 
-cpu = machine->possible_cpus->cpus[0].cpu;
-assert(cpu); /* Boot cpu is always present */
-cpu_type = object_get_typename(cpu);
 for (i = 0; i < machine->possible_cpus->len; i++) {
+Object *cpu;
 HotpluggableCPUList *list_item = g_new0(typeof(*list_item), 1);
 HotpluggableCPU *cpu_item = g_new0(typeof(*cpu_item), 1);
 
-cpu_item->type = g_strdup(cpu_type);
+cpu_item->type = g_strdup(machine->possible_cpus->cpus[i].type);
 cpu_item->vcpus_count = machine->possible_cpus->cpus[i].vcpus_count;
 cpu_item->props = g_memdup(>possible_cpus->cpus[i].props,
sizeof(*cpu_item->props));
diff --git a/hw/i386/pc.c b/hw/i386/pc.c
index 55686bf5d8..ccc50baa85 100644
--- a/hw/i386/pc.c
+++ b/hw/i386/pc.c
@@ -1148,7 +1148,8 @@ void pc_cpus_init(PCMachineState *pcms)
 pcms->apic_id_limit = x86_cpu_apic_id_from_index(max_cpus - 1) + 1;
 possible_cpus = mc->possible_cpu_arch_ids(ms);
 for (i = 0; i < smp_cpus; i++) {
-pc_new_cpu(ms->cpu_type, possible_cpus->cpus[i].arch_id, _fatal);
+pc_new_cpu(possible_cpus->cpus[i].type, possible_cpus->cpus[i].arch_id,
+   _fatal);
 }
 }
 
@@ -2307,6 +2308,7 @@ 

[Qemu-devel] [PULL 06/19] machine: Replace has_dynamic_sysbus with list of allowed devices

[Eduardo Habkost]

The existing has_dynamic_sysbus flag makes the machine accept
every user-creatable sysbus device type on the command-line.
Replace it with a list of allowed device types, so machines can
easily accept some sysbus devices while rejecting others.

To keep exactly the same behavior as before, the existing
has_dynamic_sysbus=true assignments are replaced with a
TYPE_SYS_BUS_DEVICE entry on the allowed list.  Other patches
will replace the TYPE_SYS_BUS_DEVICE entries with more specific
lists of devices.

Cc: Peter Maydell 
Cc: Marcel Apfelbaum 
Cc: "Michael S. Tsirkin" 
Cc: Alexander Graf 
Cc: David Gibson 
Cc: Stefano Stabellini 
Cc: Anthony Perard 
Cc: qemu-...@nongnu.org
Cc: qemu-...@nongnu.org
Cc: xen-de...@lists.xenproject.org
Signed-off-by: Eduardo Habkost 
Message-Id: <20171125151610.20547-2-ehabk...@redhat.com>
Reviewed-by: Greg Kurz 
Reviewed-by: David Gibson 
Reviewed-by: Marc-André Lureau 
Reviewed-by: Marcel Apfelbaum 
Signed-off-by: Eduardo Habkost 
---
 include/hw/boards.h  |  5 -
 hw/arm/virt.c|  3 ++-
 hw/core/machine.c| 43 +--
 hw/i386/pc_q35.c |  3 ++-
 hw/ppc/e500plat.c|  4 +++-
 hw/ppc/spapr.c   |  3 ++-
 hw/xen/xen_backend.c |  7 ++-
 7 files changed, 48 insertions(+), 20 deletions(-)

diff --git a/include/hw/boards.h b/include/hw/boards.h
index 156b16f7a6..041bc08971 100644
--- a/include/hw/boards.h
+++ b/include/hw/boards.h
@@ -76,6 +76,9 @@ void machine_set_cpu_numa_node(MachineState *machine,
const CpuInstanceProperties *props,
Error **errp);
 
+void machine_class_allow_dynamic_sysbus_dev(MachineClass *mc, const char 
*type);
+
+
 /**
  * CPUArchId:
  * @arch_id - architecture-dependent CPU ID of present or possible CPU
@@ -179,7 +182,6 @@ struct MachineClass {
 no_floppy:1,
 no_cdrom:1,
 no_sdcard:1,
-has_dynamic_sysbus:1,
 pci_allow_0_address:1,
 legacy_fw_cfg_order:1;
 int is_default;
@@ -197,6 +199,7 @@ struct MachineClass {
 bool ignore_memory_transaction_failures;
 int numa_mem_align_shift;
 const char **valid_cpu_types;
+strList *allowed_dynamic_sysbus_devices;
 bool auto_enable_numa_with_memhp;
 void (*numa_auto_assign_ram)(MachineClass *mc, NodeInfo *nodes,
  int nb_nodes, ram_addr_t size);
diff --git a/hw/arm/virt.c b/hw/arm/virt.c
index 543f9bd6cc..7549895fd2 100644
--- a/hw/arm/virt.c
+++ b/hw/arm/virt.c
@@ -1591,7 +1591,8 @@ static void virt_machine_class_init(ObjectClass *oc, void 
*data)
  * configuration of the particular instance.
  */
 mc->max_cpus = 255;
-mc->has_dynamic_sysbus = true;
+/*TODO: allow only sysbus devices that really work with this machine */
+machine_class_allow_dynamic_sysbus_dev(mc, TYPE_SYS_BUS_DEVICE);
 mc->block_default_type = IF_VIRTIO;
 mc->no_cdrom = 1;
 mc->pci_allow_0_address = true;
diff --git a/hw/core/machine.c b/hw/core/machine.c
index c857f3f934..0320a8efa1 100644
--- a/hw/core/machine.c
+++ b/hw/core/machine.c
@@ -334,29 +334,44 @@ static bool machine_get_enforce_config_section(Object 
*obj, Error **errp)
 return ms->enforce_config_section;
 }
 
-static void error_on_sysbus_device(SysBusDevice *sbdev, void *opaque)
+void machine_class_allow_dynamic_sysbus_dev(MachineClass *mc, const char *type)
 {
-error_report("Option '-device %s' cannot be handled by this machine",
- object_class_get_name(object_get_class(OBJECT(sbdev;
-exit(1);
+strList *item = g_new0(strList, 1);
+
+item->value = g_strdup(type);
+item->next = mc->allowed_dynamic_sysbus_devices;
+mc->allowed_dynamic_sysbus_devices = item;
 }
 
-static void machine_init_notify(Notifier *notifier, void *data)
+static void validate_sysbus_device(SysBusDevice *sbdev, void *opaque)
 {
-Object *machine = qdev_get_machine();
-ObjectClass *oc = object_get_class(machine);
-MachineClass *mc = MACHINE_CLASS(oc);
+MachineState *machine = opaque;
+MachineClass *mc = MACHINE_GET_CLASS(machine);
+bool allowed = false;
+strList *wl;
 
-if (mc->has_dynamic_sysbus) {
-/* Our machine can handle dynamic sysbus devices, we're all good */
-return;
+for (wl = mc->allowed_dynamic_sysbus_devices;
+ !allowed && wl;
+ wl = wl->next) {
+allowed |= !!object_dynamic_cast(OBJECT(sbdev), wl->value);
 }
 
+if (!allowed) {
+error_report("Option '-device %s' cannot be handled by this machine",
+ object_class_get_name(object_get_class(OBJECT(sbdev;
+exit(1);
+}
+}
+
+static void 

[Qemu-devel] [PULL 14/19] scripts: Remove fixed entries from the device-crash-test

[Eduardo Habkost]

From: Thomas Huth 

These are crashes / errors which have been fixed already in the past
months. We can remove these from the device-crash-test script now.

Signed-off-by: Thomas Huth 
Message-Id: <1513613438-11017-1-git-send-email-th...@redhat.com>
Signed-off-by: Eduardo Habkost 
---
 scripts/device-crash-test | 8 
 1 file changed, 8 deletions(-)

diff --git a/scripts/device-crash-test b/scripts/device-crash-test
index 827d8ec2af..7417177ebb 100755
--- a/scripts/device-crash-test
+++ b/scripts/device-crash-test
@@ -207,11 +207,9 @@ ERROR_WHITELIST = [
 # Known crashes will generate error messages, but won't be fatal.
 # Those entries must be removed once we fix the crashes.
 {'exitcode':-6, 'log':r"Device 'serial0' is in use", 
'loglevel':logging.ERROR},
-{'exitcode':-6, 'log':r"spapr_rtas_register: Assertion 
.*rtas_table\[token\]\.name.* failed", 'loglevel':logging.ERROR},
 {'exitcode':-6, 'log':r"qemu_net_client_setup: Assertion `!peer->peer' 
failed", 'loglevel':logging.ERROR},
 {'exitcode':-6, 'log':r'RAMBlock "[\w.-]+" already registered', 
'loglevel':logging.ERROR},
 {'exitcode':-6, 'log':r"find_ram_offset: Assertion `size != 0' failed.", 
'loglevel':logging.ERROR},
-{'exitcode':-6, 'log':r"puv3_load_kernel: Assertion `kernel_filename != 
NULL' failed", 'loglevel':logging.ERROR},
 {'exitcode':-6, 'log':r"add_cpreg_to_hashtable: code should not be 
reached", 'loglevel':logging.ERROR},
 {'exitcode':-6, 'log':r"qemu_alloc_display: Assertion `surface->image != 
NULL' failed", 'loglevel':logging.ERROR},
 {'exitcode':-6, 'log':r"Unexpected error in 
error_set_from_qdev_prop_error", 'loglevel':logging.ERROR},
@@ -219,16 +217,10 @@ ERROR_WHITELIST = [
 {'exitcode':-6, 'log':r"Object .* is not an instance of type 
generic-pc-machine", 'loglevel':logging.ERROR},
 {'exitcode':-6, 'log':r"Object .* is not an instance of type e500-ccsr", 
'loglevel':logging.ERROR},
 {'exitcode':-6, 'log':r"vmstate_register_with_alias_id: Assertion 
`!se->compat \|\| se->instance_id == 0' failed", 'loglevel':logging.ERROR},
-{'exitcode':-11, 'device':'stm32f205-soc', 'loglevel':logging.ERROR, 
'expected':True},
-{'exitcode':-11, 'device':'xlnx,zynqmp', 'loglevel':logging.ERROR, 
'expected':True},
-{'exitcode':-11, 'device':'mips-cps', 'loglevel':logging.ERROR, 
'expected':True},
 {'exitcode':-11, 'device':'gus', 'loglevel':logging.ERROR, 
'expected':True},
-{'exitcode':-11, 'device':'a9mpcore_priv', 'loglevel':logging.ERROR, 
'expected':True},
-{'exitcode':-11, 'device':'a15mpcore_priv', 'loglevel':logging.ERROR, 
'expected':True},
 {'exitcode':-11, 'device':'isa-serial', 'loglevel':logging.ERROR, 
'expected':True},
 {'exitcode':-11, 'device':'sb16', 'loglevel':logging.ERROR, 
'expected':True},
 {'exitcode':-11, 'device':'cs4231a', 'loglevel':logging.ERROR, 
'expected':True},
-{'exitcode':-11, 'device':'arm-gicv3', 'loglevel':logging.ERROR, 
'expected':True},
 {'exitcode':-11, 'machine':'isapc', 'device':'.*-iommu', 
'loglevel':logging.ERROR, 'expected':True},
 
 # everything else (including SIGABRT and SIGSEGV) will be a fatal error:
-- 
2.14.3

[Qemu-devel] [PULL 19/19] fw_cfg: fix memory corruption when all fw_cfg slots are used

[Eduardo Habkost]

From: Marcel Apfelbaum 

When all the fw_cfg slots are used, a write is made outside the
bounds of the fw_cfg files array as part of the sort algorithm.

Fix it by avoiding an unnecessary array element move.
Fix also an assert while at it.

Signed-off-by: Marcel Apfelbaum 
Message-Id: <20180108215007.46471-1-mar...@redhat.com>
Reviewed-by: Laszlo Ersek 
Signed-off-by: Eduardo Habkost 
---
 hw/nvram/fw_cfg.c | 6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/hw/nvram/fw_cfg.c b/hw/nvram/fw_cfg.c
index 753ac0e4ea..4313484b21 100644
--- a/hw/nvram/fw_cfg.c
+++ b/hw/nvram/fw_cfg.c
@@ -784,7 +784,7 @@ void fw_cfg_add_file_callback(FWCfgState *s,  const char 
*filename,
  * index and "i - 1" is the one being copied from, thus the
  * unusual start and end in the for statement.
  */
-for (i = count + 1; i > index; i--) {
+for (i = count; i > index; i--) {
 s->files->f[i] = s->files->f[i - 1];
 s->files->f[i].select = cpu_to_be16(FW_CFG_FILE_FIRST + i);
 s->entries[0][FW_CFG_FILE_FIRST + i] =
@@ -833,7 +833,6 @@ void *fw_cfg_modify_file(FWCfgState *s, const char 
*filename,
 assert(s->files);
 
 index = be32_to_cpu(s->files->count);
-assert(index < fw_cfg_file_slots(s));
 
 for (i = 0; i < index; i++) {
 if (strcmp(filename, s->files->f[i].name) == 0) {
@@ -843,6 +842,9 @@ void *fw_cfg_modify_file(FWCfgState *s, const char 
*filename,
 return ptr;
 }
 }
+
+assert(index < fw_cfg_file_slots(s));
+
 /* add new one */
 fw_cfg_add_file_callback(s, filename, NULL, NULL, NULL, data, len, true);
 return NULL;
-- 
2.14.3

[Qemu-devel] [PULL 04/19] qemu-options: document memory-backend-ram

[Eduardo Habkost]

From: Stefan Hajnoczi 

The documentation should mention -object memory-backend-ram.

Suggested-by: Yumei Huang 
Signed-off-by: Stefan Hajnoczi 
Message-Id: <20171128161529.3025-3-stefa...@redhat.com>
Reviewed-by: Eric Blake 
Reviewed-by: Eduardo Habkost 
Signed-off-by: Eduardo Habkost 
---
 qemu-options.hx | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/qemu-options.hx b/qemu-options.hx
index fe8c04f644..5b0ee43b18 100644
--- a/qemu-options.hx
+++ b/qemu-options.hx
@@ -4025,6 +4025,13 @@ restrict memory allocation to the given host node list
 interleave memory allocations across the given host node list
 @end table
 
+@item -object 
memory-backend-ram,id=@var{id},merge=@var{on|off},dump=@var{on|off},prealloc=@var{on|off},size=@var{size},host-nodes=@var{host-nodes},policy=@var{default|preferred|bind|interleave}
+
+Creates a memory backend object, which can be used to back the guest RAM.
+Memory backend objects offer more control than the @option{-m} option that is
+traditionally used to define guest RAM. Please refer to
+@option{memory-backend-file} for a description of the options.
+
 @item -object rng-random,id=@var{id},filename=@var{/dev/random}
 
 Creates a random number generator backend which obtains entropy from
-- 
2.14.3

[Qemu-devel] [PULL 10/19] xen: Add only xen-sysdev to dynamic sysbus device list

[Eduardo Habkost]

There's no need to make the machine allow every possible sysbus
device.  We can now just add xen-sysdev to the allowed list.

Cc: Stefano Stabellini 
Cc: Anthony Perard 
Cc: xen-de...@lists.xenproject.org
Cc: Juergen Gross 
Signed-off-by: Eduardo Habkost 
Message-Id: <20171125151610.20547-6-ehabk...@redhat.com>
Reviewed-by: Marc-André Lureau 
Acked-by: Anthony PERARD 
Signed-off-by: Eduardo Habkost 
---
 hw/xen/xen_backend.c | 7 +--
 1 file changed, 1 insertion(+), 6 deletions(-)

diff --git a/hw/xen/xen_backend.c b/hw/xen/xen_backend.c
index 82380ea9ee..7445b506ac 100644
--- a/hw/xen/xen_backend.c
+++ b/hw/xen/xen_backend.c
@@ -564,12 +564,7 @@ static void xen_set_dynamic_sysbus(void)
 ObjectClass *oc = object_get_class(machine);
 MachineClass *mc = MACHINE_CLASS(oc);
 
-/*
- * Emulate old mc->has_dynamic_sysbus=true assignment
- *
- *TODO: add only Xen devices to the list
- */
-machine_class_allow_dynamic_sysbus_dev(mc, TYPE_SYS_BUS_DEVICE);
+machine_class_allow_dynamic_sysbus_dev(mc, TYPE_XENSYSDEV);
 }
 
 int xen_be_register(const char *type, struct XenDevOps *ops)
-- 
2.14.3

[Qemu-devel] [PULL 16/19] nvdimm: add a macro for property "label-size"

[Eduardo Habkost]

From: Haozhong Zhang 

Signed-off-by: Haozhong Zhang 
Reviewed-by: Stefan Hajnoczi 
Message-Id: <20171211072806.2812-3-haozhong.zh...@intel.com>
Reviewed-by: Michael S. Tsirkin 
Signed-off-by: Eduardo Habkost 
---
 include/hw/mem/nvdimm.h | 3 +++
 hw/mem/nvdimm.c | 2 +-
 2 files changed, 4 insertions(+), 1 deletion(-)

diff --git a/include/hw/mem/nvdimm.h b/include/hw/mem/nvdimm.h
index 03e1ff9558..28e68ddf59 100644
--- a/include/hw/mem/nvdimm.h
+++ b/include/hw/mem/nvdimm.h
@@ -47,6 +47,9 @@
 #define NVDIMM_CLASS(oc) OBJECT_CLASS_CHECK(NVDIMMClass, (oc), TYPE_NVDIMM)
 #define NVDIMM_GET_CLASS(obj) OBJECT_GET_CLASS(NVDIMMClass, (obj), \
TYPE_NVDIMM)
+
+#define NVDIMM_LABLE_SIZE_PROP "label-size"
+
 struct NVDIMMDevice {
 /* private */
 PCDIMMDevice parent_obj;
diff --git a/hw/mem/nvdimm.c b/hw/mem/nvdimm.c
index 952fce5ec8..618c3d677b 100644
--- a/hw/mem/nvdimm.c
+++ b/hw/mem/nvdimm.c
@@ -66,7 +66,7 @@ out:
 
 static void nvdimm_init(Object *obj)
 {
-object_property_add(obj, "label-size", "int",
+object_property_add(obj, NVDIMM_LABLE_SIZE_PROP, "int",
 nvdimm_get_label_size, nvdimm_set_label_size, NULL,
 NULL, NULL);
 }
-- 
2.14.3

[Qemu-devel] [PULL 01/19] memfd: split qemu_memfd_alloc()

[Eduardo Habkost]

From: Marc-André Lureau 

Add a function to only create a memfd, without mmap. The function is
used in the following memory backend.

Signed-off-by: Marc-André Lureau 
Reviewed-by: Philippe Mathieu-Daudé 
Message-Id: <20171023141815.17709-2-marcandre.lur...@redhat.com>
Signed-off-by: Eduardo Habkost 
---
 include/qemu/memfd.h |  1 +
 util/memfd.c | 61 +++-
 2 files changed, 37 insertions(+), 25 deletions(-)

diff --git a/include/qemu/memfd.h b/include/qemu/memfd.h
index 745a8c501e..41c24d807c 100644
--- a/include/qemu/memfd.h
+++ b/include/qemu/memfd.h
@@ -16,6 +16,7 @@
 #define F_SEAL_WRITE0x0008  /* prevent writes */
 #endif
 
+int qemu_memfd_create(const char *name, size_t size, unsigned int seals);
 void *qemu_memfd_alloc(const char *name, size_t size, unsigned int seals,
int *fd);
 void qemu_memfd_free(void *ptr, size_t size, int fd);
diff --git a/util/memfd.c b/util/memfd.c
index 412e94a405..3a82505f8d 100644
--- a/util/memfd.c
+++ b/util/memfd.c
@@ -53,6 +53,38 @@ static int memfd_create(const char *name, unsigned int flags)
 #define MFD_ALLOW_SEALING 0x0002U
 #endif
 
+int qemu_memfd_create(const char *name, size_t size, unsigned int seals)
+{
+int mfd = -1;
+
+#ifdef CONFIG_LINUX
+unsigned int flags = MFD_CLOEXEC;
+
+if (seals) {
+flags |= MFD_ALLOW_SEALING;
+}
+
+mfd = memfd_create(name, flags);
+if (mfd < 0) {
+return -1;
+}
+
+if (ftruncate(mfd, size) == -1) {
+perror("ftruncate");
+close(mfd);
+return -1;
+}
+
+if (seals && fcntl(mfd, F_ADD_SEALS, seals) == -1) {
+perror("fcntl");
+close(mfd);
+return -1;
+}
+#endif
+
+return mfd;
+}
+
 /*
  * This is a best-effort helper for shared memory allocation, with
  * optional sealing. The helper will do his best to allocate using
@@ -63,35 +95,14 @@ void *qemu_memfd_alloc(const char *name, size_t size, 
unsigned int seals,
int *fd)
 {
 void *ptr;
-int mfd = -1;
-
-*fd = -1;
-
-#ifdef CONFIG_LINUX
-if (seals) {
-mfd = memfd_create(name, MFD_ALLOW_SEALING | MFD_CLOEXEC);
-}
+int mfd = qemu_memfd_create(name, size, seals);
 
+/* some systems have memfd without sealing */
 if (mfd == -1) {
-/* some systems have memfd without sealing */
-mfd = memfd_create(name, MFD_CLOEXEC);
-seals = 0;
+mfd = qemu_memfd_create(name, size, 0);
 }
-#endif
-
-if (mfd != -1) {
-if (ftruncate(mfd, size) == -1) {
-perror("ftruncate");
-close(mfd);
-return NULL;
-}
 
-if (seals && fcntl(mfd, F_ADD_SEALS, seals) == -1) {
-perror("fcntl");
-close(mfd);
-return NULL;
-}
-} else {
+if (mfd == -1) {
 const char *tmpdir = g_get_tmp_dir();
 gchar *fname;
 
-- 
2.14.3

[Qemu-devel] [PULL 17/19] nvdimm: add 'unarmed' option

[Eduardo Habkost]

From: Haozhong Zhang 

Currently the only vNVDIMM backend can guarantee the guest write
persistence is device DAX on Linux, because no host-side kernel cache
is involved in the guest access to it. The approach to detect whether
the backend is device DAX needs to access sysfs, which may not work
with SELinux.

Instead, we add the 'unarmed' option to device 'nvdimm', so that users
or management utils, which have enough knowledge about the backend,
can control the unarmed flag in guest ACPI NFIT via this option. The
guest Linux NVDIMM driver, for example, will mark the corresponding
vNVDIMM device read-only if the unarmed flag in guest NFIT is set.

The default value of 'unarmed' option is 'off' in order to keep the
backwards compatibility.

Signed-off-by: Haozhong Zhang 
Message-Id: <20171211072806.2812-4-haozhong.zh...@intel.com>
Reviewed-by: Michael S. Tsirkin 
Reviewed-by: Stefan Hajnoczi 
Signed-off-by: Eduardo Habkost 
---
 docs/nvdimm.txt | 15 +++
 include/hw/mem/nvdimm.h |  9 +
 hw/acpi/nvdimm.c|  7 +++
 hw/mem/nvdimm.c | 26 ++
 4 files changed, 57 insertions(+)

diff --git a/docs/nvdimm.txt b/docs/nvdimm.txt
index 21249dd062..e903d8bb09 100644
--- a/docs/nvdimm.txt
+++ b/docs/nvdimm.txt
@@ -138,3 +138,18 @@ backend of vNVDIMM:
 
  -object 
memory-backend-file,id=mem1,share=on,mem-path=/dev/dax0.0,size=4G,align=2M
  -device nvdimm,id=nvdimm1,memdev=mem1
+
+Guest Data Persistence
+--
+
+Though QEMU supports multiple types of vNVDIMM backends on Linux,
+currently the only one that can guarantee the guest write persistence
+is the device DAX on the real NVDIMM device (e.g., /dev/dax0.0), to
+which all guest access do not involve any host-side kernel cache.
+
+When using other types of backends, it's suggested to set 'unarmed'
+option of '-device nvdimm' to 'on', which sets the unarmed flag of the
+guest NVDIMM region mapping structure.  This unarmed flag indicates
+guest software that this vNVDIMM device contains a region that cannot
+accept persistent writes. In result, for example, the guest Linux
+NVDIMM driver, marks such vNVDIMM device as read-only.
diff --git a/include/hw/mem/nvdimm.h b/include/hw/mem/nvdimm.h
index 28e68ddf59..7fd87c4e1c 100644
--- a/include/hw/mem/nvdimm.h
+++ b/include/hw/mem/nvdimm.h
@@ -49,6 +49,7 @@
TYPE_NVDIMM)
 
 #define NVDIMM_LABLE_SIZE_PROP "label-size"
+#define NVDIMM_UNARMED_PROP"unarmed"
 
 struct NVDIMMDevice {
 /* private */
@@ -74,6 +75,14 @@ struct NVDIMMDevice {
  * guest via ACPI NFIT and _FIT method if NVDIMM hotplug is supported.
  */
 MemoryRegion nvdimm_mr;
+
+/*
+ * The 'on' value results in the unarmed flag set in ACPI NFIT,
+ * which can be used to notify guest implicitly that the host
+ * backend (e.g., files on HDD, /dev/pmemX, etc.) cannot guarantee
+ * the guest write persistence.
+ */
+bool unarmed;
 };
 typedef struct NVDIMMDevice NVDIMMDevice;
 
diff --git a/hw/acpi/nvdimm.c b/hw/acpi/nvdimm.c
index 6ceea196e7..59d6e4254c 100644
--- a/hw/acpi/nvdimm.c
+++ b/hw/acpi/nvdimm.c
@@ -138,6 +138,8 @@ struct NvdimmNfitMemDev {
 } QEMU_PACKED;
 typedef struct NvdimmNfitMemDev NvdimmNfitMemDev;
 
+#define ACPI_NFIT_MEM_NOT_ARMED (1 << 3)
+
 /*
  * NVDIMM Control Region Structure
  *
@@ -284,6 +286,7 @@ static void
 nvdimm_build_structure_memdev(GArray *structures, DeviceState *dev)
 {
 NvdimmNfitMemDev *nfit_memdev;
+NVDIMMDevice *nvdimm = NVDIMM(OBJECT(dev));
 uint64_t size = object_property_get_uint(OBJECT(dev), PC_DIMM_SIZE_PROP,
  NULL);
 int slot = object_property_get_int(OBJECT(dev), PC_DIMM_SLOT_PROP,
@@ -312,6 +315,10 @@ nvdimm_build_structure_memdev(GArray *structures, 
DeviceState *dev)
 
 /* Only one interleave for PMEM. */
 nfit_memdev->interleave_ways = cpu_to_le16(1);
+
+if (nvdimm->unarmed) {
+nfit_memdev->flags |= cpu_to_le16(ACPI_NFIT_MEM_NOT_ARMED);
+}
 }
 
 /*
diff --git a/hw/mem/nvdimm.c b/hw/mem/nvdimm.c
index 618c3d677b..61e677f92f 100644
--- a/hw/mem/nvdimm.c
+++ b/hw/mem/nvdimm.c
@@ -25,6 +25,7 @@
 #include "qemu/osdep.h"
 #include "qapi/error.h"
 #include "qapi/visitor.h"
+#include "qapi-visit.h"
 #include "hw/mem/nvdimm.h"
 
 static void nvdimm_get_label_size(Object *obj, Visitor *v, const char *name,
@@ -64,11 +65,36 @@ out:
 error_propagate(errp, local_err);
 }
 
+static bool nvdimm_get_unarmed(Object *obj, Error **errp)
+{
+NVDIMMDevice *nvdimm = NVDIMM(obj);
+
+return nvdimm->unarmed;
+}
+
+static void nvdimm_set_unarmed(Object *obj, bool value, Error **errp)
+{
+NVDIMMDevice *nvdimm = NVDIMM(obj);
+Error *local_err = NULL;
+
+if (memory_region_size(>nvdimm_mr)) {
+error_setg(_err, "cannot change property value");
+  

[Qemu-devel] [PULL 09/19] spapr: Allow only supported dynamic sysbus devices

[Eduardo Habkost]

TYPE_SPAPR_PCI_HOST_BRIDGE is the only dynamic sysbus device not
rejected by ppc_spapr_reset(), so it can be the only entry on the
allowed list.

Cc: David Gibson 
Cc: Alexander Graf 
Cc: qemu-...@nongnu.org
Signed-off-by: Eduardo Habkost 
Message-Id: <20171125151610.20547-5-ehabk...@redhat.com>
Acked-by: David Gibson 
Reviewed-by: Greg Kurz 
Signed-off-by: Eduardo Habkost 
---
 hw/ppc/spapr.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/hw/ppc/spapr.c b/hw/ppc/spapr.c
index 95f7f95dd1..583fbe483f 100644
--- a/hw/ppc/spapr.c
+++ b/hw/ppc/spapr.c
@@ -3786,8 +3786,7 @@ static void spapr_machine_class_init(ObjectClass *oc, 
void *data)
 mc->default_boot_order = "";
 mc->default_ram_size = 512 * M_BYTE;
 mc->kvm_type = spapr_kvm_type;
-/*TODO: allow only sysbus devices that really work with this machine */
-machine_class_allow_dynamic_sysbus_dev(mc, TYPE_SYS_BUS_DEVICE);
+machine_class_allow_dynamic_sysbus_dev(mc, TYPE_SPAPR_PCI_HOST_BRIDGE);
 mc->pci_allow_0_address = true;
 mc->get_hotplug_handler = spapr_get_hotplug_handler;
 hc->pre_plug = spapr_machine_device_pre_plug;
-- 
2.14.3

[Qemu-devel] [PULL 00/19] machine queue, 2018-01-18

[Eduardo Habkost]

The following changes since commit 8e5dc9ba49743b46d955ec7dacb04e42ae7ada7c:

  Merge remote-tracking branch 'remotes/rth/tags/pull-tcg-20180116' into 
staging (2018-01-16 17:36:39 +)

are available in the Git repository at:

  git://github.com/ehabkost/qemu.git tags/machine-next-pull-request

for you to fetch changes up to 901cc8d31f36ac82824ab68f656ab7050404100c:

  fw_cfg: fix memory corruption when all fw_cfg slots are used (2018-01-17 
23:04:37 -0200)


machine queue, 2018-01-18



Eduardo Habkost (6):
  machine: Replace has_dynamic_sysbus with list of allowed devices
  hw/arm/virt: Allow only supported dynamic sysbus devices
  ppc: e500: Allow only supported dynamic sysbus devices
  spapr: Allow only supported dynamic sysbus devices
  xen: Add only xen-sysdev to dynamic sysbus device list
  q35: Allow only supported dynamic sysbus devices

Haozhong Zhang (3):
  hostmem-file: add "align" option
  nvdimm: add a macro for property "label-size"
  nvdimm: add 'unarmed' option

Igor Mammedov (2):
  numa: fix missing '-numa cpu' in '-help' output
  possible_cpus: add CPUArchId::type field

Marc-André Lureau (2):
  memfd: split qemu_memfd_alloc()
  memfd: remove needless include

Marcel Apfelbaum (1):
  fw_cfg: fix memory corruption when all fw_cfg slots are used

Stefan Hajnoczi (2):
  qemu-options: document missing memory-backend-file options
  qemu-options: document memory-backend-ram

Thomas Huth (3):
  qdev_monitor: Simplify error handling in qdev_device_add()
  qdev: Check for the availability of a hotplug controller before adding
a device
  scripts: Remove fixed entries from the device-crash-test

 docs/nvdimm.txt| 31 ++
 include/exec/memory.h  |  3 +++
 include/hw/boards.h|  7 -
 include/hw/mem/nvdimm.h| 12 +
 include/hw/qdev-core.h |  1 +
 include/qemu/memfd.h   |  1 +
 backends/hostmem-file.c| 41 +++-
 exec.c |  8 +-
 hw/acpi/nvdimm.c   |  7 +
 hw/arm/virt.c  |  8 --
 hw/core/machine.c  | 55 --
 hw/core/qdev.c | 28 ++--
 hw/i386/pc.c   |  4 ++-
 hw/i386/pc_q35.c   |  5 +++-
 hw/mem/nvdimm.c| 28 +++-
 hw/nvram/fw_cfg.c  |  6 +++--
 hw/ppc/e500plat.c  |  4 ++-
 hw/ppc/spapr.c | 15 ++-
 hw/s390x/s390-virtio-ccw.c |  1 +
 hw/xen/xen_backend.c   |  2 +-
 memory.c   |  2 ++
 numa.c |  2 +-
 qdev-monitor.c | 21 +--
 util/memfd.c   | 63 ---
 vl.c   |  3 +--
 qemu-options.hx| 66 --
 scripts/device-crash-test  |  8 --
 27 files changed, 332 insertions(+), 100 deletions(-)

-- 
2.14.3

[Qemu-devel] [PULL 03/19] qemu-options: document missing memory-backend-file options

[Eduardo Habkost]

From: Stefan Hajnoczi 

This patch adds undocumented memory-backend-file options to the
documentation.

Signed-off-by: Stefan Hajnoczi 
Message-Id: <20171128161529.3025-2-stefa...@redhat.com>
Reviewed-by: Eric Blake 
Reviewed-by: Eduardo Habkost 
Signed-off-by: Eduardo Habkost 
---
 qemu-options.hx | 48 +---
 1 file changed, 41 insertions(+), 7 deletions(-)

diff --git a/qemu-options.hx b/qemu-options.hx
index 678181c599..fe8c04f644 100644
--- a/qemu-options.hx
+++ b/qemu-options.hx
@@ -3972,18 +3972,24 @@ property must be set.  These objects are placed in the
 
 @table @option
 
-@item -object 
memory-backend-file,id=@var{id},size=@var{size},mem-path=@var{dir},share=@var{on|off},discard-data=@var{on|off}
+@item -object 
memory-backend-file,id=@var{id},size=@var{size},mem-path=@var{dir},share=@var{on|off},discard-data=@var{on|off},merge=@var{on|off},dump=@var{on|off},prealloc=@var{on|off},host-nodes=@var{host-nodes},policy=@var{default|preferred|bind|interleave}
 
 Creates a memory file backend object, which can be used to back
-the guest RAM with huge pages. The @option{id} parameter is a
-unique ID that will be used to reference this memory region
-when configuring the @option{-numa} argument. The @option{size}
-option provides the size of the memory region, and accepts
-common suffixes, eg @option{500M}. The @option{mem-path} provides
-the path to either a shared memory or huge page filesystem mount.
+the guest RAM with huge pages.
+
+The @option{id} parameter is a unique ID that will be used to reference this
+memory region when configuring the @option{-numa} argument.
+
+The @option{size} option provides the size of the memory region, and accepts
+common suffixes, eg @option{500M}.
+
+The @option{mem-path} provides the path to either a shared memory or huge page
+filesystem mount.
+
 The @option{share} boolean option determines whether the memory
 region is marked as private to QEMU, or shared. The latter allows
 a co-operating external process to access the QEMU memory region.
+
 Setting the @option{discard-data} boolean option to @var{on}
 indicates that file contents can be destroyed when QEMU exits,
 to avoid unnecessarily flushing data to the backing file.  Note
@@ -3991,6 +3997,34 @@ that @option{discard-data} is only an optimization, and 
QEMU
 might not discard file contents if it aborts unexpectedly or is
 terminated using SIGKILL.
 
+The @option{merge} boolean option enables memory merge, also known as
+MADV_MERGEABLE, so that Kernel Samepage Merging will consider the pages for
+memory deduplication.
+
+Setting the @option{dump} boolean option to @var{off} excludes the memory from
+core dumps. This feature is also known as MADV_DONTDUMP.
+
+The @option{prealloc} boolean option enables memory preallocation.
+
+The @option{host-nodes} option binds the memory range to a list of NUMA host
+nodes.
+
+The @option{policy} option sets the NUMA policy to one of the following values:
+
+@table @option
+@item @var{default}
+default host policy
+
+@item @var{preferred}
+prefer the given host node list for allocation
+
+@item @var{bind}
+restrict memory allocation to the given host node list
+
+@item @var{interleave}
+interleave memory allocations across the given host node list
+@end table
+
 @item -object rng-random,id=@var{id},filename=@var{/dev/random}
 
 Creates a random number generator backend which obtains entropy from
-- 
2.14.3

[Qemu-devel] [PULL 11/19] q35: Allow only supported dynamic sysbus devices

[Eduardo Habkost]

The only user-creatable sysbus devices in qemu-system-x86_64 are
amd-iommu, intel-iommu, and xen-backend.  xen-backend is handled
by xen_set_dynamic_sysbus(), so we only need to add amd-iommu and
intel-iommu.

Cc: "Michael S. Tsirkin" 
Cc: Marcel Apfelbaum 
Signed-off-by: Eduardo Habkost 
Message-Id: <20171125151610.20547-7-ehabk...@redhat.com>
Reviewed-by: Marcel Apfelbaum 
Signed-off-by: Eduardo Habkost 
---
 hw/i386/pc_q35.c | 6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/hw/i386/pc_q35.c b/hw/i386/pc_q35.c
index d0b0e5b422..db2bebb357 100644
--- a/hw/i386/pc_q35.c
+++ b/hw/i386/pc_q35.c
@@ -42,6 +42,8 @@
 #include "exec/address-spaces.h"
 #include "hw/i386/pc.h"
 #include "hw/i386/ich9.h"
+#include "hw/i386/amd_iommu.h"
+#include "hw/i386/intel_iommu.h"
 #include "hw/smbios/smbios.h"
 #include "hw/ide/pci.h"
 #include "hw/ide/ahci.h"
@@ -299,8 +301,8 @@ static void pc_q35_machine_options(MachineClass *m)
 m->default_machine_opts = "firmware=bios-256k.bin";
 m->default_display = "std";
 m->no_floppy = 1;
-/*TODO: allow only sysbus devices that really work with this machine */
-machine_class_allow_dynamic_sysbus_dev(m, TYPE_SYS_BUS_DEVICE);
+machine_class_allow_dynamic_sysbus_dev(m, TYPE_AMD_IOMMU_DEVICE);
+machine_class_allow_dynamic_sysbus_dev(m, TYPE_INTEL_IOMMU_DEVICE);
 m->max_cpus = 288;
 }
 
-- 
2.14.3

[Qemu-devel] [PULL 08/19] ppc: e500: Allow only supported dynamic sysbus devices

[Eduardo Habkost]

platform_bus_create_devtree() already rejects all dynamic sysbus
devices except TYPE_ETSEC_COMMON, so register it as the only
allowed dynamic sysbus device for the ppce500 machine-type.

Cc: Alexander Graf 
Cc: David Gibson 
Cc: qemu-...@nongnu.org
Signed-off-by: Eduardo Habkost 
Message-Id: <20171125151610.20547-4-ehabk...@redhat.com>
Acked-by: David Gibson 
Reviewed-by: Greg Kurz 
Signed-off-by: Eduardo Habkost 
---
 hw/ppc/e500plat.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/hw/ppc/e500plat.c b/hw/ppc/e500plat.c
index 438118c29b..81d03e1038 100644
--- a/hw/ppc/e500plat.c
+++ b/hw/ppc/e500plat.c
@@ -12,6 +12,7 @@
 #include "qemu/osdep.h"
 #include "qemu-common.h"
 #include "e500.h"
+#include "hw/net/fsl_etsec/etsec.h"
 #include "hw/boards.h"
 #include "sysemu/device_tree.h"
 #include "sysemu/kvm.h"
@@ -64,8 +65,7 @@ static void e500plat_machine_init(MachineClass *mc)
 mc->desc = "generic paravirt e500 platform";
 mc->init = e500plat_init;
 mc->max_cpus = 32;
-/*TODO: allow only sysbus devices that really work with this machine */
-machine_class_allow_dynamic_sysbus_dev(mc, TYPE_SYS_BUS_DEVICE);
+machine_class_allow_dynamic_sysbus_dev(mc, TYPE_ETSEC_COMMON);
 mc->default_cpu_type = POWERPC_CPU_TYPE_NAME("e500v2_v30");
 }
 
-- 
2.14.3

[Qemu-devel] [PULL 02/19] memfd: remove needless include

[Eduardo Habkost]

From: Marc-André Lureau 

Signed-off-by: Marc-André Lureau 
Reviewed-by: Philippe Mathieu-Daudé 
Message-Id: <20171023141815.17709-3-marcandre.lur...@redhat.com>
Signed-off-by: Eduardo Habkost 
---
 util/memfd.c | 2 --
 1 file changed, 2 deletions(-)

diff --git a/util/memfd.c b/util/memfd.c
index 3a82505f8d..dce61f9d21 100644
--- a/util/memfd.c
+++ b/util/memfd.c
@@ -27,8 +27,6 @@
 
 #include "qemu/osdep.h"
 
-#include 
-
 #include "qemu/memfd.h"
 
 #if defined CONFIG_LINUX && !defined CONFIG_MEMFD
-- 
2.14.3

[Qemu-devel] [PULL 07/19] hw/arm/virt: Allow only supported dynamic sysbus devices

[Eduardo Habkost]

Replace the TYPE_SYS_BUS_DEVICE entry in the allowed sysbus
device list with the two device types that are really supported
by the virt machine: vfio-amd-xgbe and vfio-calxeda-xgmac.

Cc: Peter Maydell 
Cc: qemu-...@nongnu.org
Signed-off-by: Eduardo Habkost 
Message-Id: <20171125151610.20547-3-ehabk...@redhat.com>
Signed-off-by: Eduardo Habkost 
---
 hw/arm/virt.c | 6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/hw/arm/virt.c b/hw/arm/virt.c
index 7549895fd2..4a6fdcc4f5 100644
--- a/hw/arm/virt.c
+++ b/hw/arm/virt.c
@@ -34,6 +34,8 @@
 #include "hw/arm/arm.h"
 #include "hw/arm/primecell.h"
 #include "hw/arm/virt.h"
+#include "hw/vfio/vfio-calxeda-xgmac.h"
+#include "hw/vfio/vfio-amd-xgbe.h"
 #include "hw/devices.h"
 #include "net/net.h"
 #include "sysemu/block-backend.h"
@@ -1591,8 +1593,8 @@ static void virt_machine_class_init(ObjectClass *oc, void 
*data)
  * configuration of the particular instance.
  */
 mc->max_cpus = 255;
-/*TODO: allow only sysbus devices that really work with this machine */
-machine_class_allow_dynamic_sysbus_dev(mc, TYPE_SYS_BUS_DEVICE);
+machine_class_allow_dynamic_sysbus_dev(mc, TYPE_VFIO_CALXEDA_XGMAC);
+machine_class_allow_dynamic_sysbus_dev(mc, TYPE_VFIO_AMD_XGBE);
 mc->block_default_type = IF_VIRTIO;
 mc->no_cdrom = 1;
 mc->pci_allow_0_address = true;
-- 
2.14.3

[Qemu-devel] [PULL 05/19] numa: fix missing '-numa cpu' in '-help' output

[Eduardo Habkost]

From: Igor Mammedov 

commit 419fcdec3c (numa: add '-numa cpu,...' option for property based node 
mapping)
added '-numa cpu' option but forgot to update appropriate section for '--help'.
Add '-numa cpu' description to '-help' output

Reported-by: Markus Armbruster 
Signed-off-by: Igor Mammedov 
Message-Id: <1511880838-56509-1-git-send-email-imamm...@redhat.com>
Reviewed-by: Eric Blake 
Signed-off-by: Eduardo Habkost 
---
 qemu-options.hx | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/qemu-options.hx b/qemu-options.hx
index 5b0ee43b18..b3e03c5464 100644
--- a/qemu-options.hx
+++ b/qemu-options.hx
@@ -169,7 +169,9 @@ ETEXI
 DEF("numa", HAS_ARG, QEMU_OPTION_numa,
 "-numa node[,mem=size][,cpus=firstcpu[-lastcpu]][,nodeid=node]\n"
 "-numa node[,memdev=id][,cpus=firstcpu[-lastcpu]][,nodeid=node]\n"
-"-numa dist,src=source,dst=destination,val=distance\n", QEMU_ARCH_ALL)
+"-numa dist,src=source,dst=destination,val=distance\n"
+"-numa cpu,node-id=node[,socket-id=x][,core-id=y][,thread-id=z]\n",
+QEMU_ARCH_ALL)
 STEXI
 @item -numa 
node[,mem=@var{size}][,cpus=@var{firstcpu}[-@var{lastcpu}]][,nodeid=@var{node}]
 @itemx -numa 
node[,memdev=@var{id}][,cpus=@var{firstcpu}[-@var{lastcpu}]][,nodeid=@var{node}]
-- 
2.14.3

[Qemu-devel] [PULL 7/8] i386: Add new -IBRS versions of Intel CPU models

[Eduardo Habkost]

The new MSR IA32_SPEC_CTRL MSR was introduced by a recent Intel
microcode updated and can be used by OSes to mitigate
CVE-2017-5715.  Unfortunately we can't change the existing CPU
models without breaking existing setups, so users need to
explicitly update their VM configuration to use the new *-IBRS
CPU model if they want to expose IBRS to guests.

The new CPU models are simple copies of the existing CPU models,
with just CPUID_7_0_EDX_SPEC_CTRL added and model_id updated.

Cc: Jiri Denemark 
Signed-off-by: Eduardo Habkost 
Message-Id: <20180109154519.25634-6-ehabk...@redhat.com>
Signed-off-by: Eduardo Habkost 
---
 target/i386/cpu.c | 379 +-
 1 file changed, 378 insertions(+), 1 deletion(-)

diff --git a/target/i386/cpu.c b/target/i386/cpu.c
index 6fe14362cc..365458a6a0 100644
--- a/target/i386/cpu.c
+++ b/target/i386/cpu.c
@@ -1085,6 +1085,31 @@ static X86CPUDefinition builtin_x86_defs[] = {
 .xlevel = 0x8008,
 .model_id = "Intel Core i7 9xx (Nehalem Class Core i7)",
 },
+{
+.name = "Nehalem-IBRS",
+.level = 11,
+.vendor = CPUID_VENDOR_INTEL,
+.family = 6,
+.model = 26,
+.stepping = 3,
+.features[FEAT_1_EDX] =
+CPUID_VME | CPUID_SSE2 | CPUID_SSE | CPUID_FXSR | CPUID_MMX |
+CPUID_CLFLUSH | CPUID_PSE36 | CPUID_PAT | CPUID_CMOV | CPUID_MCA |
+CPUID_PGE | CPUID_MTRR | CPUID_SEP | CPUID_APIC | CPUID_CX8 |
+CPUID_MCE | CPUID_PAE | CPUID_MSR | CPUID_TSC | CPUID_PSE |
+CPUID_DE | CPUID_FP87,
+.features[FEAT_1_ECX] =
+CPUID_EXT_POPCNT | CPUID_EXT_SSE42 | CPUID_EXT_SSE41 |
+CPUID_EXT_CX16 | CPUID_EXT_SSSE3 | CPUID_EXT_SSE3,
+.features[FEAT_7_0_EDX] =
+CPUID_7_0_EDX_SPEC_CTRL,
+.features[FEAT_8000_0001_EDX] =
+CPUID_EXT2_LM | CPUID_EXT2_SYSCALL | CPUID_EXT2_NX,
+.features[FEAT_8000_0001_ECX] =
+CPUID_EXT3_LAHF_LM,
+.xlevel = 0x8008,
+.model_id = "Intel Core i7 9xx (Nehalem Core i7, IBRS update)",
+},
 {
 .name = "Westmere",
 .level = 11,
@@ -,6 +1136,34 @@ static X86CPUDefinition builtin_x86_defs[] = {
 .xlevel = 0x8008,
 .model_id = "Westmere E56xx/L56xx/X56xx (Nehalem-C)",
 },
+{
+.name = "Westmere-IBRS",
+.level = 11,
+.vendor = CPUID_VENDOR_INTEL,
+.family = 6,
+.model = 44,
+.stepping = 1,
+.features[FEAT_1_EDX] =
+CPUID_VME | CPUID_SSE2 | CPUID_SSE | CPUID_FXSR | CPUID_MMX |
+CPUID_CLFLUSH | CPUID_PSE36 | CPUID_PAT | CPUID_CMOV | CPUID_MCA |
+CPUID_PGE | CPUID_MTRR | CPUID_SEP | CPUID_APIC | CPUID_CX8 |
+CPUID_MCE | CPUID_PAE | CPUID_MSR | CPUID_TSC | CPUID_PSE |
+CPUID_DE | CPUID_FP87,
+.features[FEAT_1_ECX] =
+CPUID_EXT_AES | CPUID_EXT_POPCNT | CPUID_EXT_SSE42 |
+CPUID_EXT_SSE41 | CPUID_EXT_CX16 | CPUID_EXT_SSSE3 |
+CPUID_EXT_PCLMULQDQ | CPUID_EXT_SSE3,
+.features[FEAT_8000_0001_EDX] =
+CPUID_EXT2_LM | CPUID_EXT2_SYSCALL | CPUID_EXT2_NX,
+.features[FEAT_8000_0001_ECX] =
+CPUID_EXT3_LAHF_LM,
+.features[FEAT_7_0_EDX] =
+CPUID_7_0_EDX_SPEC_CTRL,
+.features[FEAT_6_EAX] =
+CPUID_6_EAX_ARAT,
+.xlevel = 0x8008,
+.model_id = "Westmere E56xx/L56xx/X56xx (IBRS update)",
+},
 {
 .name = "SandyBridge",
 .level = 0xd,
@@ -1142,6 +1195,39 @@ static X86CPUDefinition builtin_x86_defs[] = {
 .xlevel = 0x8008,
 .model_id = "Intel Xeon E312xx (Sandy Bridge)",
 },
+{
+.name = "SandyBridge-IBRS",
+.level = 0xd,
+.vendor = CPUID_VENDOR_INTEL,
+.family = 6,
+.model = 42,
+.stepping = 1,
+.features[FEAT_1_EDX] =
+CPUID_VME | CPUID_SSE2 | CPUID_SSE | CPUID_FXSR | CPUID_MMX |
+CPUID_CLFLUSH | CPUID_PSE36 | CPUID_PAT | CPUID_CMOV | CPUID_MCA |
+CPUID_PGE | CPUID_MTRR | CPUID_SEP | CPUID_APIC | CPUID_CX8 |
+CPUID_MCE | CPUID_PAE | CPUID_MSR | CPUID_TSC | CPUID_PSE |
+CPUID_DE | CPUID_FP87,
+.features[FEAT_1_ECX] =
+CPUID_EXT_AVX | CPUID_EXT_XSAVE | CPUID_EXT_AES |
+CPUID_EXT_TSC_DEADLINE_TIMER | CPUID_EXT_POPCNT |
+CPUID_EXT_X2APIC | CPUID_EXT_SSE42 | CPUID_EXT_SSE41 |
+CPUID_EXT_CX16 | CPUID_EXT_SSSE3 | CPUID_EXT_PCLMULQDQ |
+CPUID_EXT_SSE3,
+.features[FEAT_8000_0001_EDX] =
+CPUID_EXT2_LM | CPUID_EXT2_RDTSCP | CPUID_EXT2_NX |
+CPUID_EXT2_SYSCALL,
+.features[FEAT_8000_0001_ECX] =
+CPUID_EXT3_LAHF_LM,
+.features[FEAT_7_0_EDX] =
+CPUID_7_0_EDX_SPEC_CTRL,
+

[Qemu-devel] [PULL 4/8] i386: Add support for SPEC_CTRL MSR

[Eduardo Habkost]

From: Paolo Bonzini 

Signed-off-by: Eduardo Habkost 
Message-Id: <20180109154519.25634-3-ehabk...@redhat.com>
Signed-off-by: Eduardo Habkost 
---
 target/i386/cpu.h |  3 +++
 target/i386/kvm.c | 14 ++
 target/i386/machine.c | 20 
 3 files changed, 37 insertions(+)

diff --git a/target/i386/cpu.h b/target/i386/cpu.h
index f64e5ed827..10264b2e31 100644
--- a/target/i386/cpu.h
+++ b/target/i386/cpu.h
@@ -353,6 +353,7 @@ typedef enum X86Seg {
 #define MSR_IA32_APICBASE_BASE  (0xfU<<12)
 #define MSR_IA32_FEATURE_CONTROL0x003a
 #define MSR_TSC_ADJUST  0x003b
+#define MSR_IA32_SPEC_CTRL  0x48
 #define MSR_IA32_TSCDEADLINE0x6e0
 
 #define FEATURE_CONTROL_LOCKED(1<<0)
@@ -1125,6 +1126,8 @@ typedef struct CPUX86State {
 
 uint32_t pkru;
 
+uint64_t spec_ctrl;
+
 /* End of state preserved by INIT (dummy marker).  */
 struct {} end_init_save;
 
diff --git a/target/i386/kvm.c b/target/i386/kvm.c
index 4912f4d538..ad4b159b28 100644
--- a/target/i386/kvm.c
+++ b/target/i386/kvm.c
@@ -91,6 +91,7 @@ static bool has_msr_hv_synic;
 static bool has_msr_hv_stimer;
 static bool has_msr_hv_frequencies;
 static bool has_msr_xss;
+static bool has_msr_spec_ctrl;
 
 static uint32_t has_architectural_pmu_version;
 static uint32_t num_architectural_pmu_gp_counters;
@@ -1153,6 +1154,9 @@ static int kvm_get_supported_msrs(KVMState *s)
 case HV_X64_MSR_TSC_FREQUENCY:
 has_msr_hv_frequencies = true;
 break;
+case MSR_IA32_SPEC_CTRL:
+has_msr_spec_ctrl = true;
+break;
 }
 }
 }
@@ -1635,6 +1639,9 @@ static int kvm_put_msrs(X86CPU *cpu, int level)
 if (has_msr_xss) {
 kvm_msr_entry_add(cpu, MSR_IA32_XSS, env->xss);
 }
+if (has_msr_spec_ctrl) {
+kvm_msr_entry_add(cpu, MSR_IA32_SPEC_CTRL, env->spec_ctrl);
+}
 #ifdef TARGET_X86_64
 if (lm_capable_kernel) {
 kvm_msr_entry_add(cpu, MSR_CSTAR, env->cstar);
@@ -1643,6 +1650,7 @@ static int kvm_put_msrs(X86CPU *cpu, int level)
 kvm_msr_entry_add(cpu, MSR_LSTAR, env->lstar);
 }
 #endif
+
 /*
  * The following MSRs have side effects on the guest or are too heavy
  * for normal writeback. Limit them to reset or full state updates.
@@ -1980,6 +1988,9 @@ static int kvm_get_msrs(X86CPU *cpu)
 if (has_msr_xss) {
 kvm_msr_entry_add(cpu, MSR_IA32_XSS, 0);
 }
+if (has_msr_spec_ctrl) {
+kvm_msr_entry_add(cpu, MSR_IA32_SPEC_CTRL, 0);
+}
 
 
 if (!env->tsc_valid) {
@@ -2327,6 +2338,9 @@ static int kvm_get_msrs(X86CPU *cpu)
 env->mtrr_var[MSR_MTRRphysIndex(index)].base = msrs[i].data;
 }
 break;
+case MSR_IA32_SPEC_CTRL:
+env->spec_ctrl = msrs[i].data;
+break;
 }
 }
 
diff --git a/target/i386/machine.c b/target/i386/machine.c
index df5ec359eb..361c05aedf 100644
--- a/target/i386/machine.c
+++ b/target/i386/machine.c
@@ -818,6 +818,25 @@ static const VMStateDescription vmstate_mcg_ext_ctl = {
 }
 };
 
+static bool spec_ctrl_needed(void *opaque)
+{
+X86CPU *cpu = opaque;
+CPUX86State *env = >env;
+
+return env->spec_ctrl != 0;
+}
+
+static const VMStateDescription vmstate_spec_ctrl = {
+.name = "cpu/spec_ctrl",
+.version_id = 1,
+.minimum_version_id = 1,
+.needed = spec_ctrl_needed,
+.fields = (VMStateField[]){
+VMSTATE_UINT64(env.spec_ctrl, X86CPU),
+VMSTATE_END_OF_LIST()
+}
+};
+
 VMStateDescription vmstate_x86_cpu = {
 .name = "cpu",
 .version_id = 12,
@@ -936,6 +955,7 @@ VMStateDescription vmstate_x86_cpu = {
 #ifdef TARGET_X86_64
 _pkru,
 #endif
+_spec_ctrl,
 _mcg_ext_ctl,
 NULL
 }
-- 
2.14.3

[Qemu-devel] [PULL 6/8] i386: Add FEAT_8000_0008_EBX CPUID feature word

[Eduardo Habkost]

Add the new feature word and the "ibpb" feature flag.

Based on a patch by Paolo Bonzini.

Signed-off-by: Eduardo Habkost 
Message-Id: <20180109154519.25634-5-ehabk...@redhat.com>
Signed-off-by: Eduardo Habkost 
---
 target/i386/cpu.h |  3 +++
 target/i386/cpu.c | 19 ++-
 2 files changed, 21 insertions(+), 1 deletion(-)

diff --git a/target/i386/cpu.h b/target/i386/cpu.h
index d7bae242cd..30cc5628d2 100644
--- a/target/i386/cpu.h
+++ b/target/i386/cpu.h
@@ -472,6 +472,7 @@ typedef enum FeatureWord {
 FEAT_8000_0001_EDX, /* CPUID[8000_0001].EDX */
 FEAT_8000_0001_ECX, /* CPUID[8000_0001].ECX */
 FEAT_8000_0007_EDX, /* CPUID[8000_0007].EDX */
+FEAT_8000_0008_EBX, /* CPUID[8000_0008].EBX */
 FEAT_C000_0001_EDX, /* CPUID[C000_0001].EDX */
 FEAT_KVM,   /* CPUID[4000_0001].EAX (KVM_CPUID_FEATURES) */
 FEAT_HYPERV_EAX,/* CPUID[4000_0003].EAX */
@@ -669,6 +670,8 @@ typedef uint32_t FeatureWordArray[FEATURE_WORDS];
 #define CPUID_7_0_EDX_AVX512_4FMAPS (1U << 3) /* AVX512 Multiply Accumulation 
Single Precision */
 #define CPUID_7_0_EDX_SPEC_CTRL (1U << 26) /* Speculation Control */
 
+#define CPUID_8000_0008_EBX_IBPB(1U << 12) /* Indirect Branch Prediction 
Barrier */
+
 #define CPUID_XSAVE_XSAVEOPT   (1U << 0)
 #define CPUID_XSAVE_XSAVEC (1U << 1)
 #define CPUID_XSAVE_XGETBV1(1U << 2)
diff --git a/target/i386/cpu.c b/target/i386/cpu.c
index 7f815458a5..6fe14362cc 100644
--- a/target/i386/cpu.c
+++ b/target/i386/cpu.c
@@ -483,6 +483,22 @@ static FeatureWordInfo feature_word_info[FEATURE_WORDS] = {
 .tcg_features = TCG_APM_FEATURES,
 .unmigratable_flags = CPUID_APM_INVTSC,
 },
+[FEAT_8000_0008_EBX] = {
+.feat_names = {
+NULL, NULL, NULL, NULL,
+NULL, NULL, NULL, NULL,
+NULL, NULL, NULL, NULL,
+"ibpb", NULL, NULL, NULL,
+NULL, NULL, NULL, NULL,
+NULL, NULL, NULL, NULL,
+NULL, NULL, NULL, NULL,
+NULL, NULL, NULL, NULL,
+},
+.cpuid_eax = 0x8008,
+.cpuid_reg = R_EBX,
+.tcg_features = 0,
+.unmigratable_flags = 0,
+},
 [FEAT_XSAVE] = {
 .feat_names = {
 "xsaveopt", "xsavec", "xgetbv1", "xsaves",
@@ -3130,7 +3146,7 @@ void cpu_x86_cpuid(CPUX86State *env, uint32_t index, 
uint32_t count,
 } else {
 *eax = cpu->phys_bits;
 }
-*ebx = 0;
+*ebx = env->features[FEAT_8000_0008_EBX];
 *ecx = 0;
 *edx = 0;
 if (cs->nr_cores * cs->nr_threads > 1) {
@@ -3593,6 +3609,7 @@ static void x86_cpu_expand_features(X86CPU *cpu, Error 
**errp)
 x86_cpu_adjust_feat_level(cpu, FEAT_8000_0001_EDX);
 x86_cpu_adjust_feat_level(cpu, FEAT_8000_0001_ECX);
 x86_cpu_adjust_feat_level(cpu, FEAT_8000_0007_EDX);
+x86_cpu_adjust_feat_level(cpu, FEAT_8000_0008_EBX);
 x86_cpu_adjust_feat_level(cpu, FEAT_C000_0001_EDX);
 x86_cpu_adjust_feat_level(cpu, FEAT_SVM);
 x86_cpu_adjust_feat_level(cpu, FEAT_XSAVE);
-- 
2.14.3

[Qemu-devel] [PULL 5/8] i386: Add spec-ctrl CPUID bit

[Eduardo Habkost]

Add the feature name and a CPUID_7_0_EDX_SPEC_CTRL macro.

Signed-off-by: Eduardo Habkost 
Message-Id: <20180109154519.25634-4-ehabk...@redhat.com>
Signed-off-by: Eduardo Habkost 
---
 target/i386/cpu.h | 1 +
 target/i386/cpu.c | 2 +-
 2 files changed, 2 insertions(+), 1 deletion(-)

diff --git a/target/i386/cpu.h b/target/i386/cpu.h
index 10264b2e31..d7bae242cd 100644
--- a/target/i386/cpu.h
+++ b/target/i386/cpu.h
@@ -667,6 +667,7 @@ typedef uint32_t FeatureWordArray[FEATURE_WORDS];
 
 #define CPUID_7_0_EDX_AVX512_4VNNIW (1U << 2) /* AVX512 Neural Network 
Instructions */
 #define CPUID_7_0_EDX_AVX512_4FMAPS (1U << 3) /* AVX512 Multiply Accumulation 
Single Precision */
+#define CPUID_7_0_EDX_SPEC_CTRL (1U << 26) /* Speculation Control */
 
 #define CPUID_XSAVE_XSAVEOPT   (1U << 0)
 #define CPUID_XSAVE_XSAVEC (1U << 1)
diff --git a/target/i386/cpu.c b/target/i386/cpu.c
index 0e26fa4ea7..7f815458a5 100644
--- a/target/i386/cpu.c
+++ b/target/i386/cpu.c
@@ -459,7 +459,7 @@ static FeatureWordInfo feature_word_info[FEATURE_WORDS] = {
 NULL, NULL, NULL, NULL,
 NULL, NULL, NULL, NULL,
 NULL, NULL, NULL, NULL,
-NULL, NULL, NULL, NULL,
+NULL, NULL, "spec-ctrl", NULL,
 NULL, NULL, NULL, NULL,
 },
 .cpuid_eax = 7,
-- 
2.14.3

[Qemu-devel] [PULL 3/8] i386: Change X86CPUDefinition::model_id to const char*

[Eduardo Habkost]

It is valid to have a 48-character model ID on CPUID, however the
definition of X86CPUDefinition::model_id is char[48], which can
make the compiler drop the null terminator from the string.

If a CPU model happens to have 48 bytes on model_id, "-cpu help"
will print garbage and the object_property_set_str() call at
x86_cpu_load_def() will read data outside the model_id array.

We could increase the array size to 49, but this would mean the
compiler would not issue a warning if a 49-char string is used by
mistake for model_id.

To make things simpler, simply change model_id to be const char*,
and validate the string length using an assert() on
x86_register_cpudef_type().

Reported-by: "Dr. David Alan Gilbert" 
Signed-off-by: Eduardo Habkost 
Message-Id: <20180109154519.25634-2-ehabk...@redhat.com>
Signed-off-by: Eduardo Habkost 
---
 target/i386/cpu.c | 9 -
 1 file changed, 8 insertions(+), 1 deletion(-)

diff --git a/target/i386/cpu.c b/target/i386/cpu.c
index 4385853646..0e26fa4ea7 100644
--- a/target/i386/cpu.c
+++ b/target/i386/cpu.c
@@ -754,7 +754,7 @@ struct X86CPUDefinition {
 int model;
 int stepping;
 FeatureWordArray features;
-char model_id[48];
+const char *model_id;
 };
 
 static X86CPUDefinition builtin_x86_defs[] = {
@@ -923,6 +923,7 @@ static X86CPUDefinition builtin_x86_defs[] = {
 .features[FEAT_1_EDX] =
 I486_FEATURES,
 .xlevel = 0,
+.model_id = "",
 },
 {
 .name = "pentium",
@@ -934,6 +935,7 @@ static X86CPUDefinition builtin_x86_defs[] = {
 .features[FEAT_1_EDX] =
 PENTIUM_FEATURES,
 .xlevel = 0,
+.model_id = "",
 },
 {
 .name = "pentium2",
@@ -945,6 +947,7 @@ static X86CPUDefinition builtin_x86_defs[] = {
 .features[FEAT_1_EDX] =
 PENTIUM2_FEATURES,
 .xlevel = 0,
+.model_id = "",
 },
 {
 .name = "pentium3",
@@ -956,6 +959,7 @@ static X86CPUDefinition builtin_x86_defs[] = {
 .features[FEAT_1_EDX] =
 PENTIUM3_FEATURES,
 .xlevel = 0,
+.model_id = "",
 },
 {
 .name = "athlon",
@@ -2736,6 +2740,9 @@ static void x86_register_cpudef_type(X86CPUDefinition 
*def)
  * they shouldn't be set on the CPU model table.
  */
 assert(!(def->features[FEAT_8000_0001_EDX] & CPUID_EXT2_AMD_ALIASES));
+/* catch mistakes instead of silently truncating model_id when too long */
+assert(def->model_id && strlen(def->model_id) <= 48);
+
 
 type_register();
 g_free(typename);
-- 
2.14.3

[Qemu-devel] [PULL 8/8] i386: Add EPYC-IBPB CPU model

[Eduardo Habkost]

EPYC-IBPB is a copy of the EPYC CPU model with
just CPUID_8000_0008_EBX_IBPB added.

Cc: Jiri Denemark 
Cc: Tom Lendacky 
Cc: Brijesh Singh 
Signed-off-by: Eduardo Habkost 
Message-Id: <20180109154519.25634-7-ehabk...@redhat.com>
Signed-off-by: Eduardo Habkost 
---
 target/i386/cpu.c | 46 ++
 1 file changed, 46 insertions(+)

diff --git a/target/i386/cpu.c b/target/i386/cpu.c
index 365458a6a0..a49d2221ad 100644
--- a/target/i386/cpu.c
+++ b/target/i386/cpu.c
@@ -1968,6 +1968,52 @@ static X86CPUDefinition builtin_x86_defs[] = {
 .xlevel = 0x800A,
 .model_id = "AMD EPYC Processor",
 },
+{
+.name = "EPYC-IBPB",
+.level = 0xd,
+.vendor = CPUID_VENDOR_AMD,
+.family = 23,
+.model = 1,
+.stepping = 2,
+.features[FEAT_1_EDX] =
+CPUID_SSE2 | CPUID_SSE | CPUID_FXSR | CPUID_MMX | CPUID_CLFLUSH |
+CPUID_PSE36 | CPUID_PAT | CPUID_CMOV | CPUID_MCA | CPUID_PGE |
+CPUID_MTRR | CPUID_SEP | CPUID_APIC | CPUID_CX8 | CPUID_MCE |
+CPUID_PAE | CPUID_MSR | CPUID_TSC | CPUID_PSE | CPUID_DE |
+CPUID_VME | CPUID_FP87,
+.features[FEAT_1_ECX] =
+CPUID_EXT_RDRAND | CPUID_EXT_F16C | CPUID_EXT_AVX |
+CPUID_EXT_XSAVE | CPUID_EXT_AES |  CPUID_EXT_POPCNT |
+CPUID_EXT_MOVBE | CPUID_EXT_SSE42 | CPUID_EXT_SSE41 |
+CPUID_EXT_CX16 | CPUID_EXT_FMA | CPUID_EXT_SSSE3 |
+CPUID_EXT_MONITOR | CPUID_EXT_PCLMULQDQ | CPUID_EXT_SSE3,
+.features[FEAT_8000_0001_EDX] =
+CPUID_EXT2_LM | CPUID_EXT2_RDTSCP | CPUID_EXT2_PDPE1GB |
+CPUID_EXT2_FFXSR | CPUID_EXT2_MMXEXT | CPUID_EXT2_NX |
+CPUID_EXT2_SYSCALL,
+.features[FEAT_8000_0001_ECX] =
+CPUID_EXT3_OSVW | CPUID_EXT3_3DNOWPREFETCH |
+CPUID_EXT3_MISALIGNSSE | CPUID_EXT3_SSE4A | CPUID_EXT3_ABM |
+CPUID_EXT3_CR8LEG | CPUID_EXT3_SVM | CPUID_EXT3_LAHF_LM,
+.features[FEAT_8000_0008_EBX] =
+CPUID_8000_0008_EBX_IBPB,
+.features[FEAT_7_0_EBX] =
+CPUID_7_0_EBX_FSGSBASE | CPUID_7_0_EBX_BMI1 | CPUID_7_0_EBX_AVX2 |
+CPUID_7_0_EBX_SMEP | CPUID_7_0_EBX_BMI2 | CPUID_7_0_EBX_RDSEED |
+CPUID_7_0_EBX_ADX | CPUID_7_0_EBX_SMAP | CPUID_7_0_EBX_CLFLUSHOPT |
+CPUID_7_0_EBX_SHA_NI,
+/* Missing: XSAVES (not supported by some Linux versions,
+ * including v4.1 to v4.12).
+ * KVM doesn't yet expose any XSAVES state save component.
+ */
+.features[FEAT_XSAVE] =
+CPUID_XSAVE_XSAVEOPT | CPUID_XSAVE_XSAVEC |
+CPUID_XSAVE_XGETBV1,
+.features[FEAT_6_EAX] =
+CPUID_6_EAX_ARAT,
+.xlevel = 0x800A,
+.model_id = "AMD EPYC Processor (with IBPB)",
+},
 };
 
 typedef struct PropValue {
-- 
2.14.3

[Qemu-devel] [PULL 0/8] x86 queue, 2018-01-17

[Eduardo Habkost]

The following changes since commit 8e5dc9ba49743b46d955ec7dacb04e42ae7ada7c:

  Merge remote-tracking branch 'remotes/rth/tags/pull-tcg-20180116' into 
staging (2018-01-16 17:36:39 +)

are available in the Git repository at:

  git://github.com/ehabkost/qemu.git tags/x86-pull-request

for you to fetch changes up to 6cfbc54e8903a9bcc0346119949162d040c144c1:

  i386: Add EPYC-IBPB CPU model (2018-01-17 23:54:39 -0200)


x86 queue, 2018-01-17

Highlight: new CPU models that expose CPU features that guests
can use to mitigate CVE-2017-5715 (Spectre variant #2).



Eduardo Habkost (5):
  i386: Change X86CPUDefinition::model_id to const char*
  i386: Add spec-ctrl CPUID bit
  i386: Add FEAT_8000_0008_EBX CPUID feature word
  i386: Add new -IBRS versions of Intel CPU models
  i386: Add EPYC-IBPB CPU model

Haozhong Zhang (2):
  pc: add 2.12 machine types
  target/i386: add clflushopt to "Skylake-Server" cpu model

Paolo Bonzini (1):
  i386: Add support for SPEC_CTRL MSR

 include/hw/i386/pc.h  |   8 +
 target/i386/cpu.h |   7 +
 hw/i386/pc_piix.c |  15 +-
 hw/i386/pc_q35.c  |  13 +-
 target/i386/cpu.c | 457 +-
 target/i386/kvm.c |  14 ++
 target/i386/machine.c |  20 +++
 7 files changed, 524 insertions(+), 10 deletions(-)

-- 
2.14.3

[Qemu-devel] [PULL 1/8] pc: add 2.12 machine types

[Eduardo Habkost]

From: Haozhong Zhang 

Signed-off-by: Haozhong Zhang 
Message-Id: <20171219033730.12748-2-haozhong.zh...@intel.com>
Signed-off-by: Eduardo Habkost 
---
 include/hw/i386/pc.h |  3 +++
 hw/i386/pc_piix.c| 15 ---
 hw/i386/pc_q35.c | 13 +++--
 3 files changed, 26 insertions(+), 5 deletions(-)

diff --git a/include/hw/i386/pc.h b/include/hw/i386/pc.h
index 6f77eb0665..83d825e896 100644
--- a/include/hw/i386/pc.h
+++ b/include/hw/i386/pc.h
@@ -321,6 +321,9 @@ int e820_add_entry(uint64_t, uint64_t, uint32_t);
 int e820_get_num_entries(void);
 bool e820_get_entry(int, uint32_t, uint64_t *, uint64_t *);
 
+#define PC_COMPAT_2_11 \
+HW_COMPAT_2_11 \
+
 #define PC_COMPAT_2_10 \
 HW_COMPAT_2_10 \
 {\
diff --git a/hw/i386/pc_piix.c b/hw/i386/pc_piix.c
index 2febd0e136..a25619dfbf 100644
--- a/hw/i386/pc_piix.c
+++ b/hw/i386/pc_piix.c
@@ -426,21 +426,30 @@ static void pc_i440fx_machine_options(MachineClass *m)
 m->default_display = "std";
 }
 
-static void pc_i440fx_2_11_machine_options(MachineClass *m)
+static void pc_i440fx_2_12_machine_options(MachineClass *m)
 {
 pc_i440fx_machine_options(m);
 m->alias = "pc";
 m->is_default = 1;
 }
 
+DEFINE_I440FX_MACHINE(v2_12, "pc-i440fx-2.12", NULL,
+  pc_i440fx_2_12_machine_options);
+
+static void pc_i440fx_2_11_machine_options(MachineClass *m)
+{
+pc_i440fx_2_12_machine_options(m);
+m->is_default = 0;
+m->alias = NULL;
+SET_MACHINE_COMPAT(m, PC_COMPAT_2_11);
+}
+
 DEFINE_I440FX_MACHINE(v2_11, "pc-i440fx-2.11", NULL,
   pc_i440fx_2_11_machine_options);
 
 static void pc_i440fx_2_10_machine_options(MachineClass *m)
 {
 pc_i440fx_2_11_machine_options(m);
-m->is_default = 0;
-m->alias = NULL;
 SET_MACHINE_COMPAT(m, PC_COMPAT_2_10);
 m->auto_enable_numa_with_memhp = false;
 }
diff --git a/hw/i386/pc_q35.c b/hw/i386/pc_q35.c
index d6060043ac..5c6c608fcb 100644
--- a/hw/i386/pc_q35.c
+++ b/hw/i386/pc_q35.c
@@ -303,19 +303,28 @@ static void pc_q35_machine_options(MachineClass *m)
 m->max_cpus = 288;
 }
 
-static void pc_q35_2_11_machine_options(MachineClass *m)
+static void pc_q35_2_12_machine_options(MachineClass *m)
 {
 pc_q35_machine_options(m);
 m->alias = "q35";
 }
 
+DEFINE_Q35_MACHINE(v2_12, "pc-q35-2.12", NULL,
+   pc_q35_2_12_machine_options);
+
+static void pc_q35_2_11_machine_options(MachineClass *m)
+{
+pc_q35_2_12_machine_options(m);
+m->alias = NULL;
+SET_MACHINE_COMPAT(m, PC_COMPAT_2_11);
+}
+
 DEFINE_Q35_MACHINE(v2_11, "pc-q35-2.11", NULL,
pc_q35_2_11_machine_options);
 
 static void pc_q35_2_10_machine_options(MachineClass *m)
 {
 pc_q35_2_11_machine_options(m);
-m->alias = NULL;
 SET_MACHINE_COMPAT(m, PC_COMPAT_2_10);
 m->numa_auto_assign_ram = numa_legacy_auto_assign_ram;
 m->auto_enable_numa_with_memhp = false;
-- 
2.14.3

[Qemu-devel] [PULL 2/8] target/i386: add clflushopt to "Skylake-Server" cpu model

[Eduardo Habkost]

From: Haozhong Zhang 

CPUID_7_0_EBX_CLFLUSHOPT is missed in current "Skylake-Server" cpu
model. Add it to "Skylake-Server" cpu model on pc-i440fx-2.12 and
pc-q35-2.12. Keep it disabled in "Skylake-Server" cpu model on older
machine types.

Signed-off-by: Haozhong Zhang 
Message-Id: <20171219033730.12748-3-haozhong.zh...@intel.com>
Reviewed-by: Eduardo Habkost 
Reviewed-by: Michael S. Tsirkin 
Signed-off-by: Eduardo Habkost 
---
 include/hw/i386/pc.h | 5 +
 target/i386/cpu.c| 2 +-
 2 files changed, 6 insertions(+), 1 deletion(-)

diff --git a/include/hw/i386/pc.h b/include/hw/i386/pc.h
index 83d825e896..bb49165fe0 100644
--- a/include/hw/i386/pc.h
+++ b/include/hw/i386/pc.h
@@ -323,6 +323,11 @@ bool e820_get_entry(int, uint32_t, uint64_t *, uint64_t *);
 
 #define PC_COMPAT_2_11 \
 HW_COMPAT_2_11 \
+{\
+.driver   = "Skylake-Server" "-" TYPE_X86_CPU,\
+.property = "clflushopt",\
+.value= "off",\
+},
 
 #define PC_COMPAT_2_10 \
 HW_COMPAT_2_10 \
diff --git a/target/i386/cpu.c b/target/i386/cpu.c
index ad8196b166..4385853646 100644
--- a/target/i386/cpu.c
+++ b/target/i386/cpu.c
@@ -1382,7 +1382,7 @@ static X86CPUDefinition builtin_x86_defs[] = {
 CPUID_7_0_EBX_SMAP | CPUID_7_0_EBX_MPX | CPUID_7_0_EBX_CLWB |
 CPUID_7_0_EBX_AVX512F | CPUID_7_0_EBX_AVX512DQ |
 CPUID_7_0_EBX_AVX512BW | CPUID_7_0_EBX_AVX512CD |
-CPUID_7_0_EBX_AVX512VL,
+CPUID_7_0_EBX_AVX512VL | CPUID_7_0_EBX_CLFLUSHOPT,
 /* Missing: XSAVES (not supported by some Linux versions,
  * including v4.1 to v4.12).
  * KVM doesn't yet expose any XSAVES state save component,
-- 
2.14.3

Re: [Qemu-devel] [PATCH 22/24] cpu: get rid of unused cpu_init() defines

[Eduardo Habkost]

On Wed, Jan 17, 2018 at 04:43:34PM +0100, Igor Mammedov wrote:
> cpu_init(cpu_model) were replaced by cpu_create(cpu_type) so
> no users are left, remove it.
> 
> Signed-off-by: Igor Mammedov 

Wonderful.

Reviewed-by: Eduardo Habkost 

-- 
Eduardo

Re: [Qemu-devel] [PATCH 20/24] machine: drop MachineState::cpu_model

[Eduardo Habkost]

On Wed, Jan 17, 2018 at 04:43:32PM +0100, Igor Mammedov wrote:
> The last user of it was machine type 'none', which used field
> to create CPU id user requested it on CLI with -cpu option.
> 
> We could compare pointers of MachineState::cpu_type and
> MachineClass::default_cpu_type to check for the same condition,
> and drop cpu_model concept completly from machine/boards code
> So that no one would try to reuse obsolete field and only
> place to deal with cpu model would be vl.c and
> foo_cpu_class_by_name() callbacks.
> 
> Signed-off-by: Igor Mammedov 
> ---
> CC: Eduardo Habkost 
> CC: Marcel Apfelbaum 
> CC: Paolo Bonzini 
> ---
>  include/hw/boards.h|  1 -
>  hw/core/null-machine.c | 10 +++---
>  vl.c   |  8 +++-
>  3 files changed, 14 insertions(+), 5 deletions(-)
> 
> diff --git a/include/hw/boards.h b/include/hw/boards.h
> index 156b16f..decd0ec 100644
> --- a/include/hw/boards.h
> +++ b/include/hw/boards.h
> @@ -246,7 +246,6 @@ struct MachineState {
>  char *kernel_filename;
>  char *kernel_cmdline;
>  char *initrd_filename;
> -const char *cpu_model;
>  const char *cpu_type;
>  AccelState *accelerator;
>  CPUArchIdList *possible_cpus;
> diff --git a/hw/core/null-machine.c b/hw/core/null-machine.c
> index 864832d..c2e466c 100644
> --- a/hw/core/null-machine.c
> +++ b/hw/core/null-machine.c
> @@ -23,10 +23,13 @@
>  static void machine_none_init(MachineState *mch)
>  {
>  CPUState *cpu = NULL;
> +MachineClass *mc = MACHINE_GET_CLASS(mch);
>  
> -/* Initialize CPU (if a model has been specified) */
> -if (mch->cpu_model) {
> -cpu = cpu_init(mch->cpu_model);
> +/* Initialize CPU if cpu_type pointer is user provided
> + * (i.e. != to pointer tot static default cpu type string)
> + */
> +if (mch->cpu_type != mc->default_cpu_type) {
> +cpu = cpu_create(mch->cpu_type);

This is a big assumption about the code that sets mch->cpu_type.
A simple g_strdup(machine_class->default_cpu_type) would break
this silently (as it won't trigger the assert() below).


>  if (!cpu) {
>  error_report("Unable to initialize CPU");
>  exit(1);
> @@ -54,6 +57,7 @@ static void machine_none_machine_init(MachineClass *mc)
>  mc->init = machine_none_init;
>  mc->max_cpus = 1;
>  mc->default_ram_size = 0;
> +mc->default_cpu_type = TARGET_DEFAULT_CPU_TYPE;

Why do you need this?  Isn't it simpler to just leave
default_cpu_type=NULL here?


>  }
>  
>  DEFINE_MACHINE("none", machine_none_machine_init)
> diff --git a/vl.c b/vl.c
> index 2586f25..8aa0131 100644
> --- a/vl.c
> +++ b/vl.c
> @@ -4609,7 +4609,6 @@ int main(int argc, char **argv, char **envp)
>  current_machine->maxram_size = maxram_size;
>  current_machine->ram_slots = ram_slots;
>  current_machine->boot_order = boot_order;
> -current_machine->cpu_model = cpu_model;
>  
>  parse_numa_opts(current_machine);
>  
> @@ -4619,6 +4618,13 @@ int main(int argc, char **argv, char **envp)
>  if (cpu_model) {
>  current_machine->cpu_type =
>  cpu_parse_cpu_model(machine_class->default_cpu_type, 
> cpu_model);
> +
> +/* machine 'none' depends on default cpu type pointer not being
> + * equal to resolved type name pointer to fugure out if type was
> + * user provided, make sure that if it becomes not true in future
> + * it won't beark silently */
> +g_assert(
> +current_machine->cpu_type != 
> machine_class->default_cpu_type);
>  }
>  }
>  
> -- 
> 2.7.4
> 

-- 
Eduardo

Re: [Qemu-devel] [PATCH 11/24] ppc: cpu: add TARGET_DEFAULT_CPU_TYPE macro

[David Gibson]

On Wed, Jan 17, 2018 at 04:43:23PM +0100, Igor Mammedov wrote:
> it will be used for for 2 purposes, 1st is to
> provide to cpu name resolving class for machine 'none'
>   cpu_parse_cpu_model(machine_class->default_cpu_type, cpu_model)
> and later to drop a bunch of ifdefs *-user/main.c that
> set default cpu_model.
> 
> Use default values from linux-user for TARGET_DEFAULT_CPU_TYPE.
> While at it fixup linux-user to use corresponding cpu models
> instead of aliases.
> 
> Signed-off-by: Igor Mammedov 

Acked-by: David Gibson 

> ---
> CC: Riku Voipio 
> CC: Laurent Vivier 
> CC: David Gibson 
> CC: Alexander Graf 
> CC: qemu-...@nongnu.org
> ---
>  target/ppc/cpu.h  | 6 ++
>  linux-user/main.c | 4 ++--
>  2 files changed, 8 insertions(+), 2 deletions(-)
> 
> diff --git a/target/ppc/cpu.h b/target/ppc/cpu.h
> index a5e49f2..4af4aff 100644
> --- a/target/ppc/cpu.h
> +++ b/target/ppc/cpu.h
> @@ -1377,6 +1377,12 @@ int ppc_dcr_write (ppc_dcr_t *dcr_env, int dcrn, 
> uint32_t val);
>  #define POWERPC_CPU_TYPE_SUFFIX "-" TYPE_POWERPC_CPU
>  #define POWERPC_CPU_TYPE_NAME(model) model POWERPC_CPU_TYPE_SUFFIX
>  
> +#ifdef TARGET_PPC64
> +#define TARGET_DEFAULT_CPU_TYPE POWERPC_CPU_TYPE_NAME("power8_v2.0")
> +#else
> +#define TARGET_DEFAULT_CPU_TYPE POWERPC_CPU_TYPE_NAME("750_v3.1")
> +#endif
> +
>  #define cpu_signal_handler cpu_ppc_signal_handler
>  #define cpu_list ppc_cpu_list
>  
> diff --git a/linux-user/main.c b/linux-user/main.c
> index 54e8aac..279cd97 100644
> --- a/linux-user/main.c
> +++ b/linux-user/main.c
> @@ -4343,9 +4343,9 @@ int main(int argc, char **argv, char **envp)
>  cpu_model = "or1200";
>  #elif defined(TARGET_PPC)
>  # ifdef TARGET_PPC64
> -cpu_model = "POWER8";
> +cpu_model = "power8_v2.0";
>  # else
> -cpu_model = "750";
> +cpu_model = "750_v3.1";
>  # endif
>  #elif defined TARGET_SH4
>  cpu_model = "sh7785";

-- 
David Gibson| I'll have my music baroque, and my code
david AT gibson.dropbear.id.au  | minimalist, thank you.  NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson


signature.asc
Description: PGP signature

Re: [Qemu-devel] [PATCH 1/3] spapr: drop duplicate variable in spapr_core_plug()

[David Gibson]

On Wed, Jan 17, 2018 at 10:20:27AM +0100, Greg Kurz wrote:
> A variable is already defined at the begining of the function to
> hold a pointer to the CPU core object:
> 
> sPAPRCPUCore *core = SPAPR_CPU_CORE(OBJECT(dev));
> 
> No need to define it again in the pre-2.10 compatibility code snipplet.
> 
> Signed-off-by: Greg Kurz 

Applied to ppc-for-2.12, thanks.

> ---
>  hw/ppc/spapr.c |4 +---
>  1 file changed, 1 insertion(+), 3 deletions(-)
> 
> diff --git a/hw/ppc/spapr.c b/hw/ppc/spapr.c
> index 499ab647d882..bca838fce638 100644
> --- a/hw/ppc/spapr.c
> +++ b/hw/ppc/spapr.c
> @@ -3362,9 +3362,7 @@ static void spapr_core_plug(HotplugHandler 
> *hotplug_dev, DeviceState *dev,
>  int i;
>  
>  for (i = 0; i < cc->nr_threads; i++) {
> -sPAPRCPUCore *sc = SPAPR_CPU_CORE(dev);
> -
> -cs = CPU(sc->threads[i]);
> +cs = CPU(core->threads[i]);
>  pre_2_10_vmstate_unregister_dummy_icp(cs->cpu_index);
>  }
>  }
> 

-- 
David Gibson| I'll have my music baroque, and my code
david AT gibson.dropbear.id.au  | minimalist, thank you.  NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson


signature.asc
Description: PGP signature

Re: [Qemu-devel] [PATCH v1 1/1] linux-user: Fix webkitgtk hangs on 32-bit x86 target

[Richard Henderson]

On 01/17/2018 12:39 PM, Alistair Francis wrote:
> Since commit "linux-user: Tidy and enforce reserved_va initialization"
> (18e80c55bb6ec17c05ec0ba717ec83933c2bfc07) the Yocto webkitgtk build
> hangs when cross compiling for 32-bit x86 on a 64-bit x86 machine using
> musl.
> 
> To fix the issue reduce the MAX_RESERVED_VA macro to be a closer match
> to what it was before the problematic commit.
> 
> Signed-off-by: Alistair Francis 
> ---

I don't like this at all.  You don't say why this hangs.
What is the actual host, x86_64 or i686?


r~

Re: [Qemu-devel] Functional tests (AKA Avocado-based tests)

[Cleber Rosa]

On 01/17/2018 06:41 PM, Alistair Francis wrote:
> On Wed, Jan 17, 2018 at 12:05 AM, Cleber Rosa  wrote:
>> TL;DR
>> =
>>
>> This is about how QEMU developers can get started with functional
>> tests that are built on top of the Avocado libraries (and meant to be
>> run with the Avocado test runner).
>>
>> The past
>> 
>>
>> The Avocado project[1] has been working, for quite some time now, on a
>> "set of tools and libraries" with the goal of making writing tests
>> easier.  It is supposed to be a framework agnostic to the exact
>> software that will be under test.
>>
>> But, at the same time, the Avocado project cannot deny its inheritance
>> and influences.  Those come from Autotest[2], which had "KVM Autotest"
>> as its largest and most developed "test".  This large Autotest test
>> (KVM Autotest) became virt-test[3] and later got integrated into
>> Avocado and became Avocado-VT[4] which is quite relevant here,
>> together with its QEMU test provider[5].
>>
>> Avocado-VT and the QEMU test provider attempt to provide coverage
>> across platform and QEMU versions, which increases its complexity.
>> Also, it's built on a legacy set of principles and tools that makes
>> some developers stir away from it.
>>
>> What's new?
>> ===
>>
>> A few months ago, the Avocado developers returned to its
>> "virtualization origins", in an attempt to learn from the QEMU
>> project, and try to help with a way to have more functional tests in
>> the upstream QEMU repo.
>>
>> We believe it's possible to expand the test coverage for QEMU by
>> facilitating
>> the creation of more functional tests QEMU.  This is no different than how
>> other types of tests are already included in the tree itself.
>>
>> How
>> ===
>>
>> How we did it (so far)
>> --
>>
>> We're aware that there's a dilemma here: to be able to easily write
>> more powerful tests, a lot of the complexity has to be moved
>> elsewhere.  Here, it means moving complexity from the test itself to a
>> framework.  The QEMU source tree itself has proofs of this approach,
>> being the "scripts" and "tests/qemu-iotests" some of the examples.
>>
>> Avocado itself[1] provides a lot of the code that should help to
>> absorb some of the complexities in writing tests, but not exactly
>> everything that is needed for QEMU.  The approach we believe will have
>> the best balance is to reuse upstream Avocado libraries whenever they
>> are useful and generic enough, and on top of that, libraries that are
>> part of QEMU itself.
>>
>> How can you get started with it
>> ---
>>
>> First of all, get Avocado installed.  Besides the Avocado test runner
>> itself, this will give you the basic libraries on which the other part
>> of this work was built on.  We want that to be simple and painless, so
>> here's our best bet for a one-liner installation:
>>
>>   pip install --user avocado-framework
>> avocado-framework-plugin-varianter-yaml-to-mux aexpect
>>
>> That will install Avocado within the user's home directory.  If you
>> give up on it, it can be uninstalled with another simple one-liner:
>>
>>   pip uninstall -y avocado-framework
>> avocado-framework-plugin-varianter-yaml-to-mux aexpect
>>
>> Now, suppose you're working on a given feature, and want to try your
>> luck writing a test using this work.  To avoid having you fetching and
>> rebasing from our currently in development fork[6] and branch[7], you
>> can just
>> add one commit to your tree with:
>>
>>   curl
>> https://patch-diff.githubusercontent.com/raw/apahim/qemu/pull/17.patch |
>> git am -
>>
>> This will get a simple patch from a snapshot branch[8].  You can, of course,
>> do it "the git way", fetching from that repo[6] and using the
>> non-snapshotted branch.
>>
>> After that, we'd love for you to take a look at some of the existing
>> tests[9][10] and then attempt to create test for your own use case.
>> The basic README[11] file, and the Avocado documentation[12] are also
>> important resources not to be missed.
>>
>> What's next?
>> 
>>
>> Initially, feedback is what we're looking for.  It would be greatly
>> appreciated to understand if/how this suits (or not) use cases out
>> there.
>>
>> After feedback, further refinements, and more tests are written, the
>> Avocado developers will follow up with an initial patch series for
>> upstream QEMU.  In such a proposal, we intend to have further
>> integration.  Ideally in way that "configure" can be given a
>> "--with-functional-[avocado-]tests" parameter of sorts, and a "make
>>  [functional-]check" would seamlessly include them.
> 
> I have a few thoughts.
> 
> We use pytest/pexpect internally to kick off QEMU runs and monitor the
> output (no interaction with the QEMU source tree) and I think it is
> extremely useful. So I am all for using Python to test things and this
> looks really well done!
> 

Thanks for checking it out, and for the positive words.  Now, sorry if

Re: [Qemu-devel] [PATCH 22/24] cpu: get rid of unused cpu_init() defines

[David Gibson]

On Wed, Jan 17, 2018 at 04:43:34PM +0100, Igor Mammedov wrote:
> cpu_init(cpu_model) were replaced by cpu_create(cpu_type) so
> no users are left, remove it.
> 
> Signed-off-by: Igor Mammedov 

ppc part

Acked-by: David Gibson 

> ---
> CC: Richard Henderson  (maintainer:Alpha)
> CC: Peter Maydell 
> CC: "Edgar E. Iglesias" 
> CC: Eduardo Habkost 
> CC: Michael Walle 
> CC: Laurent Vivier 
> CC: Aurelien Jarno 
> CC: Yongbok Kim 
> CC: Anthony Green 
> CC: Chris Wulff 
> CC: Marek Vasut 
> CC: Stafford Horne 
> CC: David Gibson 
> CC: Alexander Graf 
> CC: Mark Cave-Ayland 
> CC: Artyom Tarasenko 
> CC: Bastian Koppelmann 
> CC: Guan Xuetao 
> CC: Max Filippov 
> CC: qemu-...@nongnu.org
> CC: qemu-...@nongnu.org
> CC: qemu-s3...@nongnu.org
> ---
>  target/alpha/cpu.h  | 2 --
>  target/arm/cpu.h| 2 --
>  target/cris/cpu.h   | 2 --
>  target/hppa/cpu.h   | 1 -
>  target/i386/cpu.h   | 2 --
>  target/lm32/cpu.h   | 2 --
>  target/m68k/cpu.h   | 2 --
>  target/microblaze/cpu.h | 1 -
>  target/mips/cpu.h   | 2 --
>  target/moxie/cpu.h  | 2 --
>  target/nios2/cpu.h  | 1 -
>  target/openrisc/cpu.h   | 2 --
>  target/ppc/cpu.h| 2 --
>  target/s390x/cpu.h  | 2 --
>  target/sh4/cpu.h| 2 --
>  target/sparc/cpu.h  | 4 
>  target/tilegx/cpu.h | 1 -
>  target/tricore/cpu.h| 2 --
>  target/unicore32/cpu.h  | 2 --
>  target/xtensa/cpu.h | 2 --
>  20 files changed, 38 deletions(-)
> 
> diff --git a/target/alpha/cpu.h b/target/alpha/cpu.h
> index c8dd560..1a1d9a0 100644
> --- a/target/alpha/cpu.h
> +++ b/target/alpha/cpu.h
> @@ -468,8 +468,6 @@ enum {
>  
>  void alpha_translate_init(void);
>  
> -#define cpu_init(cpu_model) cpu_generic_init(TYPE_ALPHA_CPU, cpu_model)
> -
>  #define ALPHA_CPU_TYPE_SUFFIX "-" TYPE_ALPHA_CPU
>  #define ALPHA_CPU_TYPE_NAME(model) model ALPHA_CPU_TYPE_SUFFIX
>  #define TARGET_DEFAULT_CPU_TYPE ALPHA_CPU_TYPE_NAME("ev67")
> diff --git a/target/arm/cpu.h b/target/arm/cpu.h
> index c87bb76..3c1e1aa 100644
> --- a/target/arm/cpu.h
> +++ b/target/arm/cpu.h
> @@ -2167,8 +2167,6 @@ static inline bool arm_excp_unmasked(CPUState *cs, 
> unsigned int excp_idx,
>  return unmasked || pstate_unmasked;
>  }
>  
> -#define cpu_init(cpu_model) cpu_generic_init(TYPE_ARM_CPU, cpu_model)
> -
>  #define ARM_CPU_TYPE_SUFFIX "-" TYPE_ARM_CPU
>  #define ARM_CPU_TYPE_NAME(name) (name ARM_CPU_TYPE_SUFFIX)
>  #define TARGET_DEFAULT_CPU_TYPE ARM_CPU_TYPE_NAME("any")
> diff --git a/target/cris/cpu.h b/target/cris/cpu.h
> index 8feabb4..9845d89 100644
> --- a/target/cris/cpu.h
> +++ b/target/cris/cpu.h
> @@ -267,8 +267,6 @@ enum {
>  #define TARGET_PHYS_ADDR_SPACE_BITS 32
>  #define TARGET_VIRT_ADDR_SPACE_BITS 32
>  
> -#define cpu_init(cpu_model) cpu_generic_init(TYPE_CRIS_CPU, cpu_model)
> -
>  #define CRIS_CPU_TYPE_SUFFIX "-" TYPE_CRIS_CPU
>  #define CRIS_CPU_TYPE_NAME(name) (name CRIS_CPU_TYPE_SUFFIX)
>  #define TARGET_DEFAULT_CPU_TYPE CRIS_CPU_TYPE_NAME("crisv32")
> diff --git a/target/hppa/cpu.h b/target/hppa/cpu.h
> index 04625f7..7a6074e 100644
> --- a/target/hppa/cpu.h
> +++ b/target/hppa/cpu.h
> @@ -112,7 +112,6 @@ static inline int cpu_mmu_index(CPUHPPAState *env, bool 
> ifetch)
>  
>  void hppa_translate_init(void);
>  
> -#define cpu_init(cpu_model) cpu_generic_init(TYPE_HPPA_CPU, cpu_model)
>  #define TARGET_DEFAULT_CPU_TYPE TYPE_HPPA_CPU
>  
>  void hppa_cpu_list(FILE *f, fprintf_function cpu_fprintf);
> diff --git a/target/i386/cpu.h b/target/i386/cpu.h
> index f64e5ed..0b4563b 100644
> --- a/target/i386/cpu.h
> +++ b/target/i386/cpu.h
> @@ -1557,8 +1557,6 @@ uint64_t cpu_get_tsc(CPUX86State *env);
>  
>  #define PHYS_ADDR_MASK MAKE_64BIT_MASK(0, TCG_PHYS_ADDR_BITS)
>  
> -#define cpu_init(cpu_model) cpu_generic_init(TYPE_X86_CPU, cpu_model)
> -
>  #define X86_CPU_TYPE_SUFFIX "-" TYPE_X86_CPU
>  #define X86_CPU_TYPE_NAME(name) (name X86_CPU_TYPE_SUFFIX)
>  
> diff --git a/target/lm32/cpu.h b/target/lm32/cpu.h
> index 65f58f5..ec9efa7 100644
> --- a/target/lm32/cpu.h
> +++ b/target/lm32/cpu.h
> @@ -255,8 +255,6 @@ void lm32_watchpoint_insert(CPULM32State *env, int index, 
> target_ulong address,
>  void lm32_watchpoint_remove(CPULM32State *env, int index);
>  bool lm32_cpu_do_semihosting(CPUState *cs);
>  
> -#define cpu_init(cpu_model) cpu_generic_init(TYPE_LM32_CPU, cpu_model)
> -
>  #define LM32_CPU_TYPE_SUFFIX "-" TYPE_LM32_CPU
>  #define LM32_CPU_TYPE_NAME(model) model LM32_CPU_TYPE_SUFFIX
>  #define TARGET_DEFAULT_CPU_TYPE LM32_CPU_TYPE_NAME("lm32-basic")
> 

Re: [Qemu-devel] [PATCH 0/4] Implements the Windows Hypervisor Platform accelerator

[Justin Terry (VM) via Qemu-devel]

Hey Paolo,

Thanks for all the feedback. After talking with various members of the team 
around these scenarios I think its best we add the migration blockers for all 
of your comments unfortunately. The answers to your question are below:

1. For CPUID. The API has support for an "EXTENDED_VM_EXITS" of type 
WHvRunVpExitReasonX64Cpuid after a call to WHvRunVirtualProcessor. This will 
one day allow for the CPUID instruction to be resolved however it is not 
currently implemented in the platform. So for right now we will have to block 
on CPUID.

2. For dirty memory tracking. We currently don’t have support in the platform 
or API for this. I have added that to the feature backlog and will update QEMU 
as that gets implemented in the platform. However, VGA does indeed work with 
the current impl of log_sync.

3. Also, for XSAVE/RSTOR we again don’t have platform support for the required 
registers. I have added this to the feature platform backlog to gain access for 
that functionality as well.

4. This will be supported on Windows 10 hosts (I don’t have the insider build 
number yet) and it will require an Intel processor with VT-x and Unrestricted 
Guest support. Will update the qemu-devel list once we have an insider build 
that is public that has the platform bits.

So, if your ok with it I will block on CPUID, Memory Tracking, and XSAVE/RSTOR 
functionality and send out the updated PR.

-Justin

> -Original Message-
> From: Paolo Bonzini [mailto:pbonz...@redhat.com]
> Sent: Friday, January 12, 2018 12:48 PM
> To: Justin Terry (VM) 
> Cc: qemu-devel@nongnu.org qemu-devel 
> Subject: Re: [PATCH 0/4] Implements the Windows Hypervisor Platform
> accelerator
> 
> 
> > Hello QEMU Community!
> >
> > Over the past few months the Hyper-V team at Microsoft has been
> > working hard on a new user-mode API for our hypervisor that will be
> > released as part of the upcoming SDK. This new API adds user-mode
> > capabilities to create and manage partitions at the hypervisor level,
> > configure memory mappings for the partition, and create and control
> execution of virtual processors.
> >
> > With this new API we are now able to bring our hypervisor to the QEMU
> > community! The following patches implement the Windows Hypervisor
> > Platform accelerator (WHPX) for QEMU on Windows 10 hosts.
> >
> > When compiling QEMU for x86_64 passing the --enable-whpx flag will
> > compile the accelerator for use. At runtime using the '-accel whpx'
> > should see a significant performance improvement over emulation, much
> > like when using 'hax' on Windows.
> >
> > Over the next few days the pre-release version of the documentation
> > for this new API will be visible at
> >
> https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdocs.
> > microsoft.com%2Fen-
> us%2Fvirtualization=02%7C01%7Cjuterry%40microsoft.com%7Ce979c5
> 0ab5544ab2dec708d559fdc86f%7C72f988bf86f141af91ab2d7cd011db47%7C1
> %7C0%7C636513868884987772=E%2BE5DX%2FJqsK2%2BZJVWzQ3qFy
> Kg0YLKrg6EtzLkvnJqbU%3D=0 under the 'Windows Hypervisor
> Platform' section. Here you will see the requirements, API, and examples.
> 
> That's great!  Accelerator galore. :)
> 
> From a quick skim they patches seem to be generally pretty good!  I have a
> few quick question on a couple features that seem to be missing:
> 
> - an important missing feature is support for CPU models (e.g. "-cpu
> Haswell").  Code
>   for that was added recently for Hypervisor.framework and you should be
> able to copy
>   some of it and then more for your CPUID intercept.  However, the question
> I have is:
>   what interfaces does WHPX support to query the hypervisor's CPUID
> capabilities?
> 
> - is dirty memory support available?  The log_sync callback seems a bit
> incomplete :)
>   If it's not, VGA output probably will not work.
> 
> - I might have missed this because the relevant code is quite repetitive -
> what about
>   get/set of XSAVE areas?  If either this or dirty memory is not present, it's
> probably
>   best to block migration (grep for migration_blockers).
> 
> Also, what versions of Windows will support WHPX?
> 
> Thanks,
> 
> Paolo
> > Thank you for your feedback.
> >
> > Justin Terry (VM) (4):
> >   Add the Windows Hypervisor Platform accelerator.
> >   Add the WHPX vcpu API
> >   Introduce the WHPX impl
> >   Add the WHPX acceleration enlightenments
> >
> >  accel/stubs/Makefile.objs |9 +-
> >  accel/stubs/whpx-stub.c   |   48 ++
> >  configure |   48 +-
> >  cpus.c|   66 ++-
> >  include/sysemu/hw_accel.h |   13 +
> >  include/sysemu/whpx.h |   40 ++
> >  qemu-options.hx   |8 +-
> >  target/i386/Makefile.objs |1 +
> >  target/i386/helper.c  |2 +-
> >  target/i386/whpx-all.c| 1395
> >  +
> >  10 files changed, 1619 insertions(+), 11 deletions(-)  create mode
> > 100644 accel/stubs/whpx-stub.c  create 

Re: [Qemu-devel] Functional tests (AKA Avocado-based tests)

[Alistair Francis]

On Wed, Jan 17, 2018 at 12:05 AM, Cleber Rosa  wrote:
> TL;DR
> =
>
> This is about how QEMU developers can get started with functional
> tests that are built on top of the Avocado libraries (and meant to be
> run with the Avocado test runner).
>
> The past
> 
>
> The Avocado project[1] has been working, for quite some time now, on a
> "set of tools and libraries" with the goal of making writing tests
> easier.  It is supposed to be a framework agnostic to the exact
> software that will be under test.
>
> But, at the same time, the Avocado project cannot deny its inheritance
> and influences.  Those come from Autotest[2], which had "KVM Autotest"
> as its largest and most developed "test".  This large Autotest test
> (KVM Autotest) became virt-test[3] and later got integrated into
> Avocado and became Avocado-VT[4] which is quite relevant here,
> together with its QEMU test provider[5].
>
> Avocado-VT and the QEMU test provider attempt to provide coverage
> across platform and QEMU versions, which increases its complexity.
> Also, it's built on a legacy set of principles and tools that makes
> some developers stir away from it.
>
> What's new?
> ===
>
> A few months ago, the Avocado developers returned to its
> "virtualization origins", in an attempt to learn from the QEMU
> project, and try to help with a way to have more functional tests in
> the upstream QEMU repo.
>
> We believe it's possible to expand the test coverage for QEMU by
> facilitating
> the creation of more functional tests QEMU.  This is no different than how
> other types of tests are already included in the tree itself.
>
> How
> ===
>
> How we did it (so far)
> --
>
> We're aware that there's a dilemma here: to be able to easily write
> more powerful tests, a lot of the complexity has to be moved
> elsewhere.  Here, it means moving complexity from the test itself to a
> framework.  The QEMU source tree itself has proofs of this approach,
> being the "scripts" and "tests/qemu-iotests" some of the examples.
>
> Avocado itself[1] provides a lot of the code that should help to
> absorb some of the complexities in writing tests, but not exactly
> everything that is needed for QEMU.  The approach we believe will have
> the best balance is to reuse upstream Avocado libraries whenever they
> are useful and generic enough, and on top of that, libraries that are
> part of QEMU itself.
>
> How can you get started with it
> ---
>
> First of all, get Avocado installed.  Besides the Avocado test runner
> itself, this will give you the basic libraries on which the other part
> of this work was built on.  We want that to be simple and painless, so
> here's our best bet for a one-liner installation:
>
>   pip install --user avocado-framework
> avocado-framework-plugin-varianter-yaml-to-mux aexpect
>
> That will install Avocado within the user's home directory.  If you
> give up on it, it can be uninstalled with another simple one-liner:
>
>   pip uninstall -y avocado-framework
> avocado-framework-plugin-varianter-yaml-to-mux aexpect
>
> Now, suppose you're working on a given feature, and want to try your
> luck writing a test using this work.  To avoid having you fetching and
> rebasing from our currently in development fork[6] and branch[7], you
> can just
> add one commit to your tree with:
>
>   curl
> https://patch-diff.githubusercontent.com/raw/apahim/qemu/pull/17.patch |
> git am -
>
> This will get a simple patch from a snapshot branch[8].  You can, of course,
> do it "the git way", fetching from that repo[6] and using the
> non-snapshotted branch.
>
> After that, we'd love for you to take a look at some of the existing
> tests[9][10] and then attempt to create test for your own use case.
> The basic README[11] file, and the Avocado documentation[12] are also
> important resources not to be missed.
>
> What's next?
> 
>
> Initially, feedback is what we're looking for.  It would be greatly
> appreciated to understand if/how this suits (or not) use cases out
> there.
>
> After feedback, further refinements, and more tests are written, the
> Avocado developers will follow up with an initial patch series for
> upstream QEMU.  In such a proposal, we intend to have further
> integration.  Ideally in way that "configure" can be given a
> "--with-functional-[avocado-]tests" parameter of sorts, and a "make
>  [functional-]check" would seamlessly include them.

I have a few thoughts.

We use pytest/pexpect internally to kick off QEMU runs and monitor the
output (no interaction with the QEMU source tree) and I think it is
extremely useful. So I am all for using Python to test things and this
looks really well done!

What I don't understand though is what this gives us compared to the
existing QEMU test infrastructure? Besides being able to use Python
and a better interface what are the main benefits? I think that is
something worth documenting somewhere.

Re: [Qemu-devel] [PATCH v3] file-posix: specify expected filetypes

[John Snow]

On 01/17/2018 05:18 PM, no-re...@patchew.org wrote:
> Hi,
> 
> This series failed build test on s390x host. Please find the details below.
> 

@)(#_%(@)#_

I forgot to check in some changes in my local branch that keep the texi
from breaking.

Sorry for the noise...

Re: [Qemu-devel] [PATCH v3] file-posix: specify expected filetypes

[no-reply]

Hi,

This series failed build test on s390x host. Please find the details below.

Type: series
Message-id: 20180117221210.28575-1-js...@redhat.com
Subject: [Qemu-devel] [PATCH v3] file-posix: specify expected filetypes

=== TEST SCRIPT BEGIN ===
#!/bin/bash
# Testing script will be invoked under the git checkout with
# HEAD pointing to a commit that has the patches applied on top of "base"
# branch
set -e
echo "=== ENV ==="
env
echo "=== PACKAGES ==="
rpm -qa
echo "=== TEST BEGIN ==="
CC=$HOME/bin/cc
INSTALL=$PWD/install
BUILD=$PWD/build
echo -n "Using CC: "
realpath $CC
mkdir -p $BUILD $INSTALL
SRC=$PWD
cd $BUILD
$SRC/configure --cc=$CC --prefix=$INSTALL
make -j4
# XXX: we need reliable clean up
# make check -j4 V=1
make install
=== TEST SCRIPT END ===

Updating 3c8cf5a9c21ff8782164d1def7f44bd888713384
From https://github.com/patchew-project/qemu
 t [tag update]
patchew/20180117193757.73471-1-borntrae...@de.ibm.com -> 
patchew/20180117193757.73471-1-borntrae...@de.ibm.com
 * [new tag]   patchew/20180117221210.28575-1-js...@redhat.com -> 
patchew/20180117221210.28575-1-js...@redhat.com
Switched to a new branch 'test'
28b166b3d7 file-posix: specify expected filetypes

=== OUTPUT BEGIN ===
=== ENV ===
LANG=en_US.UTF-8
XDG_SESSION_ID=14259
USER=fam
PWD=/var/tmp/patchew-tester-tmp-m9251zth/src
HOME=/home/fam
SHELL=/bin/sh
SHLVL=2
PATCHEW=/home/fam/patchew/patchew-cli -s http://patchew.org --nodebug
LOGNAME=fam
DBUS_SESSION_BUS_ADDRESS=unix:path=/run/user/1012/bus
XDG_RUNTIME_DIR=/run/user/1012
PATH=/usr/bin:/bin
_=/usr/bin/env
=== PACKAGES ===
gpg-pubkey-873529b8-54e386ff
glibc-debuginfo-common-2.24-10.fc25.s390x
fedora-release-26-1.noarch
dejavu-sans-mono-fonts-2.35-4.fc26.noarch
xemacs-filesystem-21.5.34-22.20170124hgf412e9f093d4.fc26.noarch
bash-4.4.12-7.fc26.s390x
freetype-2.7.1-9.fc26.s390x
libSM-1.2.2-5.fc26.s390x
libmpc-1.0.2-6.fc26.s390x
libaio-0.3.110-7.fc26.s390x
libverto-0.2.6-7.fc26.s390x
perl-Scalar-List-Utils-1.48-1.fc26.s390x
iptables-libs-1.6.1-2.fc26.s390x
perl-threads-shared-1.57-1.fc26.s390x
p11-kit-trust-0.23.9-2.fc26.s390x
tcl-8.6.6-2.fc26.s390x
libxshmfence-1.2-4.fc26.s390x
expect-5.45-23.fc26.s390x
perl-Thread-Queue-3.12-1.fc26.noarch
perl-encoding-2.19-6.fc26.s390x
keyutils-1.5.10-1.fc26.s390x
gmp-devel-6.1.2-4.fc26.s390x
enchant-1.6.0-16.fc26.s390x
net-snmp-libs-5.7.3-17.fc26.s390x
python-gobject-base-3.24.1-1.fc26.s390x
python3-distro-1.0.3-1.fc26.noarch
python3-enchant-1.6.10-1.fc26.noarch
python-lockfile-0.11.0-6.fc26.noarch
python2-pyparsing-2.1.10-3.fc26.noarch
python2-lxml-4.1.1-1.fc26.s390x
librados2-10.2.7-2.fc26.s390x
trousers-lib-0.3.13-7.fc26.s390x
libpaper-1.1.24-14.fc26.s390x
libdatrie-0.2.9-4.fc26.s390x
libsoup-2.58.2-1.fc26.s390x
passwd-0.79-9.fc26.s390x
bind99-libs-9.9.10-3.P3.fc26.s390x
python3-rpm-4.13.0.2-1.fc26.s390x
mock-core-configs-27.4-1.fc26.noarch
systemd-233-7.fc26.s390x
virglrenderer-0.6.0-1.20170210git76b3da97b.fc26.s390x
s390utils-ziomon-1.36.1-3.fc26.s390x
s390utils-osasnmpd-1.36.1-3.fc26.s390x
libXrandr-1.5.1-2.fc26.s390x
libglvnd-glx-1.0.0-1.fc26.s390x
texlive-ifxetex-svn19685.0.5-33.fc26.2.noarch
texlive-psnfss-svn33946.9.2a-33.fc26.2.noarch
texlive-dvipdfmx-def-svn40328-33.fc26.2.noarch
texlive-natbib-svn20668.8.31b-33.fc26.2.noarch
texlive-xdvi-bin-svn40750-33.20160520.fc26.2.s390x
texlive-cm-svn32865.0-33.fc26.2.noarch
texlive-beton-svn15878.0-33.fc26.2.noarch
texlive-fpl-svn15878.1.002-33.fc26.2.noarch
texlive-mflogo-svn38628-33.fc26.2.noarch
texlive-texlive-docindex-svn41430-33.fc26.2.noarch
texlive-luaotfload-bin-svn34647.0-33.20160520.fc26.2.noarch
texlive-koma-script-svn41508-33.fc26.2.noarch
texlive-pst-tree-svn24142.1.12-33.fc26.2.noarch
texlive-breqn-svn38099.0.98d-33.fc26.2.noarch
texlive-xetex-svn41438-33.fc26.2.noarch
gstreamer1-plugins-bad-free-1.12.3-1.fc26.s390x
xorg-x11-font-utils-7.5-33.fc26.s390x
ghostscript-fonts-5.50-36.fc26.noarch
libXext-devel-1.3.3-5.fc26.s390x
libusbx-devel-1.0.21-2.fc26.s390x
libglvnd-devel-1.0.0-1.fc26.s390x
emacs-25.3-3.fc26.s390x
alsa-lib-devel-1.1.4.1-1.fc26.s390x
kbd-2.0.4-2.fc26.s390x
dconf-0.26.0-2.fc26.s390x
ccache-3.3.4-1.fc26.s390x
glibc-static-2.25-12.fc26.s390x
mc-4.8.19-5.fc26.s390x
doxygen-1.8.13-9.fc26.s390x
dpkg-1.18.24-1.fc26.s390x
libtdb-1.3.13-1.fc26.s390x
python2-pynacl-1.1.1-1.fc26.s390x
nss-sysinit-3.34.0-1.0.fc26.s390x
kernel-4.13.16-202.fc26.s390x
perl-Filter-1.58-1.fc26.s390x
python2-pip-9.0.1-11.fc26.noarch
dnf-2.7.5-2.fc26.noarch
pcre2-utf16-10.23-11.fc26.s390x
glusterfs-devel-3.10.8-1.fc26.s390x
sssd-common-1.16.0-4.fc26.s390x
python2-sssdconfig-1.16.0-4.fc26.noarch
acpica-tools-20171110-1.fc26.s390x
glibc-debuginfo-2.24-10.fc25.s390x
fedora-repos-26-1.noarch
dejavu-fonts-common-2.35-4.fc26.noarch
bind99-license-9.9.10-3.P3.fc26.noarch
ncurses-libs-6.0-8.20170212.fc26.s390x
libpng-1.6.28-2.fc26.s390x
libICE-1.0.9-9.fc26.s390x
kmod-24-1.fc26.s390x
libseccomp-2.3.2-1.fc26.s390x
perl-Text-ParseWords-3.30-366.fc26.noarch
libtool-ltdl-2.4.6-17.fc26.s390x

[Qemu-devel] [PATCH v3] file-posix: specify expected filetypes

[John Snow]

Adjust each caller of raw_open_common to specify if they are expecting
host and character devices or not. Tighten expectations of file types upon
open in the common code and refuse types that are not expected.

This has two effects:

(1) Character and block devices are now considered deprecated for the
'file' driver, which expects only S_IFREG, and
(2) no file-posix driver (file, host_cdrom, or host_device) can open
directories now.

I don't think there's a legitimate reason to open directories as if
they were files. This prevents QEMU from opening and attempting to probe
a directory inode, which can break in exciting ways. One of those ways
is lseek on ext4/xfs, which will return 0x7fff as the file
size instead of EISDIR. This can coax QEMU into responding with a
confusing "file too big" instead of "Hey, that's not a file".

See: https://bugs.launchpad.net/qemu/+bug/1739304/
Signed-off-by: John Snow 
---

v3: Fixed bad semantics on multi-line break (Kevin)
Added deprecation warning (Eric, Kevin)
Removed superfluous whitespace change (Eric)

 block/file-posix.c | 37 +
 qemu-doc.texi  |  6 ++
 2 files changed, 35 insertions(+), 8 deletions(-)

diff --git a/block/file-posix.c b/block/file-posix.c
index 36ee89e940..61fac1d2a4 100644
--- a/block/file-posix.c
+++ b/block/file-posix.c
@@ -417,7 +417,8 @@ static QemuOptsList raw_runtime_opts = {
 };
 
 static int raw_open_common(BlockDriverState *bs, QDict *options,
-   int bdrv_flags, int open_flags, Error **errp)
+   int bdrv_flags, int open_flags,
+   bool device, Error **errp)
 {
 BDRVRawState *s = bs->opaque;
 QemuOpts *opts;
@@ -556,10 +557,30 @@ static int raw_open_common(BlockDriverState *bs, QDict 
*options,
 error_setg_errno(errp, errno, "Could not stat file");
 goto fail;
 }
-if (S_ISREG(st.st_mode)) {
-s->discard_zeroes = true;
-s->has_fallocate = true;
+
+if (!device) {
+if (S_ISBLK(st.st_mode)) {
+warn_report("Opening a block device as file using 'file' "
+"driver is deprecated");
+} else if (S_ISCHR(st.st_mode)) {
+warn_report("Opening a character device as file using the 'file' "
+"driver is deprecated");
+} else if (!S_ISREG(st.st_mode)) {
+error_setg(errp, "A regular file was expected by the 'file' 
driver, "
+   "but something else was given");
+goto fail;
+} else {
+s->discard_zeroes = true;
+s->has_fallocate = true;
+}
+} else {
+if (!(S_ISCHR(st.st_mode) || S_ISBLK(st.st_mode))) {
+error_setg(errp, "host_device/host_cdrom driver expects either "
+   "a character or block device");
+goto fail;
+}
 }
+
 if (S_ISBLK(st.st_mode)) {
 #ifdef BLKDISCARDZEROES
 unsigned int arg;
@@ -611,7 +632,7 @@ static int raw_open(BlockDriverState *bs, QDict *options, 
int flags,
 BDRVRawState *s = bs->opaque;
 
 s->type = FTYPE_FILE;
-return raw_open_common(bs, options, flags, 0, errp);
+return raw_open_common(bs, options, flags, 0, false, errp);
 }
 
 typedef enum {
@@ -2575,7 +2596,7 @@ hdev_open_Mac_error:
 
 s->type = FTYPE_FILE;
 
-ret = raw_open_common(bs, options, flags, 0, _err);
+ret = raw_open_common(bs, options, flags, 0, true, _err);
 if (ret < 0) {
 error_propagate(errp, local_err);
 #if defined(__APPLE__) && defined(__MACH__)
@@ -2802,7 +2823,7 @@ static int cdrom_open(BlockDriverState *bs, QDict 
*options, int flags,
 s->type = FTYPE_CD;
 
 /* open will not fail even if no CD is inserted, so add O_NONBLOCK */
-return raw_open_common(bs, options, flags, O_NONBLOCK, errp);
+return raw_open_common(bs, options, flags, O_NONBLOCK, true, errp);
 }
 
 static int cdrom_probe_device(const char *filename)
@@ -2915,7 +2936,7 @@ static int cdrom_open(BlockDriverState *bs, QDict 
*options, int flags,
 
 s->type = FTYPE_CD;
 
-ret = raw_open_common(bs, options, flags, 0, _err);
+ret = raw_open_common(bs, options, flags, 0, true, _err);
 if (ret) {
 error_propagate(errp, local_err);
 return ret;
diff --git a/qemu-doc.texi b/qemu-doc.texi
index 3e9eb819a6..aaed699142 100644
--- a/qemu-doc.texi
+++ b/qemu-doc.texi
@@ -2708,6 +2708,12 @@ that can be specified with the ``-device'' parameter.
 The drive addr argument is replaced by the the addr argument
 that can be specified with the ``-device'' parameter.
 
+@subsection -drive file=json:{...{'driver':'file'}} (since 2.12.0)
+
+The 'file' driver for drives is no longer appropriate for character or host
+devices and will only accept regular files (S_IFREG). The correct driver
+for these file types is 'host_cdrom' or 'host_device' as appropriate.
+
 @subsection 

Re: [Qemu-devel] [PATCH v2 3/3] s390x/kvm: provide stfle.81

[David Hildenbrand]

On 17.01.2018 22:37, Christian Borntraeger wrote:
> 
> 
> On 01/17/2018 10:13 PM, David Hildenbrand wrote:
>> On 17.01.2018 20:37, Christian Borntraeger wrote:
>>> stfle.81 (ppa15) is a transparent facility that can be passed to the
>>> guest without the need to implement hypervisor support. As this feature
>>> can be provided by firmware we add it to all full models.
>>>
>>> Signed-off-by: Christian Borntraeger 
>>> ---
>>>  target/s390x/cpu_features.c | 1 +
>>>  target/s390x/cpu_features_def.h | 1 +
>>>  target/s390x/gen-features.c | 1 +
>>>  3 files changed, 3 insertions(+)
>>>
>>> diff --git a/target/s390x/cpu_features.c b/target/s390x/cpu_features.c
>>> index 5d1c210..1550ab0 100644
>>> --- a/target/s390x/cpu_features.c
>>> +++ b/target/s390x/cpu_features.c
>>> @@ -89,6 +89,7 @@ static const S390FeatDef s390_features[] = {
>>>  FEAT_INIT("msa4-base", S390_FEAT_TYPE_STFL, 77, 
>>> "Message-security-assist-extension-4 facility (excluding subfunctions)"),
>>>  FEAT_INIT("edat2", S390_FEAT_TYPE_STFL, 78, "Enhanced-DAT facility 2"),
>>>  FEAT_INIT("dfppc", S390_FEAT_TYPE_STFL, 80, "Decimal-floating-point 
>>> packed-conversion facility"),
>>> +FEAT_INIT("ppa15", S390_FEAT_TYPE_STFL, 81, "PPA15 is installed"),
>>>  FEAT_INIT("bpb", S390_FEAT_TYPE_STFL, 82, "Branch Prediction 
>>> Blocking"),
>>>  FEAT_INIT("vx", S390_FEAT_TYPE_STFL, 129, "Vector facility"),
>>>  FEAT_INIT("iep", S390_FEAT_TYPE_STFL, 130, 
>>> "Instruction-execution-protection facility"),
>>> diff --git a/target/s390x/cpu_features_def.h 
>>> b/target/s390x/cpu_features_def.h
>>> index 4487cfd..4d93087 100644
>>> --- a/target/s390x/cpu_features_def.h
>>> +++ b/target/s390x/cpu_features_def.h
>>> @@ -80,6 +80,7 @@ typedef enum {
>>>  S390_FEAT_MSA_EXT_4,
>>>  S390_FEAT_EDAT_2,
>>>  S390_FEAT_DFP_PACKED_CONVERSION,
>>> +S390_FEAT_PPA15,
>>>  S390_FEAT_BPB,
>>>  S390_FEAT_VECTOR,
>>>  S390_FEAT_INSTRUCTION_EXEC_PROT,
>>> diff --git a/target/s390x/gen-features.c b/target/s390x/gen-features.c
>>> index 95ee870..50bd3f4 100644
>>> --- a/target/s390x/gen-features.c
>>> +++ b/target/s390x/gen-features.c
>>> @@ -357,6 +357,7 @@ static uint16_t full_GEN7_GA1[] = {
>>>  S390_FEAT_SIE_GPERE,
>>>  S390_FEAT_SIE_IB,
>>>  S390_FEAT_SIE_CEI,
>>> +S390_FEAT_PPA15,
>>>  S390_FEAT_BPB,
>>
> 
>> Is the order in this list still correct?
> 
> Is the order in this array important as well? It seems to work fine. At least 
> PPA15 is correctly
> ordered vs BPB.
> 

Purely style. (when introducing, I tried to keep features in the same
order as defined in target/s390x/cpu_features_def.h )

So feel free to keep the order (or I'll clean this up again one day).

Reviewed-by: David Hildenbrand 

-- 

Thanks,

David / dhildenb

Re: [Qemu-devel] [PATCH v2 3/3] s390x/kvm: provide stfle.81

[Christian Borntraeger]

On 01/17/2018 10:13 PM, David Hildenbrand wrote:
> On 17.01.2018 20:37, Christian Borntraeger wrote:
>> stfle.81 (ppa15) is a transparent facility that can be passed to the
>> guest without the need to implement hypervisor support. As this feature
>> can be provided by firmware we add it to all full models.
>>
>> Signed-off-by: Christian Borntraeger 
>> ---
>>  target/s390x/cpu_features.c | 1 +
>>  target/s390x/cpu_features_def.h | 1 +
>>  target/s390x/gen-features.c | 1 +
>>  3 files changed, 3 insertions(+)
>>
>> diff --git a/target/s390x/cpu_features.c b/target/s390x/cpu_features.c
>> index 5d1c210..1550ab0 100644
>> --- a/target/s390x/cpu_features.c
>> +++ b/target/s390x/cpu_features.c
>> @@ -89,6 +89,7 @@ static const S390FeatDef s390_features[] = {
>>  FEAT_INIT("msa4-base", S390_FEAT_TYPE_STFL, 77, 
>> "Message-security-assist-extension-4 facility (excluding subfunctions)"),
>>  FEAT_INIT("edat2", S390_FEAT_TYPE_STFL, 78, "Enhanced-DAT facility 2"),
>>  FEAT_INIT("dfppc", S390_FEAT_TYPE_STFL, 80, "Decimal-floating-point 
>> packed-conversion facility"),
>> +FEAT_INIT("ppa15", S390_FEAT_TYPE_STFL, 81, "PPA15 is installed"),
>>  FEAT_INIT("bpb", S390_FEAT_TYPE_STFL, 82, "Branch Prediction Blocking"),
>>  FEAT_INIT("vx", S390_FEAT_TYPE_STFL, 129, "Vector facility"),
>>  FEAT_INIT("iep", S390_FEAT_TYPE_STFL, 130, 
>> "Instruction-execution-protection facility"),
>> diff --git a/target/s390x/cpu_features_def.h 
>> b/target/s390x/cpu_features_def.h
>> index 4487cfd..4d93087 100644
>> --- a/target/s390x/cpu_features_def.h
>> +++ b/target/s390x/cpu_features_def.h
>> @@ -80,6 +80,7 @@ typedef enum {
>>  S390_FEAT_MSA_EXT_4,
>>  S390_FEAT_EDAT_2,
>>  S390_FEAT_DFP_PACKED_CONVERSION,
>> +S390_FEAT_PPA15,
>>  S390_FEAT_BPB,
>>  S390_FEAT_VECTOR,
>>  S390_FEAT_INSTRUCTION_EXEC_PROT,
>> diff --git a/target/s390x/gen-features.c b/target/s390x/gen-features.c
>> index 95ee870..50bd3f4 100644
>> --- a/target/s390x/gen-features.c
>> +++ b/target/s390x/gen-features.c
>> @@ -357,6 +357,7 @@ static uint16_t full_GEN7_GA1[] = {
>>  S390_FEAT_SIE_GPERE,
>>  S390_FEAT_SIE_IB,
>>  S390_FEAT_SIE_CEI,
>> +S390_FEAT_PPA15,
>>  S390_FEAT_BPB,
> 

> Is the order in this list still correct?

Is the order in this array important as well? It seems to work fine. At least 
PPA15 is correctly
ordered vs BPB.

[Qemu-devel] [PATCH v2] xilinx_spips: Correct usage of an uninitialized local variable

[Francisco Iglesias]

Coverity found that the variable tx_rx in the function
xilinx_spips_flush_txfifo was being used uninitialized (CID 1383841). This
patch corrects this by always initializing tx_rx to zeros.

Signed-off-by: Francisco Iglesias 

---
v2. Add a sanity check on the num_busses property when realizing the
devices.
---
 hw/ssi/xilinx_spips.c | 13 -
 1 file changed, 12 insertions(+), 1 deletion(-)

diff --git a/hw/ssi/xilinx_spips.c b/hw/ssi/xilinx_spips.c
index 85c5d0c..12f1de9 100644
--- a/hw/ssi/xilinx_spips.c
+++ b/hw/ssi/xilinx_spips.c
@@ -210,6 +210,9 @@
 #define SNOOP_NONE 0xEE
 #define SNOOP_STRIPING 0
 
+#define MIN_NUM_BUSSES 1
+#define MAX_NUM_BUSSES 2
+
 static inline int num_effective_busses(XilinxSPIPS *s)
 {
 return (s->regs[R_LQSPI_CFG] & LQSPI_CFG_SEP_BUS &&
@@ -573,7 +576,7 @@ static void xilinx_spips_flush_txfifo(XilinxSPIPS *s)
 for (;;) {
 int i;
 uint8_t tx = 0;
-uint8_t tx_rx[num_effective_busses(s)];
+uint8_t tx_rx[MAX_NUM_BUSSES] = { 0 };
 uint8_t dummy_cycles = 0;
 uint8_t addr_length;
 
@@ -1221,6 +1224,14 @@ static void xilinx_spips_realize(DeviceState *dev, Error 
**errp)
 
 DB_PRINT_L(0, "realized spips\n");
 
+if (s->num_busses < MIN_NUM_BUSSES || s->num_busses > MAX_NUM_BUSSES) {
+qemu_log_mask(LOG_GUEST_ERROR,
+  "%s: Invalid number of spi busses requested, "
+  "will default to use one bus\n",
+  __func__);
+s->num_busses = 1;
+}
+
 s->spi = g_new(SSIBus *, s->num_busses);
 for (i = 0; i < s->num_busses; ++i) {
 char bus_name[16];
-- 
2.9.3

Re: [Qemu-devel] [PATCH v2 02/19] spapr: introduce a skeleton for the XIVE interrupt controller

[Benjamin Herrenschmidt]

On Wed, 2018-01-17 at 15:39 +0100, Cédric Le Goater wrote:
> Migration is a problem. We will need both backend QEMU objects to be 
> available anyhow if we want to migrate. So we are back to the current 
> solution creating both QEMU objects but we can try to defer some of the 
> KVM inits and create the KVM device on demand at CAS time.

Do we have a way to migrate a piece of info from the machine *first*
that indicate what type of XICS/XIVE to instanciate ?

> The next problem is the ICP object that currently needs the KVM device 
> fd to connect the vcpus ... So, we will need to change that also. 
> That is probably the biggest problem today. We need a way to disconnect 
> the vpcu from the KVM device and see how we can defer the connection.
> I need to make sure this is possible, I can check that without XIVE

Ben.

Re: [Qemu-devel] [PATCH v2 3/3] s390x/kvm: provide stfle.81

[David Hildenbrand]

On 17.01.2018 20:37, Christian Borntraeger wrote:
> stfle.81 (ppa15) is a transparent facility that can be passed to the
> guest without the need to implement hypervisor support. As this feature
> can be provided by firmware we add it to all full models.
> 
> Signed-off-by: Christian Borntraeger 
> ---
>  target/s390x/cpu_features.c | 1 +
>  target/s390x/cpu_features_def.h | 1 +
>  target/s390x/gen-features.c | 1 +
>  3 files changed, 3 insertions(+)
> 
> diff --git a/target/s390x/cpu_features.c b/target/s390x/cpu_features.c
> index 5d1c210..1550ab0 100644
> --- a/target/s390x/cpu_features.c
> +++ b/target/s390x/cpu_features.c
> @@ -89,6 +89,7 @@ static const S390FeatDef s390_features[] = {
>  FEAT_INIT("msa4-base", S390_FEAT_TYPE_STFL, 77, 
> "Message-security-assist-extension-4 facility (excluding subfunctions)"),
>  FEAT_INIT("edat2", S390_FEAT_TYPE_STFL, 78, "Enhanced-DAT facility 2"),
>  FEAT_INIT("dfppc", S390_FEAT_TYPE_STFL, 80, "Decimal-floating-point 
> packed-conversion facility"),
> +FEAT_INIT("ppa15", S390_FEAT_TYPE_STFL, 81, "PPA15 is installed"),
>  FEAT_INIT("bpb", S390_FEAT_TYPE_STFL, 82, "Branch Prediction Blocking"),
>  FEAT_INIT("vx", S390_FEAT_TYPE_STFL, 129, "Vector facility"),
>  FEAT_INIT("iep", S390_FEAT_TYPE_STFL, 130, 
> "Instruction-execution-protection facility"),
> diff --git a/target/s390x/cpu_features_def.h b/target/s390x/cpu_features_def.h
> index 4487cfd..4d93087 100644
> --- a/target/s390x/cpu_features_def.h
> +++ b/target/s390x/cpu_features_def.h
> @@ -80,6 +80,7 @@ typedef enum {
>  S390_FEAT_MSA_EXT_4,
>  S390_FEAT_EDAT_2,
>  S390_FEAT_DFP_PACKED_CONVERSION,
> +S390_FEAT_PPA15,
>  S390_FEAT_BPB,
>  S390_FEAT_VECTOR,
>  S390_FEAT_INSTRUCTION_EXEC_PROT,
> diff --git a/target/s390x/gen-features.c b/target/s390x/gen-features.c
> index 95ee870..50bd3f4 100644
> --- a/target/s390x/gen-features.c
> +++ b/target/s390x/gen-features.c
> @@ -357,6 +357,7 @@ static uint16_t full_GEN7_GA1[] = {
>  S390_FEAT_SIE_GPERE,
>  S390_FEAT_SIE_IB,
>  S390_FEAT_SIE_CEI,
> +S390_FEAT_PPA15,
>  S390_FEAT_BPB,

Is the order in this list still correct?

Apart from that, looks nice.

>  };
>  
> 


-- 

Thanks,

David / dhildenb

Re: [Qemu-devel] [PATCH v2 2/3] s390x/kvm: Handle bpb feature

[David Hildenbrand]

On 17.01.2018 20:37, Christian Borntraeger wrote:
> We need to handle the bpb control on reset and migration. Normally
> stfle.82 is transparent (and the normal guest part works without
> hypervisor activity). To prevent any issues we require full
> host kernel support for this feature.
> 
> Signed-off-by: Christian Borntraeger 
> ---
>  target/s390x/cpu.c  |  1 +
>  target/s390x/cpu.h  |  1 +
>  target/s390x/cpu_features.c |  1 +
>  target/s390x/cpu_features_def.h |  1 +
>  target/s390x/gen-features.c |  1 +
>  target/s390x/kvm.c  | 14 ++
>  target/s390x/machine.c  | 17 +
>  7 files changed, 36 insertions(+)
> 
> diff --git a/target/s390x/cpu.c b/target/s390x/cpu.c
> index ae3cee9..1577b2c 100644
> --- a/target/s390x/cpu.c
> +++ b/target/s390x/cpu.c
> @@ -89,6 +89,7 @@ static void s390_cpu_reset(CPUState *s)
>  CPUS390XState *env = >env;
>  
>  env->pfault_token = -1UL;
> +env->bpbc = 0;

As this is effectively only 1 bit, I wonder if we should also make that
clear in QEMU

bool bpbc, VMSTATE_BOOL ...

Apart from that, looks sane.

-- 

Thanks,

David / dhildenb

Re: [Qemu-devel] [PATCH v2 1/3] header sync

[David Hildenbrand]

On 17.01.2018 20:37, Christian Borntraeger wrote:
> replace with proper header sync
> 
> Signed-off-by: Christian Borntraeger 
> ---
>  linux-headers/asm-s390/kvm.h | 9 -
>  linux-headers/linux/kvm.h| 5 +++--
>  2 files changed, 7 insertions(+), 7 deletions(-)
> 
> diff --git a/linux-headers/asm-s390/kvm.h b/linux-headers/asm-s390/kvm.h
> index 32d372e..11def14 100644
> --- a/linux-headers/asm-s390/kvm.h
> +++ b/linux-headers/asm-s390/kvm.h
> @@ -6,10 +6,6 @@
>   *
>   * Copyright IBM Corp. 2008
>   *
> - * This program is free software; you can redistribute it and/or modify
> - * it under the terms of the GNU General Public License (version 2 only)
> - * as published by the Free Software Foundation.
> - *
>   *Author(s): Carsten Otte 
>   *   Christian Borntraeger 
>   */
> @@ -228,6 +224,7 @@ struct kvm_guest_debug_arch {
>  #define KVM_SYNC_RICCB  (1UL << 7)
>  #define KVM_SYNC_FPRS   (1UL << 8)
>  #define KVM_SYNC_GSCB   (1UL << 9)
> +#define KVM_SYNC_BPBC   (1UL << 10)
>  /* length and alignment of the sdnx as a power of two */
>  #define SDNXC 8
>  #define SDNXL (1UL << SDNXC)
> @@ -251,7 +248,9 @@ struct kvm_sync_regs {
>   };
>   __u8  reserved[512];/* for future vector expansion */
>   __u32 fpc;  /* valid on KVM_SYNC_VRS or KVM_SYNC_FPRS */
> - __u8 padding1[52];  /* riccb needs to be 64byte aligned */
> + __u8 bpbc : 1;  /* bp mode */
> + __u8 reserved2 : 7;
> + __u8 padding1[51];  /* riccb needs to be 64byte aligned */
>   __u8 riccb[64]; /* runtime instrumentation controls block */
>   __u8 padding2[192]; /* sdnx needs to be 256byte aligned */
>   union {
> diff --git a/linux-headers/linux/kvm.h b/linux-headers/linux/kvm.h
> index ce6c2f1..b4503d8 100644
> --- a/linux-headers/linux/kvm.h
> +++ b/linux-headers/linux/kvm.h
> @@ -630,9 +630,9 @@ struct kvm_s390_irq {
>  
>  struct kvm_s390_irq_state {
>   __u64 buf;
> - __u32 flags;
> + __u32 flags;/* will stay unused for compatibility reasons */
>   __u32 len;
> - __u32 reserved[4];
> + __u32 reserved[4];  /* will stay unused for compatibility reasons */
>  };
>  
>  /* for KVM_SET_GUEST_DEBUG */
> @@ -932,6 +932,7 @@ struct kvm_ppc_resize_hpt {
>  #define KVM_CAP_HYPERV_SYNIC2 148
>  #define KVM_CAP_HYPERV_VP_INDEX 149
>  #define KVM_CAP_S390_AIS_MIGRATION 150
> +#define KVM_CAP_S390_BPB 151
>  
>  #ifdef KVM_CAP_IRQ_ROUTING
>  
> 

Acked-by: David Hildenbrand 

-- 

Thanks,

David / dhildenb

Re: [Qemu-devel] [PATCH v1 1/1] linux-user: Fix webkitgtk hangs on 32-bit x86 target

[Philippe Mathieu-Daudé]

On 01/17/2018 05:39 PM, Alistair Francis wrote:
> Since commit "linux-user: Tidy and enforce reserved_va initialization"
> (18e80c55bb6ec17c05ec0ba717ec83933c2bfc07) the Yocto webkitgtk build
> hangs when cross compiling for 32-bit x86 on a 64-bit x86 machine using
> musl.
> 
> To fix the issue reduce the MAX_RESERVED_VA macro to be a closer match
> to what it was before the problematic commit.
> 
> Signed-off-by: Alistair Francis 
> ---
> 
>  linux-user/main.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/linux-user/main.c b/linux-user/main.c
> index 450eb3ce65..c7cc0a184e 100644
> --- a/linux-user/main.c
> +++ b/linux-user/main.c
> @@ -77,7 +77,7 @@ do {
> \
>(TARGET_LONG_BITS == 32 || defined(TARGET_ABI32))
>  /* There are a number of places where we assign reserved_va to a variable
> of type abi_ulong and expect it to fit.  Avoid the last page.  */

If this is only for MUSL shouldn't we think of smth like: ?

#if defined(__GLIBC__) || defined(__UCLIBC__)

> -#   define MAX_RESERVED_VA  (0xul & TARGET_PAGE_MASK)

#else /* __MUSL__ */

> +#   define MAX_RESERVED_VA  (0x7ffful & TARGET_PAGE_MASK)

#endif

>  #  else
>  #   define MAX_RESERVED_VA  (1ul << TARGET_VIRT_ADDR_SPACE_BITS)
>  #  endif
> 

Re: [Qemu-devel] [PATCH v3 1/3] xlnx-zynqmp-rtc: Initial commit

[Alistair Francis]

On Wed, Jan 17, 2018 at 12:39 PM, Philippe Mathieu-Daudé
 wrote:
> On 01/17/2018 02:27 PM, Alistair Francis wrote:
>> Initial commit of the ZynqMP RTC device.
>>
>> Signed-off-by: Alistair Francis 
>> ---
>> V2:
>>  - Delete unused realise function
>>  - Remove DB_PRINT()
>>
>>  hw/timer/Makefile.objs |   1 +
>>  hw/timer/xlnx-zynqmp-rtc.c | 218 
>> +
>>  include/hw/timer/xlnx-zynqmp-rtc.h |  84 ++
>
> Please 'git config diff.orderFile scripts/git.orderfile' :)
>
>>  3 files changed, 303 insertions(+)
>>  create mode 100644 hw/timer/xlnx-zynqmp-rtc.c
>>  create mode 100644 include/hw/timer/xlnx-zynqmp-rtc.h
>>
>> diff --git a/hw/timer/Makefile.objs b/hw/timer/Makefile.objs
>> index 8c19eac3b6..8b27a4b7ef 100644
>> --- a/hw/timer/Makefile.objs
>> +++ b/hw/timer/Makefile.objs
>> @@ -21,6 +21,7 @@ common-obj-$(CONFIG_IMX) += imx_epit.o
>>  common-obj-$(CONFIG_IMX) += imx_gpt.o
>>  common-obj-$(CONFIG_LM32) += lm32_timer.o
>>  common-obj-$(CONFIG_MILKYMIST) += milkymist-sysctl.o
>> +common-obj-$(CONFIG_XLNX_ZYNQMP) += xlnx-zynqmp-rtc.o
>>
>>  obj-$(CONFIG_ALTERA_TIMER) += altera_timer.o
>>  obj-$(CONFIG_EXYNOS4) += exynos4210_mct.o
>> diff --git a/hw/timer/xlnx-zynqmp-rtc.c b/hw/timer/xlnx-zynqmp-rtc.c
>> new file mode 100644
>> index 00..ead40fc42d
>> --- /dev/null
>> +++ b/hw/timer/xlnx-zynqmp-rtc.c
>> @@ -0,0 +1,218 @@
>> +/*
>> + * QEMU model of the Xilinx ZynqMP Real Time Clock (RTC).
>> + *
>> + * Copyright (c) 2017 Xilinx Inc.
>> + *
>> + * Written-by: Alistair Francis 
>> + *
>> + * Permission is hereby granted, free of charge, to any person obtaining a 
>> copy
>> + * of this software and associated documentation files (the "Software"), to 
>> deal
>> + * in the Software without restriction, including without limitation the 
>> rights
>> + * to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
>> + * copies of the Software, and to permit persons to whom the Software is
>> + * furnished to do so, subject to the following conditions:
>> + *
>> + * The above copyright notice and this permission notice shall be included 
>> in
>> + * all copies or substantial portions of the Software.
>> + *
>> + * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS 
>> OR
>> + * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
>> + * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL
>> + * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR 
>> OTHER
>> + * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING 
>> FROM,
>> + * OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN
>> + * THE SOFTWARE.
>
> *
> * SPDX-License-Identifier: MIT

What does this mean? Why is it MIT?

Alistair

>
>> + */
>> +
>> +#include "qemu/osdep.h"
>> +#include "hw/sysbus.h"
>> +#include "hw/register.h"
>> +#include "qemu/bitops.h"
>> +#include "qemu/log.h"
>> +#include "hw/timer/xlnx-zynqmp-rtc.h"
>> +
>> +#ifndef XLNX_ZYNQMP_RTC_ERR_DEBUG
>> +#define XLNX_ZYNQMP_RTC_ERR_DEBUG 0
>> +#endif
>> +
>> +static void rtc_int_update_irq(XlnxZynqMPRTC *s)
>> +{
>> +bool pending = s->regs[R_RTC_INT_STATUS] & ~s->regs[R_RTC_INT_MASK];
>> +qemu_set_irq(s->irq_rtc_int, pending);
>> +}
>> +
>> +static void addr_error_int_update_irq(XlnxZynqMPRTC *s)
>> +{
>> +bool pending = s->regs[R_ADDR_ERROR] & ~s->regs[R_ADDR_ERROR_INT_MASK];
>> +qemu_set_irq(s->irq_addr_error_int, pending);
>> +}
>> +
>> +static void rtc_int_status_postw(RegisterInfo *reg, uint64_t val64)
>> +{
>> +XlnxZynqMPRTC *s = XLNX_ZYNQMP_RTC(reg->opaque);
>> +rtc_int_update_irq(s);
>> +}
>> +
>> +static uint64_t rtc_int_en_prew(RegisterInfo *reg, uint64_t val64)
>> +{
>> +XlnxZynqMPRTC *s = XLNX_ZYNQMP_RTC(reg->opaque);
>> +uint32_t val = val64;
>> +
>> +s->regs[R_RTC_INT_MASK] &= ~val;
>> +rtc_int_update_irq(s);
>> +return 0;
>> +}
>> +
>> +static uint64_t rtc_int_dis_prew(RegisterInfo *reg, uint64_t val64)
>> +{
>> +XlnxZynqMPRTC *s = XLNX_ZYNQMP_RTC(reg->opaque);
>> +uint32_t val = val64;
>> +
>> +s->regs[R_RTC_INT_MASK] |= val;
>> +rtc_int_update_irq(s);
>> +return 0;
>> +}
>> +
>> +static void addr_error_postw(RegisterInfo *reg, uint64_t val64)
>> +{
>> +XlnxZynqMPRTC *s = XLNX_ZYNQMP_RTC(reg->opaque);
>> +addr_error_int_update_irq(s);
>> +}
>> +
>> +static uint64_t addr_error_int_en_prew(RegisterInfo *reg, uint64_t val64)
>> +{
>> +XlnxZynqMPRTC *s = XLNX_ZYNQMP_RTC(reg->opaque);
>> +uint32_t val = val64;
>> +
>> +s->regs[R_ADDR_ERROR_INT_MASK] &= ~val;
>> +addr_error_int_update_irq(s);
>> +return 0;
>> +}
>> +
>> +static uint64_t addr_error_int_dis_prew(RegisterInfo *reg, uint64_t val64)
>> +{
>> +XlnxZynqMPRTC *s = XLNX_ZYNQMP_RTC(reg->opaque);
>> +uint32_t val = val64;
>> +
>> +

Re: [Qemu-devel] [PATCH v3 3/3] xlnx-zynqmp: Connect the RTC device

[Philippe Mathieu-Daudé]

On 01/17/2018 02:27 PM, Alistair Francis wrote:
> Signed-off-by: Alistair Francis 
> Reviewed-by: Peter Maydell 

Reviewed-by: Philippe Mathieu-Daudé 

> ---
> 
>  hw/arm/xlnx-zynqmp.c | 14 ++
>  include/hw/arm/xlnx-zynqmp.h |  2 ++
>  2 files changed, 16 insertions(+)
> 
> diff --git a/hw/arm/xlnx-zynqmp.c b/hw/arm/xlnx-zynqmp.c
> index 325642058b..deef583c2a 100644
> --- a/hw/arm/xlnx-zynqmp.c
> +++ b/hw/arm/xlnx-zynqmp.c
> @@ -50,6 +50,9 @@
>  #define DPDMA_ADDR  0xfd4c
>  #define DPDMA_IRQ   116
> 
> +#define RTC_ADDR0xffa6
> +#define RTC_IRQ 26
> +
>  static const uint64_t gem_addr[XLNX_ZYNQMP_NUM_GEMS] = {
>  0xFF0B, 0xFF0C, 0xFF0D, 0xFF0E,
>  };
> @@ -183,6 +186,9 @@ static void xlnx_zynqmp_init(Object *obj)
> 
>  object_initialize(>dpdma, sizeof(s->dpdma), TYPE_XLNX_DPDMA);
>  qdev_set_parent_bus(DEVICE(>dpdma), sysbus_get_default());
> +
> +object_initialize(>rtc, sizeof(s->rtc), TYPE_XLNX_ZYNQMP_RTC);
> +qdev_set_parent_bus(DEVICE(>rtc), sysbus_get_default());
>  }
> 
>  static void xlnx_zynqmp_realize(DeviceState *dev, Error **errp)
> @@ -454,6 +460,14 @@ static void xlnx_zynqmp_realize(DeviceState *dev, Error 
> **errp)
>   _abort);
>  sysbus_mmio_map(SYS_BUS_DEVICE(>dpdma), 0, DPDMA_ADDR);
>  sysbus_connect_irq(SYS_BUS_DEVICE(>dpdma), 0, gic_spi[DPDMA_IRQ]);
> +
> +object_property_set_bool(OBJECT(>rtc), true, "realized", );
> +if (err) {
> +error_propagate(errp, err);
> +return;
> +}
> +sysbus_mmio_map(SYS_BUS_DEVICE(>rtc), 0, RTC_ADDR);
> +sysbus_connect_irq(SYS_BUS_DEVICE(>rtc), 0, gic_spi[RTC_IRQ]);
>  }
> 
>  static Property xlnx_zynqmp_props[] = {
> diff --git a/include/hw/arm/xlnx-zynqmp.h b/include/hw/arm/xlnx-zynqmp.h
> index 3e6fb9b7bd..9e8c9e18dd 100644
> --- a/include/hw/arm/xlnx-zynqmp.h
> +++ b/include/hw/arm/xlnx-zynqmp.h
> @@ -28,6 +28,7 @@
>  #include "hw/ssi/xilinx_spips.h"
>  #include "hw/dma/xlnx_dpdma.h"
>  #include "hw/display/xlnx_dp.h"
> +#include "hw/timer/xlnx-zynqmp-rtc.h"
> 
>  #define TYPE_XLNX_ZYNQMP "xlnx,zynqmp"
>  #define XLNX_ZYNQMP(obj) OBJECT_CHECK(XlnxZynqMPState, (obj), \
> @@ -90,6 +91,7 @@ typedef struct XlnxZynqMPState {
>  XlnxZynqMPQSPIPS qspi;
>  XlnxDPState dp;
>  XlnxDPDMAState dpdma;
> +XlnxZynqMPRTC rtc;
> 
>  char *boot_cpu;
>  ARMCPU *boot_cpu_ptr;
> --
> 2.14.1
> 

Re: [Qemu-devel] [PATCH v3 2/3] xlnx-zynqmp-rtc: Add basic time support

[Philippe Mathieu-Daudé]

On 01/17/2018 02:27 PM, Alistair Francis wrote:
> Allow the guest to determine the time set from the QEMU command line.
> 
> This includes adding a trace event to debug the new time.
> 
> The migration logic was copied from the PL031 migration logic.
> 
> Signed-off-by: Alistair Francis 
> ---
> V3:
>  - Store an offset value
>  - Use mktimegm()
>  - Log unimplemented writes
> V2:
>  - Convert DB_PRINT() macro to trace
> 
>  hw/timer/trace-events  |  3 ++
>  hw/timer/xlnx-zynqmp-rtc.c | 64 
> ++
>  include/hw/timer/xlnx-zynqmp-rtc.h |  4 +++
>  3 files changed, 71 insertions(+)
> 
> diff --git a/hw/timer/trace-events b/hw/timer/trace-events
> index 640722b5d1..e6e042fddb 100644
> --- a/hw/timer/trace-events
> +++ b/hw/timer/trace-events
> @@ -60,3 +60,6 @@ systick_write(uint64_t addr, uint32_t value, unsigned size) 
> "systick write addr
>  cmsdk_apb_timer_read(uint64_t offset, uint64_t data, unsigned size) "CMSDK 
> APB timer read: offset 0x%" PRIx64 " data 0x%" PRIx64 " size %u"
>  cmsdk_apb_timer_write(uint64_t offset, uint64_t data, unsigned size) "CMSDK 
> APB timer write: offset 0x%" PRIx64 " data 0x%" PRIx64 " size %u"
>  cmsdk_apb_timer_reset(void) "CMSDK APB timer: reset"
> +
> +# hw/timer/xlnx-zynqmp-rtc.c
> +xlnx_zynqmp_rtc_gettime(int year, int month, int day, int hour, int min, int 
> sec) "Get time from host: %d-%d-%d %2d:%02d:%02d"
> diff --git a/hw/timer/xlnx-zynqmp-rtc.c b/hw/timer/xlnx-zynqmp-rtc.c
> index ead40fc42d..76c1af1afe 100644
> --- a/hw/timer/xlnx-zynqmp-rtc.c
> +++ b/hw/timer/xlnx-zynqmp-rtc.c
> @@ -29,6 +29,10 @@
>  #include "hw/register.h"
>  #include "qemu/bitops.h"
>  #include "qemu/log.h"
> +#include "hw/ptimer.h"
> +#include "qemu/cutils.h"
> +#include "sysemu/sysemu.h"
> +#include "trace.h"
>  #include "hw/timer/xlnx-zynqmp-rtc.h"
> 
>  #ifndef XLNX_ZYNQMP_RTC_ERR_DEBUG
> @@ -47,6 +51,19 @@ static void addr_error_int_update_irq(XlnxZynqMPRTC *s)
>  qemu_set_irq(s->irq_addr_error_int, pending);
>  }
> 
> +static uint32_t rtc_get_count(XlnxZynqMPRTC *s)
> +{
> +int64_t now = qemu_clock_get_ns(rtc_clock);
> +return s->tick_offset + now / NANOSECONDS_PER_SECOND;
> +}
> +
> +static uint64_t current_time_postr(RegisterInfo *reg, uint64_t val64)
> +{
> +XlnxZynqMPRTC *s = XLNX_ZYNQMP_RTC(reg->opaque);
> +
> +return rtc_get_count(s);
> +}
> +
>  static void rtc_int_status_postw(RegisterInfo *reg, uint64_t val64)
>  {
>  XlnxZynqMPRTC *s = XLNX_ZYNQMP_RTC(reg->opaque);
> @@ -99,15 +116,25 @@ static uint64_t addr_error_int_dis_prew(RegisterInfo 
> *reg, uint64_t val64)
>  return 0;
>  }
> 
> +static void unimp_postw(RegisterInfo *reg, uint64_t val64)
> +{
> +qemu_log_mask(LOG_UNIMP, "The time setting functionality is not "
> +  "implemented\n");
> +}
> +
>  static const RegisterAccessInfo rtc_regs_info[] = {
>  {   .name = "SET_TIME_WRITE",  .addr = A_SET_TIME_WRITE,
> +.post_write = unimp_postw,

Why bother adding this function? Rather use ".unimp = ~0" which log
register name accessed.

>  },{ .name = "SET_TIME_READ",  .addr = A_SET_TIME_READ,
>  .ro = 0x,
> +.post_read = current_time_postr,
>  },{ .name = "CALIB_WRITE",  .addr = A_CALIB_WRITE,
> +.post_write = unimp_postw,

Ditto.

>  },{ .name = "CALIB_READ",  .addr = A_CALIB_READ,
>  .ro = 0x1f,
>  },{ .name = "CURRENT_TIME",  .addr = A_CURRENT_TIME,
>  .ro = 0x,
> +.post_read = current_time_postr,
>  },{ .name = "CURRENT_TICK",  .addr = A_CURRENT_TICK,
>  .ro = 0x,
>  },{ .name = "ALARM",  .addr = A_ALARM,
> @@ -147,6 +174,10 @@ static void rtc_reset(DeviceState *dev)
>  register_reset(>regs_info[i]);
>  }
> 
> +trace_xlnx_zynqmp_rtc_gettime(s->current_tm.tm_year, 
> s->current_tm.tm_mon,
> +  s->current_tm.tm_mday, 
> s->current_tm.tm_hour,
> +  s->current_tm.tm_min, 
> s->current_tm.tm_sec);
> +
>  rtc_int_update_irq(s);
>  addr_error_int_update_irq(s);
>  }
> @@ -182,14 +213,47 @@ static void rtc_init(Object *obj)
>  sysbus_init_mmio(sbd, >iomem);
>  sysbus_init_irq(sbd, >irq_rtc_int);
>  sysbus_init_irq(sbd, >irq_addr_error_int);
> +
> +qemu_get_timedate(>current_tm, 0);
> +s->tick_offset = mktimegm(>current_tm) -
> +qemu_clock_get_ns(rtc_clock) / NANOSECONDS_PER_SECOND;
> +}
> +
> +static int rtc_pre_save(void *opaque)
> +{
> +XlnxZynqMPRTC *s = opaque;
> +
> +/* tick_offset is base_time - rtc_clock base time.  Instead, we want to
> + * store the base time relative to the QEMU_CLOCK_VIRTUAL for
> + * backwards-compatibility.
> + */
> +int64_t delta = qemu_clock_get_ns(rtc_clock) -
> +qemu_clock_get_ns(QEMU_CLOCK_VIRTUAL);
> +s->tick_offset_vmstate = s->tick_offset + delta / NANOSECONDS_PER_SECOND;
> +
> +

[Qemu-devel] [PATCH v1 1/1] linux-user: Fix webkitgtk hangs on 32-bit x86 target

[Alistair Francis]

Since commit "linux-user: Tidy and enforce reserved_va initialization"
(18e80c55bb6ec17c05ec0ba717ec83933c2bfc07) the Yocto webkitgtk build
hangs when cross compiling for 32-bit x86 on a 64-bit x86 machine using
musl.

To fix the issue reduce the MAX_RESERVED_VA macro to be a closer match
to what it was before the problematic commit.

Signed-off-by: Alistair Francis 
---

 linux-user/main.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/linux-user/main.c b/linux-user/main.c
index 450eb3ce65..c7cc0a184e 100644
--- a/linux-user/main.c
+++ b/linux-user/main.c
@@ -77,7 +77,7 @@ do {  
  \
   (TARGET_LONG_BITS == 32 || defined(TARGET_ABI32))
 /* There are a number of places where we assign reserved_va to a variable
of type abi_ulong and expect it to fit.  Avoid the last page.  */
-#   define MAX_RESERVED_VA  (0xul & TARGET_PAGE_MASK)
+#   define MAX_RESERVED_VA  (0x7ffful & TARGET_PAGE_MASK)
 #  else
 #   define MAX_RESERVED_VA  (1ul << TARGET_VIRT_ADDR_SPACE_BITS)
 #  endif
-- 
2.14.1

Re: [Qemu-devel] [PATCH v3 1/3] xlnx-zynqmp-rtc: Initial commit

[Philippe Mathieu-Daudé]

On 01/17/2018 02:27 PM, Alistair Francis wrote:
> Initial commit of the ZynqMP RTC device.
> 
> Signed-off-by: Alistair Francis 
> ---
> V2:
>  - Delete unused realise function
>  - Remove DB_PRINT()
> 
>  hw/timer/Makefile.objs |   1 +
>  hw/timer/xlnx-zynqmp-rtc.c | 218 
> +
>  include/hw/timer/xlnx-zynqmp-rtc.h |  84 ++

Please 'git config diff.orderFile scripts/git.orderfile' :)

>  3 files changed, 303 insertions(+)
>  create mode 100644 hw/timer/xlnx-zynqmp-rtc.c
>  create mode 100644 include/hw/timer/xlnx-zynqmp-rtc.h
> 
> diff --git a/hw/timer/Makefile.objs b/hw/timer/Makefile.objs
> index 8c19eac3b6..8b27a4b7ef 100644
> --- a/hw/timer/Makefile.objs
> +++ b/hw/timer/Makefile.objs
> @@ -21,6 +21,7 @@ common-obj-$(CONFIG_IMX) += imx_epit.o
>  common-obj-$(CONFIG_IMX) += imx_gpt.o
>  common-obj-$(CONFIG_LM32) += lm32_timer.o
>  common-obj-$(CONFIG_MILKYMIST) += milkymist-sysctl.o
> +common-obj-$(CONFIG_XLNX_ZYNQMP) += xlnx-zynqmp-rtc.o
> 
>  obj-$(CONFIG_ALTERA_TIMER) += altera_timer.o
>  obj-$(CONFIG_EXYNOS4) += exynos4210_mct.o
> diff --git a/hw/timer/xlnx-zynqmp-rtc.c b/hw/timer/xlnx-zynqmp-rtc.c
> new file mode 100644
> index 00..ead40fc42d
> --- /dev/null
> +++ b/hw/timer/xlnx-zynqmp-rtc.c
> @@ -0,0 +1,218 @@
> +/*
> + * QEMU model of the Xilinx ZynqMP Real Time Clock (RTC).
> + *
> + * Copyright (c) 2017 Xilinx Inc.
> + *
> + * Written-by: Alistair Francis 
> + *
> + * Permission is hereby granted, free of charge, to any person obtaining a 
> copy
> + * of this software and associated documentation files (the "Software"), to 
> deal
> + * in the Software without restriction, including without limitation the 
> rights
> + * to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
> + * copies of the Software, and to permit persons to whom the Software is
> + * furnished to do so, subject to the following conditions:
> + *
> + * The above copyright notice and this permission notice shall be included in
> + * all copies or substantial portions of the Software.
> + *
> + * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
> + * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
> + * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL
> + * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
> + * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING 
> FROM,
> + * OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN
> + * THE SOFTWARE.

*
* SPDX-License-Identifier: MIT

> + */
> +
> +#include "qemu/osdep.h"
> +#include "hw/sysbus.h"
> +#include "hw/register.h"
> +#include "qemu/bitops.h"
> +#include "qemu/log.h"
> +#include "hw/timer/xlnx-zynqmp-rtc.h"
> +
> +#ifndef XLNX_ZYNQMP_RTC_ERR_DEBUG
> +#define XLNX_ZYNQMP_RTC_ERR_DEBUG 0
> +#endif
> +
> +static void rtc_int_update_irq(XlnxZynqMPRTC *s)
> +{
> +bool pending = s->regs[R_RTC_INT_STATUS] & ~s->regs[R_RTC_INT_MASK];
> +qemu_set_irq(s->irq_rtc_int, pending);
> +}
> +
> +static void addr_error_int_update_irq(XlnxZynqMPRTC *s)
> +{
> +bool pending = s->regs[R_ADDR_ERROR] & ~s->regs[R_ADDR_ERROR_INT_MASK];
> +qemu_set_irq(s->irq_addr_error_int, pending);
> +}
> +
> +static void rtc_int_status_postw(RegisterInfo *reg, uint64_t val64)
> +{
> +XlnxZynqMPRTC *s = XLNX_ZYNQMP_RTC(reg->opaque);
> +rtc_int_update_irq(s);
> +}
> +
> +static uint64_t rtc_int_en_prew(RegisterInfo *reg, uint64_t val64)
> +{
> +XlnxZynqMPRTC *s = XLNX_ZYNQMP_RTC(reg->opaque);
> +uint32_t val = val64;
> +
> +s->regs[R_RTC_INT_MASK] &= ~val;
> +rtc_int_update_irq(s);
> +return 0;
> +}
> +
> +static uint64_t rtc_int_dis_prew(RegisterInfo *reg, uint64_t val64)
> +{
> +XlnxZynqMPRTC *s = XLNX_ZYNQMP_RTC(reg->opaque);
> +uint32_t val = val64;
> +
> +s->regs[R_RTC_INT_MASK] |= val;
> +rtc_int_update_irq(s);
> +return 0;
> +}
> +
> +static void addr_error_postw(RegisterInfo *reg, uint64_t val64)
> +{
> +XlnxZynqMPRTC *s = XLNX_ZYNQMP_RTC(reg->opaque);
> +addr_error_int_update_irq(s);
> +}
> +
> +static uint64_t addr_error_int_en_prew(RegisterInfo *reg, uint64_t val64)
> +{
> +XlnxZynqMPRTC *s = XLNX_ZYNQMP_RTC(reg->opaque);
> +uint32_t val = val64;
> +
> +s->regs[R_ADDR_ERROR_INT_MASK] &= ~val;
> +addr_error_int_update_irq(s);
> +return 0;
> +}
> +
> +static uint64_t addr_error_int_dis_prew(RegisterInfo *reg, uint64_t val64)
> +{
> +XlnxZynqMPRTC *s = XLNX_ZYNQMP_RTC(reg->opaque);
> +uint32_t val = val64;
> +
> +s->regs[R_ADDR_ERROR_INT_MASK] |= val;
> +addr_error_int_update_irq(s);
> +return 0;
> +}
> +
> +static const RegisterAccessInfo rtc_regs_info[] = {
> +{   .name = "SET_TIME_WRITE",  .addr = A_SET_TIME_WRITE,
> +},{ .name = "SET_TIME_READ",  .addr = A_SET_TIME_READ,
> +  

Re: [Qemu-devel] [PATCH 00/24] generalize parsing of cpu_model (part 4)

[Peter Maydell]

On 17 January 2018 at 19:15, Igor Mammedov  wrote:
> On Wed, 17 Jan 2018 16:12:09 +
> Peter Maydell  wrote:
>> I like moving this from being an ifdef ladder into per-cpu
>> code, but I don't think the definition belongs in target/$ARCH.
>> It's part of the choice usermode makes about how to handle
>> binaries it's loading, so it should go in linux-user/$ARCH/target_cpu.h.
>> target/$ARCH should really be for things that are properties
>> of the architecture.
> That's used not only by linux-user but also reused by null-machine.c
> to get access to a target specific cpu_class_by_name() callback.

That usage must want a different name, though, surely?
For Arm the default CPU for linux-user is 'any' but that
is usermode only and won't work for system emulation so
null-machine.c will need to pick something else.

thanks
-- PMM

Re: [Qemu-devel] [PATCH QEMU v1 0/4] multiboot: bss_end_addr can be zero / cleanup

[Jack Schwartz]

Hi Kevin and Anatol.

Kevin, thanks for your review.

More inline below...

On 01/15/18 07:54, Kevin Wolf wrote:

Am 21.12.2017 um 18:25 hat Jack Schwartz geschrieben:

Properly account for the possibility of multiboot kernels with a zero
bss_end_addr.  The Multiboot Specification, section 3.1.3 allows for
kernels without a bss section, by allowing a zeroed bss_end_addr multiboot
header field.

Do some cleanup to multiboot.c as well:
- Remove some unused variables.
- Use more intuitive header names when displaying fields in messages.
- Change fprintf(stderr...) to error_report

There are some conflicts with Anatol's (CCed) multiboot series:
https://lists.nongnu.org/archive/html/qemu-devel/2017-10/msg03003.html

None if these should be hard to resolve, but it would be good if you
could agree with each other whose patch series should come first, and
then the other one should be rebased on top of that.

Anatol,

from my side, there are pros and cons to either patch set going in 
first, but advantages to either are pretty negligible.  Pro for you 
going first: I can use the constants you will define in header files.  
Pro for me going first: your merge should be about the same as if you 
went first (since my changes are small, more localized and affect only 
multiboot.c) and my merge will be easier.


What are your thoughts?

Testing:
   1) Ran the "make check" test suite.
   2) Booted multiboot kernel with bss_end_addr=0.  (I rolled my own
  grub multiboot.elf test "kernel" by modifying source.)  Verified
  with gdb that new code that reads addresses/offsets from multiboot
  header was accessed.
   3) Booted multiboot kernel with non-zero bss_end_addr.
   4) Uncommented DEBUG_MULTIBOOT in multiboot.c and verified messages worked.
   5) Code has soaked in an internal repo for two months.
Can you integrate your test kernel from 2) in tests/multiboot/ so we can
keep this as a regression test?

Kevin and alias,

Before I proceed with adding my multiboot test file, I'll clarify here 
that I started with a version from the grub2 tree.  In that file I 
expanded a header file, also from the same tree.  Neither file had any 
license header, though the tree I got them from (Dated October 2017) 
contains the GNU GPLv3 license file.


I'll need to check with my company before I can say I can deliver this 
file.  If I deliver it, I'll add a header stating the GPL license, that 
it came from grub2 and to check its repository for contributors.

Jack Schwartz (4):
   multiboot: bss_end_addr can be zero
   multiboot: Remove unused variables from multiboot.c
   multiboot: Use header names when displaying fields
   multiboot: fprintf(stderr...) -> error_report()

Apart from the conflicts, the patches look good to me.

    Thanks,
    Jack


Kevin

Re: [Qemu-devel] [PATCH v2 1/3] header sync

[Christian Borntraeger]

It is just a header sync and mimics the kernel.
The previous header sync added the the commit that added the SPDX tag and this
header sync added the commit that removed the now redundant licence text.

On 01/17/2018 08:46 PM, Eric Blake wrote:
> On 01/17/2018 01:37 PM, Christian Borntraeger wrote:
>> replace with proper header sync
>>
>> Signed-off-by: Christian Borntraeger 
>> ---
>>  linux-headers/asm-s390/kvm.h | 9 -
>>  linux-headers/linux/kvm.h| 5 +++--
>>  2 files changed, 7 insertions(+), 7 deletions(-)
>>tag
>> diff --git a/linux-headers/asm-s390/kvm.h b/linux-headers/asm-s390/kvm.h
>> index 32d372e..11def14 100644
>> --- a/linux-headers/asm-s390/kvm.h
>> +++ b/linux-headers/asm-s390/kvm.h
>> @@ -6,10 +6,6 @@
>>   *
>>   * Copyright IBM Corp. 2008
>>   *
>> - * This program is free software; you can redistribute it and/or modify
>> - * it under the terms of the GNU General Public License (version 2 only)
>> - * as published by the Free Software Foundation.
>> - *
> 
> Is dropping a license clause intentional?  If so, the commit message may
> want to go into more details why it is okay.
> 

Re: [Qemu-devel] [PATCH v2 1/3] header sync

[Eric Blake]

On 01/17/2018 01:37 PM, Christian Borntraeger wrote:
> replace with proper header sync
> 
> Signed-off-by: Christian Borntraeger 
> ---
>  linux-headers/asm-s390/kvm.h | 9 -
>  linux-headers/linux/kvm.h| 5 +++--
>  2 files changed, 7 insertions(+), 7 deletions(-)
> 
> diff --git a/linux-headers/asm-s390/kvm.h b/linux-headers/asm-s390/kvm.h
> index 32d372e..11def14 100644
> --- a/linux-headers/asm-s390/kvm.h
> +++ b/linux-headers/asm-s390/kvm.h
> @@ -6,10 +6,6 @@
>   *
>   * Copyright IBM Corp. 2008
>   *
> - * This program is free software; you can redistribute it and/or modify
> - * it under the terms of the GNU General Public License (version 2 only)
> - * as published by the Free Software Foundation.
> - *

Is dropping a license clause intentional?  If so, the commit message may
want to go into more details why it is okay.

-- 
Eric Blake, Principal Software Engineer
Red Hat, Inc.   +1-919-301-3266
Virtualization:  qemu.org | libvirt.org



signature.asc
Description: OpenPGP digital signature

Re: [Qemu-devel] [PATCH 0/2] iotests compat=0.10 fixes

[Max Reitz]

On 2018-01-17 17:54, Eric Blake wrote:
> As requested here:
> https://lists.gnu.org/archive/html/qemu-devel/2018-01/msg03984.html
> 
> Eric Blake (1):
>   iotests: Split 177 into two parts for compat=0.10
> 
> Max Reitz (1):
>   iotests: Disable some tests for compat=0.10

Thanks!  Applied to my block branch:

https://github.com/XanClic/qemu/commits/block

Max



signature.asc
Description: OpenPGP digital signature

[Qemu-devel] [PATCH v2 2/3] s390x/kvm: Handle bpb feature

[Christian Borntraeger]

We need to handle the bpb control on reset and migration. Normally
stfle.82 is transparent (and the normal guest part works without
hypervisor activity). To prevent any issues we require full
host kernel support for this feature.

Signed-off-by: Christian Borntraeger 
---
 target/s390x/cpu.c  |  1 +
 target/s390x/cpu.h  |  1 +
 target/s390x/cpu_features.c |  1 +
 target/s390x/cpu_features_def.h |  1 +
 target/s390x/gen-features.c |  1 +
 target/s390x/kvm.c  | 14 ++
 target/s390x/machine.c  | 17 +
 7 files changed, 36 insertions(+)

diff --git a/target/s390x/cpu.c b/target/s390x/cpu.c
index ae3cee9..1577b2c 100644
--- a/target/s390x/cpu.c
+++ b/target/s390x/cpu.c
@@ -89,6 +89,7 @@ static void s390_cpu_reset(CPUState *s)
 CPUS390XState *env = >env;
 
 env->pfault_token = -1UL;
+env->bpbc = 0;
 scc->parent_reset(s);
 cpu->env.sigp_order = 0;
 s390_cpu_set_state(CPU_STATE_STOPPED, cpu);
diff --git a/target/s390x/cpu.h b/target/s390x/cpu.h
index 1a8b6b9..8514905 100644
--- a/target/s390x/cpu.h
+++ b/target/s390x/cpu.h
@@ -93,6 +93,7 @@ struct CPUS390XState {
 
 uint32_t fpc;  /* floating-point control register */
 uint32_t cc_op;
+uint8_t bpbc;  /* branch prediction blocking */
 
 float_status fpu_status; /* passed to softfloat lib */
 
diff --git a/target/s390x/cpu_features.c b/target/s390x/cpu_features.c
index 31a4676..5d1c210 100644
--- a/target/s390x/cpu_features.c
+++ b/target/s390x/cpu_features.c
@@ -89,6 +89,7 @@ static const S390FeatDef s390_features[] = {
 FEAT_INIT("msa4-base", S390_FEAT_TYPE_STFL, 77, 
"Message-security-assist-extension-4 facility (excluding subfunctions)"),
 FEAT_INIT("edat2", S390_FEAT_TYPE_STFL, 78, "Enhanced-DAT facility 2"),
 FEAT_INIT("dfppc", S390_FEAT_TYPE_STFL, 80, "Decimal-floating-point 
packed-conversion facility"),
+FEAT_INIT("bpb", S390_FEAT_TYPE_STFL, 82, "Branch Prediction Blocking"),
 FEAT_INIT("vx", S390_FEAT_TYPE_STFL, 129, "Vector facility"),
 FEAT_INIT("iep", S390_FEAT_TYPE_STFL, 130, 
"Instruction-execution-protection facility"),
 FEAT_INIT("sea_esop2", S390_FEAT_TYPE_STFL, 131, "Side-effect-access 
facility and Enhanced-suppression-on-protection facility 2"),
diff --git a/target/s390x/cpu_features_def.h b/target/s390x/cpu_features_def.h
index 4b6d4e9..4487cfd 100644
--- a/target/s390x/cpu_features_def.h
+++ b/target/s390x/cpu_features_def.h
@@ -80,6 +80,7 @@ typedef enum {
 S390_FEAT_MSA_EXT_4,
 S390_FEAT_EDAT_2,
 S390_FEAT_DFP_PACKED_CONVERSION,
+S390_FEAT_BPB,
 S390_FEAT_VECTOR,
 S390_FEAT_INSTRUCTION_EXEC_PROT,
 S390_FEAT_SIDE_EFFECT_ACCESS_ESOP2,
diff --git a/target/s390x/gen-features.c b/target/s390x/gen-features.c
index b24f6ad..95ee870 100644
--- a/target/s390x/gen-features.c
+++ b/target/s390x/gen-features.c
@@ -357,6 +357,7 @@ static uint16_t full_GEN7_GA1[] = {
 S390_FEAT_SIE_GPERE,
 S390_FEAT_SIE_IB,
 S390_FEAT_SIE_CEI,
+S390_FEAT_BPB,
 };
 
 static uint16_t full_GEN7_GA2[] = {
diff --git a/target/s390x/kvm.c b/target/s390x/kvm.c
index 6a18a41..8736001 100644
--- a/target/s390x/kvm.c
+++ b/target/s390x/kvm.c
@@ -490,6 +490,11 @@ int kvm_arch_put_registers(CPUState *cs, int level)
 cs->kvm_run->kvm_dirty_regs |= KVM_SYNC_GSCB;
 }
 
+if (can_sync_regs(cs, KVM_SYNC_BPBC)) {
+cs->kvm_run->s.regs.bpbc = env->bpbc;
+cs->kvm_run->kvm_dirty_regs |= KVM_SYNC_BPBC;
+}
+
 /* Finally the prefix */
 if (can_sync_regs(cs, KVM_SYNC_PREFIX)) {
 cs->kvm_run->s.regs.prefix = env->psa;
@@ -600,6 +605,10 @@ int kvm_arch_get_registers(CPUState *cs)
 memcpy(env->gscb, cs->kvm_run->s.regs.gscb, 32);
 }
 
+if (can_sync_regs(cs, KVM_SYNC_BPBC)) {
+env->bpbc = cs->kvm_run->s.regs.bpbc;
+}
+
 /* pfault parameters */
 if (can_sync_regs(cs, KVM_SYNC_PFAULT)) {
 env->pfault_token = cs->kvm_run->s.regs.pft;
@@ -2278,6 +2287,11 @@ void kvm_s390_get_host_cpu_model(S390CPUModel *model, 
Error **errp)
 clear_bit(S390_FEAT_CMM_NT, model->features);
 }
 
+/* bpb needs kernel support for migration, VSIE and reset */
+if (!kvm_check_extension(kvm_state, KVM_CAP_S390_BPB)) {
+clear_bit(S390_FEAT_BPB, model->features);
+}
+
 /* We emulate a zPCI bus and AEN, therefore we don't need HW support */
 if (pci_available) {
 set_bit(S390_FEAT_ZPCI, model->features);
diff --git a/target/s390x/machine.c b/target/s390x/machine.c
index b78f326..4aac456 100644
--- a/target/s390x/machine.c
+++ b/target/s390x/machine.c
@@ -194,6 +194,22 @@ const VMStateDescription vmstate_gscb = {
 }
 };
 
+static bool bpbc_needed(void *opaque)
+{
+return s390_has_feat(S390_FEAT_BPB);
+}
+
+const VMStateDescription vmstate_bpbc = {
+.name = "cpu/bpbc",
+.version_id = 1,
+.minimum_version_id = 1,
+.needed = bpbc_needed,
+

[Qemu-devel] [PATCH v2 1/3] header sync

[Christian Borntraeger]

replace with proper header sync

Signed-off-by: Christian Borntraeger 
---
 linux-headers/asm-s390/kvm.h | 9 -
 linux-headers/linux/kvm.h| 5 +++--
 2 files changed, 7 insertions(+), 7 deletions(-)

diff --git a/linux-headers/asm-s390/kvm.h b/linux-headers/asm-s390/kvm.h
index 32d372e..11def14 100644
--- a/linux-headers/asm-s390/kvm.h
+++ b/linux-headers/asm-s390/kvm.h
@@ -6,10 +6,6 @@
  *
  * Copyright IBM Corp. 2008
  *
- * This program is free software; you can redistribute it and/or modify
- * it under the terms of the GNU General Public License (version 2 only)
- * as published by the Free Software Foundation.
- *
  *Author(s): Carsten Otte 
  *   Christian Borntraeger 
  */
@@ -228,6 +224,7 @@ struct kvm_guest_debug_arch {
 #define KVM_SYNC_RICCB  (1UL << 7)
 #define KVM_SYNC_FPRS   (1UL << 8)
 #define KVM_SYNC_GSCB   (1UL << 9)
+#define KVM_SYNC_BPBC   (1UL << 10)
 /* length and alignment of the sdnx as a power of two */
 #define SDNXC 8
 #define SDNXL (1UL << SDNXC)
@@ -251,7 +248,9 @@ struct kvm_sync_regs {
};
__u8  reserved[512];/* for future vector expansion */
__u32 fpc;  /* valid on KVM_SYNC_VRS or KVM_SYNC_FPRS */
-   __u8 padding1[52];  /* riccb needs to be 64byte aligned */
+   __u8 bpbc : 1;  /* bp mode */
+   __u8 reserved2 : 7;
+   __u8 padding1[51];  /* riccb needs to be 64byte aligned */
__u8 riccb[64]; /* runtime instrumentation controls block */
__u8 padding2[192]; /* sdnx needs to be 256byte aligned */
union {
diff --git a/linux-headers/linux/kvm.h b/linux-headers/linux/kvm.h
index ce6c2f1..b4503d8 100644
--- a/linux-headers/linux/kvm.h
+++ b/linux-headers/linux/kvm.h
@@ -630,9 +630,9 @@ struct kvm_s390_irq {
 
 struct kvm_s390_irq_state {
__u64 buf;
-   __u32 flags;
+   __u32 flags;/* will stay unused for compatibility reasons */
__u32 len;
-   __u32 reserved[4];
+   __u32 reserved[4];  /* will stay unused for compatibility reasons */
 };
 
 /* for KVM_SET_GUEST_DEBUG */
@@ -932,6 +932,7 @@ struct kvm_ppc_resize_hpt {
 #define KVM_CAP_HYPERV_SYNIC2 148
 #define KVM_CAP_HYPERV_VP_INDEX 149
 #define KVM_CAP_S390_AIS_MIGRATION 150
+#define KVM_CAP_S390_BPB 151
 
 #ifdef KVM_CAP_IRQ_ROUTING
 
-- 
2.9.4

[Qemu-devel] [PATCH v2 0/3] s390x/kvm: implement new hardware/firmware features

[Christian Borntraeger]

We want to provide more hw features to guests, namely the new bpb
control as well as other transparent facilities that might be
introduced by firmware updates (e.g. the stfle facility 81).

See the kernel discussion for the KVM side
https://www.spinics.net/lists/kernel/msg2700551.html

v1->v2: - style and comment fixes
- drop transparent facility patch
- add patch to introduce facility 81

Christian Borntraeger (3):
  header sync
  s390x/kvm: Handle bpb feature
  s390x/kvm: provide stfle.81

 linux-headers/asm-s390/kvm.h|  9 -
 linux-headers/linux/kvm.h   |  5 +++--
 target/s390x/cpu.c  |  1 +
 target/s390x/cpu.h  |  1 +
 target/s390x/cpu_features.c |  2 ++
 target/s390x/cpu_features_def.h |  2 ++
 target/s390x/gen-features.c |  2 ++
 target/s390x/kvm.c  | 14 ++
 target/s390x/machine.c  | 17 +
 9 files changed, 46 insertions(+), 7 deletions(-)

-- 
2.9.4

[Qemu-devel] [PATCH v2 3/3] s390x/kvm: provide stfle.81

[Christian Borntraeger]

stfle.81 (ppa15) is a transparent facility that can be passed to the
guest without the need to implement hypervisor support. As this feature
can be provided by firmware we add it to all full models.

Signed-off-by: Christian Borntraeger 
---
 target/s390x/cpu_features.c | 1 +
 target/s390x/cpu_features_def.h | 1 +
 target/s390x/gen-features.c | 1 +
 3 files changed, 3 insertions(+)

diff --git a/target/s390x/cpu_features.c b/target/s390x/cpu_features.c
index 5d1c210..1550ab0 100644
--- a/target/s390x/cpu_features.c
+++ b/target/s390x/cpu_features.c
@@ -89,6 +89,7 @@ static const S390FeatDef s390_features[] = {
 FEAT_INIT("msa4-base", S390_FEAT_TYPE_STFL, 77, 
"Message-security-assist-extension-4 facility (excluding subfunctions)"),
 FEAT_INIT("edat2", S390_FEAT_TYPE_STFL, 78, "Enhanced-DAT facility 2"),
 FEAT_INIT("dfppc", S390_FEAT_TYPE_STFL, 80, "Decimal-floating-point 
packed-conversion facility"),
+FEAT_INIT("ppa15", S390_FEAT_TYPE_STFL, 81, "PPA15 is installed"),
 FEAT_INIT("bpb", S390_FEAT_TYPE_STFL, 82, "Branch Prediction Blocking"),
 FEAT_INIT("vx", S390_FEAT_TYPE_STFL, 129, "Vector facility"),
 FEAT_INIT("iep", S390_FEAT_TYPE_STFL, 130, 
"Instruction-execution-protection facility"),
diff --git a/target/s390x/cpu_features_def.h b/target/s390x/cpu_features_def.h
index 4487cfd..4d93087 100644
--- a/target/s390x/cpu_features_def.h
+++ b/target/s390x/cpu_features_def.h
@@ -80,6 +80,7 @@ typedef enum {
 S390_FEAT_MSA_EXT_4,
 S390_FEAT_EDAT_2,
 S390_FEAT_DFP_PACKED_CONVERSION,
+S390_FEAT_PPA15,
 S390_FEAT_BPB,
 S390_FEAT_VECTOR,
 S390_FEAT_INSTRUCTION_EXEC_PROT,
diff --git a/target/s390x/gen-features.c b/target/s390x/gen-features.c
index 95ee870..50bd3f4 100644
--- a/target/s390x/gen-features.c
+++ b/target/s390x/gen-features.c
@@ -357,6 +357,7 @@ static uint16_t full_GEN7_GA1[] = {
 S390_FEAT_SIE_GPERE,
 S390_FEAT_SIE_IB,
 S390_FEAT_SIE_CEI,
+S390_FEAT_PPA15,
 S390_FEAT_BPB,
 };
 
-- 
2.9.4

Re: [Qemu-devel] [PATCH v7 4/4] hw: convert virtio-input-hid device to keycodemapdb

[Michael S. Tsirkin]

On Wed, Jan 17, 2018 at 01:02:07PM -0600, Eric Blake wrote:
> On 01/17/2018 10:41 AM, Daniel P. Berrange wrote:
> > Replace the keymap_qcode table with automatically generated
> > tables.
> > 
> > Missing entries in keymap_qcode now fixed:
> > 
> 
> > 
> > When a keycode is removed from the list of possible keycodes that host can
> > send to the guest, it means that the guest OS will think it is possible
> > to receive a key that in pratice can never be generated, which is harmless.
> 
> s/pratice/practice/
> 
> > 
> > When a keycode is added to the list of possible keycodes that the host can
> > send to the guest, it means that the guest OS can see an unexpected event.
> > The Linux virtio_input.c driver code simply forwards this event to the
> > input_event() method in the Linux input subsystem. This in turn calls
> > input_handle_event(), which then calls input_get_disposition(). This method
> > checks if the input event is present in the permitted keys bitmap, and if
> > not returns INPUT_IGNORE_EVENT. Thus the unexpected event will get dropped,
> > which is harmless.
> > 
> > If the guest OS reboots, or otherwise re-initializes the virt-input device,
> > it will read the new keycode bitmap. No matter how many keys are defined,
> > the config space has a fixed 128 byte bitmap. There is, however, a size
> > field defiend which says how many bytes in the bitmap are used. So the guest
> 
> s/defiend/defined/
> 
> > OS reads the size of the bitmap, and then it reads the data from bitmap upto
> 
> s/upto/up to/
> 
> > the designated size. So if the guest OS re-initializes at precisely the time
> > that QEMU is migrated across versions, in the worst case, it could 
> > conceivably
> > read the old size field, but then get the newly updated bitmap.  If a key 
> > were
> > added this is harmless, since it simply means it may not process the newly
> > added key. If a key were removed, then it could be readnig a byte from the
> 
> s/readnig/reading/
> 
> > bitmap that was not initialized. Fortunately QEMU always memsets() the 
> > entire
> 
> maybe s/memsets()/memset()s/
> 
> > bitmap to 0, prior to setting keybits. Thus the guest OS will simply read
> > zeros, which is again harmless.
> > 
> > Based on this analysis, it is believed that there is no need to preserve the
> > virtio-input-hid keymaps across migration, as the host<->guest ABI change is
> > harmless and self-resolving at time of guest reboot.
> > 
> > NB, this behaviour should perhaps be formalized in the virtio-input spec
> > to declare how guest OS drivers should be written to be robust in their
> > handling of the potentially changable key bitmaps.
> 
> Your analysis of the issues, as well as the advice to enhance the
> virtio-input spec to document that a guest must not react negatively to
> the change, both sound reasonable.


If anyone has the time to finalize the spec patch and send it to
the virtio tc, that would be very welcome!
IIRC the last revision was
[virtio-dev] [PATCH v2] Add virtio input device specification.


> > 
> > Signed-off-by: Daniel P. Berrange 
> > ---
> >  hw/input/virtio-input-hid.c | 136 
> > +++-
> >  1 file changed, 9 insertions(+), 127 deletions(-)
> 
> Fun diffstat ratio!
> 
> I have not closely reviewed the series, so much as noticing the grammar
> on the fly.
> 
> -- 
> Eric Blake, Principal Software Engineer
> Red Hat, Inc.   +1-919-301-3266
> Virtualization:  qemu.org | libvirt.org
> 

Re: [Qemu-devel] [qemu-s390x] [PATCH 12/24] s390x: cpu: add TARGET_DEFAULT_CPU_TYPE macro

[Igor Mammedov]

On Wed, 17 Jan 2018 17:04:31 +0100
David Hildenbrand  wrote:

> On 17.01.2018 16:43, Igor Mammedov wrote:
> > it will be used for for 2 purposes, 1st is to
> > provide to cpu name resolving class for machine 'none'
> >   cpu_parse_cpu_model(machine_class->default_cpu_type, cpu_model)
> > and later to drop a bunch of ifdefs *-user/main.c that
> > set default cpu_model.
> > 
> > Use default value from linux-user for TARGET_DEFAULT_CPU_TYPE.
> > 
> > Signed-off-by: Igor Mammedov 
> > ---
> > CC: Richard Henderson 
> > CC: Alexander Graf 
> > CC: qemu-s3...@nongnu.org
> > ---
> >  target/s390x/cpu.h | 1 +
> >  1 file changed, 1 insertion(+)
> > 
> > diff --git a/target/s390x/cpu.h b/target/s390x/cpu.h
> > index 1a8b6b9..174624a 100644
> > --- a/target/s390x/cpu.h
> > +++ b/target/s390x/cpu.h
> > @@ -731,6 +731,7 @@ void s390_set_qemu_cpu_model(uint16_t type, uint8_t 
> > gen, uint8_t ec_ga,
> >  
> >  #define S390_CPU_TYPE_SUFFIX "-" TYPE_S390_CPU
> >  #define S390_CPU_TYPE_NAME(name) (name S390_CPU_TYPE_SUFFIX)
> > +#define TARGET_DEFAULT_CPU_TYPE S390_CPU_TYPE_NAME("qemu")
> >  
> >  /* you can call this signal handler from your SIGBUS and SIGSEGV
> > signal handlers to inform the virtual CPU of exceptions. non zero
> >   
> 
> At least from a !KVM perspective this is correct. And that is at least
> relevant for linux-user. I doubt that this is relevant for KVM. The
> "none" machine cannot be used either way and CPU models are sensed via qmp.
If you look at cpu_parse_cpu_model() impl., you'll see that
TARGET_DEFAULT_CPU_TYPE isn't used as actual CPU type but as a proxy
to get access to CPUClass::class_by_name() callback which is
implemented by every target. So accelerator doesn't have any effect
here.

> Reviewed-by: David Hildenbrand 
Thanks! 

[Qemu-devel] [PATCH] hw/pci-bridge: fix pcie root port's IO hints capability

[Marcel Apfelbaum]

The gen_pcie_root_port mem-reserve and pref32-reserve properties are
defined as size (so uint64_t), but passed as uint32_t when building
the 'IO hints' vendor specific capability.
Passing 4G (or more) gets truncated and passed as a zero reservation.
Is not a huge issue since the guest firmware will always compare the
hints with the default value and take the maximum.

Fix it by passing the values as uint64_t and failing to init the
gen_pcie_root_port id invalid values are used.

Signed-off-by: Marcel Apfelbaum 
---
 hw/pci/pci_bridge.c | 24 +++-
 include/hw/pci/pci_bridge.h |  4 ++--
 2 files changed, 21 insertions(+), 7 deletions(-)

diff --git a/hw/pci/pci_bridge.c b/hw/pci/pci_bridge.c
index b2e50c36a0..40a39f57cb 100644
--- a/hw/pci/pci_bridge.c
+++ b/hw/pci/pci_bridge.c
@@ -412,22 +412,36 @@ void pci_bridge_map_irq(PCIBridge *br, const char* 
bus_name,
 
 int pci_bridge_qemu_reserve_cap_init(PCIDevice *dev, int cap_offset,
  uint32_t bus_reserve, uint64_t io_reserve,
- uint32_t mem_non_pref_reserve,
- uint32_t mem_pref_32_reserve,
+ uint64_t mem_non_pref_reserve,
+ uint64_t mem_pref_32_reserve,
  uint64_t mem_pref_64_reserve,
  Error **errp)
 {
-if (mem_pref_32_reserve != (uint32_t)-1 &&
+if (mem_pref_32_reserve != (uint64_t)-1 &&
 mem_pref_64_reserve != (uint64_t)-1) {
 error_setg(errp,
"PCI resource reserve cap: PREF32 and PREF64 conflict");
 return -EINVAL;
 }
 
+if (mem_non_pref_reserve != (uint64_t)-1 &&
+mem_non_pref_reserve >= (1ULL << 32)) {
+error_setg(errp,
+   "PCI resource reserve cap: mem-reserve must be less than 
4G");
+return -EINVAL;
+}
+
+if (mem_pref_32_reserve != (uint64_t)-1 &&
+mem_pref_32_reserve >= (1ULL << 32)) {
+error_setg(errp,
+   "PCI resource reserve cap: pref32-reserve  must be less 
than 4G");
+return -EINVAL;
+}
+
 if (bus_reserve == (uint32_t)-1 &&
 io_reserve == (uint64_t)-1 &&
-mem_non_pref_reserve == (uint32_t)-1 &&
-mem_pref_32_reserve == (uint32_t)-1 &&
+mem_non_pref_reserve == (uint64_t)-1 &&
+mem_pref_32_reserve == (uint64_t)-1 &&
 mem_pref_64_reserve == (uint64_t)-1) {
 return 0;
 }
diff --git a/include/hw/pci/pci_bridge.h b/include/hw/pci/pci_bridge.h
index 9b44ffd22a..0347da52d2 100644
--- a/include/hw/pci/pci_bridge.h
+++ b/include/hw/pci/pci_bridge.h
@@ -135,8 +135,8 @@ typedef struct PCIBridgeQemuCap {
 
 int pci_bridge_qemu_reserve_cap_init(PCIDevice *dev, int cap_offset,
   uint32_t bus_reserve, uint64_t io_reserve,
-  uint32_t mem_non_pref_reserve,
-  uint32_t mem_pref_32_reserve,
+  uint64_t mem_non_pref_reserve,
+  uint64_t mem_pref_32_reserve,
   uint64_t mem_pref_64_reserve,
   Error **errp);
 
-- 
2.13.5

Re: [Qemu-devel] [PATCH 00/24] generalize parsing of cpu_model (part 4)

[Igor Mammedov]

On Wed, 17 Jan 2018 16:12:09 +
Peter Maydell  wrote:

> On 17 January 2018 at 15:43, Igor Mammedov  wrote:
> > Series is finishing work on generalizing cpu_model parsing
> > and limiting parts that deal with inconsistent cpu_model
> > naming to "-cpu" CLI option processing in vl.c/*-user.main.c
> > and FOO_cpu_class_by_name() callbacks.
> >
> > It introduces TARGET_DEFAULT_CPU_TYPE which must be defined
> > by each target and is used setting default cpu type for
> > linux/bsd-user targets and as anchor point to pick cpu class
> > that provides target specific FOO_cpu_class_by_name()
> > callback for cpu_parse_cpu_model() in null-machine.c
> > which is compiled for all targets that have system
> > mode emulation.  
> 
> I like moving this from being an ifdef ladder into per-cpu
> code, but I don't think the definition belongs in target/$ARCH.
> It's part of the choice usermode makes about how to handle
> binaries it's loading, so it should go in linux-user/$ARCH/target_cpu.h.
> target/$ARCH should really be for things that are properties
> of the architecture.
That's used not only by linux-user but also reused by null-machine.c
to get access to a target specific cpu_class_by_name() callback.
I admit that it's a convoluted API i.e. for cpu_parse_cpu_model()
to require a target specific CPU type to resolve cpu_model name,
but that's what we ended up with and have now.
It seemed logical to me to put YET_ANOTHER_CPU_TYPE to
target/$ARCH/cpu.h along with other target specific CPU type
macros'. 

Main goal of this series is not TARGET_DEFAULT_CPU_TYPE and
its abuse by null-machine.c, but rather getting rid of
cpu_model handling across whole tree (which is easy to misuse
due to existing APIs and its general availability) and limiting
cpu_model translation to option parsing+target specific
cpu_class_by_name() callbacks.

We can build on top of that linux-user specific extension
to pick CPU type based on ELF notes, the difference would
be that it will work with cpu types and not with cpu_model
as it were implemented in:
  [PATCH v3 0/4] linux-user: select CPU type according  ELF header values

> thanks
> -- PMM

Re: [Qemu-devel] [PATCH v7 4/4] hw: convert virtio-input-hid device to keycodemapdb

[Eric Blake]

On 01/17/2018 10:41 AM, Daniel P. Berrange wrote:
> Replace the keymap_qcode table with automatically generated
> tables.
> 
> Missing entries in keymap_qcode now fixed:
> 

> 
> When a keycode is removed from the list of possible keycodes that host can
> send to the guest, it means that the guest OS will think it is possible
> to receive a key that in pratice can never be generated, which is harmless.

s/pratice/practice/

> 
> When a keycode is added to the list of possible keycodes that the host can
> send to the guest, it means that the guest OS can see an unexpected event.
> The Linux virtio_input.c driver code simply forwards this event to the
> input_event() method in the Linux input subsystem. This in turn calls
> input_handle_event(), which then calls input_get_disposition(). This method
> checks if the input event is present in the permitted keys bitmap, and if
> not returns INPUT_IGNORE_EVENT. Thus the unexpected event will get dropped,
> which is harmless.
> 
> If the guest OS reboots, or otherwise re-initializes the virt-input device,
> it will read the new keycode bitmap. No matter how many keys are defined,
> the config space has a fixed 128 byte bitmap. There is, however, a size
> field defiend which says how many bytes in the bitmap are used. So the guest

s/defiend/defined/

> OS reads the size of the bitmap, and then it reads the data from bitmap upto

s/upto/up to/

> the designated size. So if the guest OS re-initializes at precisely the time
> that QEMU is migrated across versions, in the worst case, it could conceivably
> read the old size field, but then get the newly updated bitmap.  If a key were
> added this is harmless, since it simply means it may not process the newly
> added key. If a key were removed, then it could be readnig a byte from the

s/readnig/reading/

> bitmap that was not initialized. Fortunately QEMU always memsets() the entire

maybe s/memsets()/memset()s/

> bitmap to 0, prior to setting keybits. Thus the guest OS will simply read
> zeros, which is again harmless.
> 
> Based on this analysis, it is believed that there is no need to preserve the
> virtio-input-hid keymaps across migration, as the host<->guest ABI change is
> harmless and self-resolving at time of guest reboot.
> 
> NB, this behaviour should perhaps be formalized in the virtio-input spec
> to declare how guest OS drivers should be written to be robust in their
> handling of the potentially changable key bitmaps.

Your analysis of the issues, as well as the advice to enhance the
virtio-input spec to document that a guest must not react negatively to
the change, both sound reasonable.

> 
> Signed-off-by: Daniel P. Berrange 
> ---
>  hw/input/virtio-input-hid.c | 136 
> +++-
>  1 file changed, 9 insertions(+), 127 deletions(-)

Fun diffstat ratio!

I have not closely reviewed the series, so much as noticing the grammar
on the fly.

-- 
Eric Blake, Principal Software Engineer
Red Hat, Inc.   +1-919-301-3266
Virtualization:  qemu.org | libvirt.org



signature.asc
Description: OpenPGP digital signature

Re: [Qemu-devel] QEMU virt board: extending various limits

[Igor Mammedov]

On Wed, 17 Jan 2018 17:53:48 +0100
Andrew Jones  wrote:

> On Wed, Jan 17, 2018 at 04:18:30PM +, Peter Maydell wrote:
> > On 17 January 2018 at 16:15, Igor Mammedov  wrote:  
> > > my idea was to drop fixed RAM base for virt board (at least for
> > > new machine types) so that QEMU could specify it dynamically and
> > > firmware would get base from x0 instead of compiled in constant.  
> > 
> > "base of ram is fixed" is about the one thing we've told
> > people they can rely on without fishing it out of the
> > device tree, so I think I'll just rule changing that out
> > of consideration now :-)
> >  
> 
> So that leaves three choices:
> 
> 1) New machine type that has a different or non-fixed RAM base
> 
> (Makes the QEMU/AAVMF zoo even worse.)
may be it's a way to go, we can drop all the stuff we don't
really need for virt use case and new firmware would
pick up RAM base from x0 and it would be able to work on
both new and old (fixed base put in x0) machine type.
Guests that want to run on new machine would have to
be booted by new AAVMF or handle dynamic RAM base from
x0 themselves.

how about virt-enterprise (64bit only EFI OS support booted by AAVMF)?

> 2) Implement spit memory where one chunk is guaranteed to be at
>the 1G boundary, e.g. 'size <= 1G' at 1G
> 
> (The QEMU work will no doubt snowball, especially when considering
>  memory hotplug. Although hotplug will likely warrant using DIMMs
>  anyway, which means one 'size <= 1G' at 1G DIMM could be a non-removable,
>  there by default DIMM, and other DIMM(s) would go elsewhere in order to
>  implement the split memory.)
look at PC memory map and a bunch of tweaks that alter it,
it's hard to figure out if a change to it would break something.
So if we can (i.e. not restricted by spec) than we should go
for a flexible route that doesn't have design issues from the start.


> 3) Leave memory like it is and just put everything else we want to expand
>in high memory, probably above the second PCIe window. I.e. CPU
>redistributor regions 124 and up and an additional PCIe ECAM space
>would go up there.
> 
> (Easiest, most backward compatible thing to do. Is there risk with putting
>  those things above 4G? Someday we may want to shift those things and the
>  second PCIe window even higher, if we ever want to support more than 515
>  GB of memory, but I guess that shouldn't be a problem.)
we can do that, but platform is too new so eventually we might
have to change layout and have to deal with compat issues than,
but it will be too late to change direction (with existing customers)
so we would have to live with self-inflicted pain which could
be avoided if we made thing flexible.


> 
> Thanks,
> drew