date:20200209

On Wed, Feb 05, 2020 at 07:24:04AM +0100, Thomas Huth wrote:
> On 05/02/2020 06.30, David Gibson wrote:
> > On Tue, Feb 04, 2020 at 10:20:14AM +0100, Thomas Huth wrote:
> >> On 04/02/2020 09.54, Cornelia Huck wrote:
> >>> On Tue, 4 Feb 2020 07:16:46 +0100
> >>> Thomas Huth  wrote:
> >>>
>  On 04/02/2020 00.26, Paolo Bonzini wrote:
> >
> >
> > Il mar 4 feb 2020, 00:20 Alexey Kardashevskiy  > > ha scritto:
> >
> > Speaking seriously, what would I put into the guest?
> >
> > Only things that would be considered drivers. Ignore the partitions
> > issue for now so that you can just pass the device tree services to QEMU
> > with hypercalls.
> >
> > Netboot's dhcp/tftp/ip/ipv6 client? It is going to be another SLOF,
> > smaller but adhoc with only a couple of people knowing it.
> >
> >
> > You can generalize and reuse the s390 code. All you have to write is the
> > PCI scan and virtio-pci setup.  
> 
>  Well, for netbooting, the s390-ccw bios uses the libnet code from SLOF,
>  so re-using this for a slim netboot client on ppc64 would certainly be
>  feasible (especially since there are also already virtio drivers in SLOF
>  that are written in C), but I think it is not very future proof. The
>  libnet from SLOF only supports UDP, and no TCP. So for advanced boot
>  scenarios like booting from HTTP or even HTTPS, you need something else
>  (i.e. maybe grub is the better option, indeed).
> >>>
> >>> That makes me wonder what that means for s390: We're inheriting
> >>> libnet's limitations, but we don't have grub -- do we need to come up
> >>> with something different? Or improve libnet?
> >>
> >> I don't think that it makes sense to re-invent the wheel yet another
> >> time and write yet another TCP implementation (which is likely quite a
> >> bit of work, too, especially if you also want to do secure HTTPS in the
> >> end). So yes, in the long run (as soon as somebody seriously asks for
> >> HTTP booting on s390x) we need something different here.
> >>
> >> Now looking at our standard s390x bootloader zipl - this has been giving
> >> us a headache a couple of times in the past, too (from a distro point of
> >> view since s390x is the only major platform left that does not use grub,
> >> but also from a s390-ccw bios point of view, see e.g.
> >> https://lists.gnu.org/archive/html/qemu-devel/2019-12/msg03046.html and
> >> related discussions).
> >>
> >> So IMHO the s390x world should move towards grub2, too. We could e.g.
> >> link it initially into the s390-ccw bios bios ... and if that works out
> >> well, later also use it as normal bootloader instead of zipl (not sure
> >> if that works in all cases, though, IIRC there were some size
> >> constraints and stuff like that).
> > 
> > petitboot would be another reasonable thing to consider here.  Since
> > it's Linux based, you have all the drivers you have there.  It's not
> > quite grub, but it does at least parse the same configuration files.
> > 
> > You do need kexec() of course, I don't know if you have that already
> > for s390 or not.
> 
> AFAIK we have kexec on s390. So yes, petitboot would be another option
> for replacing the s390-ccw bios. But when it comes to LPARs and z/VMs, I
> don't think it's really feasible to replace the zipl bootloader there
> with petitboot, so in that case grub2 still sounds like the better
> option to me.

Actually, between that and Paolo's suggestions, I thought of another
idea that could be helpful for both s390 and power.  Could we load
non-kexec() things (legacy kernels, non-Linux OSes) from Petitboot by
having it kexec() into a shim mini-kernel that just sets up the boot
environment for the other thing.

What I'm imagining is that petitboot loads everything that will be
needed for the other OS into RAM - probably as (or part of) the
"initrd" image.  That means the shim doesn't need to have drivers or
a network stack to load that in.  It just needs to construct
environment and jump into the real kernel.

-- 
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: VW ELF loader

On Thu, Feb 06, 2020 at 09:27:01AM +0100, Paolo Bonzini wrote:
> On 05/02/20 07:06, David Gibson wrote:
> > On Tue, Feb 04, 2020 at 12:26:32AM +0100, Paolo Bonzini wrote:
> >> Il mar 4 feb 2020, 00:20 Alexey Kardashevskiy  ha scritto:
> >>> Speaking seriously, what would I put into the guest?
> >>
> >> Only things that would be considered drivers. Ignore the partitions issue
> >> for now so that you can just pass the device tree services to QEMU with
> >> hypercalls.
> > 
> > Urgh... first, I don't really see how you'd do that.  OF's whole
> > device model is based around the device tree.  So implementing OF
> > driver interactions would require the firmware to do a bunch of
> > internal hypercalls to do all the DT stuff, which brings us back to a
> > much more complex and active interface between firmware and hypervisor
> > than we really want.
> 
> I'm really sorry if what I am saying is stupid; but I was thinking of a
> firmware entrypoint like
> 
>   if (op == "read" || op == "write")
>   do_driver_stuff(op);
>   else
>   hypercall();

Um... I'm not really clear on where you're imagining this going.  In
the OF model, device operations are done by "opening" a device tree
node then executing methods on it, so you can't really even get to
this point without a bunch of DT stuff.

> This is not even close to pseudocode, but hopefully enough to give the
> idea.  Perhaps what I don't understand is why you can't start the
> firmware with r3 pointing to the device tree, and stash it for when you
> leave control to GRUB.

Again, I'm not even really sure what you mean by this.  We already
enter SLOF with r3 pointing to a device tree.  I'm not sure what
stashing it would accomplish.  GRUB as it stands expects an OF style
entry point though, not a flat tree style entry point.

Are you suggesting rewriting it to run in that environment?  That
might be an option, but it's certainly not easy.  We'd have to write
"native" grub drivers for all the devices we care about, rather than
calling into OF for them.  Maybe there's some x86 code we could
already use here?  I don't know how much GRUB relies on the BIOS or
UEFI for device access on PC.

> Or to put it another way, what petitboot does
> that you cannot do in your own firmware.

So, part of the confusion is that there are two things we're
considering here and it's not really clear yet how much they overlap.

1) Is using petitboot as our bootloader.  That gives us basically
every driver, network protocol and tool we could ever want.  However,
it gets to the next stage via kexec(), so it can only support OSes
which are kexec()able - i.e. Linux.  This is mostly speculation at
this point.

2) Having a way of booting existing clients - i.e. those that expect
OF-style entry conditions - but without having to maintain a blob of
Forth.  The "kill slof" patches are a concrete, if limited, attempt at
this.

> > Second, drivers are kind of where we'd get the most benefit by putting
> > them in qemu: from qemu we can just talk to the device backends
> > directly so we don't need to re-abstract the differences between
> > different device models of the same type.
> 
> Of course, but drivers are easy to write.

I'm not really sure I agree with you there.

> Not as easy as s390 probably
> because you'd have to link in libfdt and so on, but between
> kvm-unit-tests and s390-ccw there's quite a bit of code can be reused.

Maybe, but I'm not really sure where you're picturing it fitting in.

> >> You can generalize and reuse the s390 code. All you have to write is the
> >> PCI scan and virtio-pci setup.
> > 
> > If we assume virtio only.
> 
> Do you actually need something else?

Well.. that's an interesting question.

> The TTY can use the simple
> getchar/putchar hypercalls,

Yes... though if people attach a graphical console they might be
pretty surprised that they don't get anything on there.  Supporting
that means adding vga, which adds substantial complexity (especially
since text mode isn't really a thing for a vga on a POWER machine).

> and sPAPR-vSCSI clients can keep using SLOF.

We can possibly ignore the spapr virtual devices.  They seemed like
they'd be important for people transitioning from guests under
PowerVM, but honestly I'm not sure they've ever been used much.

We do support emulated (or passthrough) PCI devices.  I don't know if
they're common enough that we need boot support for them.  Netboot
from a vfio network adaptor might be something people want.

USB storage is also a fairly likely candidate, and that would add a
*lot* of extra complexity, since we'd need both the HCD and storage
drivers.

-- 
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: VW ELF loader

On Fri, Feb 07, 2020 at 12:45:20AM +0100, Paolo Bonzini wrote:
> On 07/02/20 00:17, Alexey Kardashevskiy wrote:
> > This is a lot and what is exactly the benefit? My alternative does not
> > need drivers at all.
> 
> Anything you put in the host is potential attack surface.

Ok, it is attack surface you're concerned about.  That wasn't totally
clear before this point.

> Plus, you're
> not doing a different thing than anyone else and as you've found out it
> may be easy for block device but not for everything else.

Uh.. was that supposed to be "we *are* doing a different thing than
anyone else"?

> Every platform that QEMU supports is just using a firmware to do
> firmware things; it can be U-Boot, EDK-2, SLOF, SeaBIOS, qboot, with
> varying level of complexity.  Some are doing -kernel in QEMU rather than
> firmware, but that's where things end.

Well, yeah, but AIUI those platforms actually have a defined hardware
environment on which the firmware is running.  For PAPR we don't, we
*only* have a specification for the "hardware"+"firmware" environment
as seen by the OS together.

-- 
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

[PATCH v3 1/5] target/riscv: add vector unit stride load and store instructions

Vector unit-stride operations access elements stored contiguously in memory
starting from the base effective address.

The Zvlsseg expands some vector load/store segment instructions, which move
multiple contiguous fields in memory to and from consecutively numbered
vector register

Signed-off-by: LIU Zhiwei 
---
 target/riscv/helper.h   |  70 
 target/riscv/insn32.decode  |  17 +
 target/riscv/insn_trans/trans_rvv.inc.c | 294 
 target/riscv/translate.c|   2 +
 target/riscv/vector_helper.c| 438 
 5 files changed, 821 insertions(+)

diff --git a/target/riscv/helper.h b/target/riscv/helper.h
index 3c28c7e407..74c483ef9e 100644
--- a/target/riscv/helper.h
+++ b/target/riscv/helper.h
@@ -78,3 +78,73 @@ DEF_HELPER_1(tlb_flush, void, env)
 #endif
 /* Vector functions */
 DEF_HELPER_3(vsetvl, tl, env, tl, tl)
+DEF_HELPER_5(vlb_v_b, void, ptr, tl, ptr, env, i32)
+DEF_HELPER_5(vlb_v_b_mask, void, ptr, tl, ptr, env, i32)
+DEF_HELPER_5(vlb_v_h, void, ptr, tl, ptr, env, i32)
+DEF_HELPER_5(vlb_v_h_mask, void, ptr, tl, ptr, env, i32)
+DEF_HELPER_5(vlb_v_w, void, ptr, tl, ptr, env, i32)
+DEF_HELPER_5(vlb_v_w_mask, void, ptr, tl, ptr, env, i32)
+DEF_HELPER_5(vlb_v_d, void, ptr, tl, ptr, env, i32)
+DEF_HELPER_5(vlb_v_d_mask, void, ptr, tl, ptr, env, i32)
+DEF_HELPER_5(vlh_v_h, void, ptr, tl, ptr, env, i32)
+DEF_HELPER_5(vlh_v_h_mask, void, ptr, tl, ptr, env, i32)
+DEF_HELPER_5(vlh_v_w, void, ptr, tl, ptr, env, i32)
+DEF_HELPER_5(vlh_v_w_mask, void, ptr, tl, ptr, env, i32)
+DEF_HELPER_5(vlh_v_d, void, ptr, tl, ptr, env, i32)
+DEF_HELPER_5(vlh_v_d_mask, void, ptr, tl, ptr, env, i32)
+DEF_HELPER_5(vlw_v_w, void, ptr, tl, ptr, env, i32)
+DEF_HELPER_5(vlw_v_w_mask, void, ptr, tl, ptr, env, i32)
+DEF_HELPER_5(vlw_v_d, void, ptr, tl, ptr, env, i32)
+DEF_HELPER_5(vlw_v_d_mask, void, ptr, tl, ptr, env, i32)
+DEF_HELPER_5(vle_v_b, void, ptr, tl, ptr, env, i32)
+DEF_HELPER_5(vle_v_b_mask, void, ptr, tl, ptr, env, i32)
+DEF_HELPER_5(vle_v_h, void, ptr, tl, ptr, env, i32)
+DEF_HELPER_5(vle_v_h_mask, void, ptr, tl, ptr, env, i32)
+DEF_HELPER_5(vle_v_w, void, ptr, tl, ptr, env, i32)
+DEF_HELPER_5(vle_v_w_mask, void, ptr, tl, ptr, env, i32)
+DEF_HELPER_5(vle_v_d, void, ptr, tl, ptr, env, i32)
+DEF_HELPER_5(vle_v_d_mask, void, ptr, tl, ptr, env, i32)
+DEF_HELPER_5(vlbu_v_b, void, ptr, tl, ptr, env, i32)
+DEF_HELPER_5(vlbu_v_b_mask, void, ptr, tl, ptr, env, i32)
+DEF_HELPER_5(vlbu_v_h, void, ptr, tl, ptr, env, i32)
+DEF_HELPER_5(vlbu_v_h_mask, void, ptr, tl, ptr, env, i32)
+DEF_HELPER_5(vlbu_v_w, void, ptr, tl, ptr, env, i32)
+DEF_HELPER_5(vlbu_v_w_mask, void, ptr, tl, ptr, env, i32)
+DEF_HELPER_5(vlbu_v_d, void, ptr, tl, ptr, env, i32)
+DEF_HELPER_5(vlbu_v_d_mask, void, ptr, tl, ptr, env, i32)
+DEF_HELPER_5(vlhu_v_h, void, ptr, tl, ptr, env, i32)
+DEF_HELPER_5(vlhu_v_h_mask, void, ptr, tl, ptr, env, i32)
+DEF_HELPER_5(vlhu_v_w, void, ptr, tl, ptr, env, i32)
+DEF_HELPER_5(vlhu_v_w_mask, void, ptr, tl, ptr, env, i32)
+DEF_HELPER_5(vlhu_v_d, void, ptr, tl, ptr, env, i32)
+DEF_HELPER_5(vlhu_v_d_mask, void, ptr, tl, ptr, env, i32)
+DEF_HELPER_5(vlwu_v_w, void, ptr, tl, ptr, env, i32)
+DEF_HELPER_5(vlwu_v_w_mask, void, ptr, tl, ptr, env, i32)
+DEF_HELPER_5(vlwu_v_d, void, ptr, tl, ptr, env, i32)
+DEF_HELPER_5(vlwu_v_d_mask, void, ptr, tl, ptr, env, i32)
+DEF_HELPER_5(vsb_v_b, void, ptr, tl, ptr, env, i32)
+DEF_HELPER_5(vsb_v_b_mask, void, ptr, tl, ptr, env, i32)
+DEF_HELPER_5(vsb_v_h, void, ptr, tl, ptr, env, i32)
+DEF_HELPER_5(vsb_v_h_mask, void, ptr, tl, ptr, env, i32)
+DEF_HELPER_5(vsb_v_w, void, ptr, tl, ptr, env, i32)
+DEF_HELPER_5(vsb_v_w_mask, void, ptr, tl, ptr, env, i32)
+DEF_HELPER_5(vsb_v_d, void, ptr, tl, ptr, env, i32)
+DEF_HELPER_5(vsb_v_d_mask, void, ptr, tl, ptr, env, i32)
+DEF_HELPER_5(vsh_v_h, void, ptr, tl, ptr, env, i32)
+DEF_HELPER_5(vsh_v_h_mask, void, ptr, tl, ptr, env, i32)
+DEF_HELPER_5(vsh_v_w, void, ptr, tl, ptr, env, i32)
+DEF_HELPER_5(vsh_v_w_mask, void, ptr, tl, ptr, env, i32)
+DEF_HELPER_5(vsh_v_d, void, ptr, tl, ptr, env, i32)
+DEF_HELPER_5(vsh_v_d_mask, void, ptr, tl, ptr, env, i32)
+DEF_HELPER_5(vsw_v_w, void, ptr, tl, ptr, env, i32)
+DEF_HELPER_5(vsw_v_w_mask, void, ptr, tl, ptr, env, i32)
+DEF_HELPER_5(vsw_v_d, void, ptr, tl, ptr, env, i32)
+DEF_HELPER_5(vsw_v_d_mask, void, ptr, tl, ptr, env, i32)
+DEF_HELPER_5(vse_v_b, void, ptr, tl, ptr, env, i32)
+DEF_HELPER_5(vse_v_b_mask, void, ptr, tl, ptr, env, i32)
+DEF_HELPER_5(vse_v_h, void, ptr, tl, ptr, env, i32)
+DEF_HELPER_5(vse_v_h_mask, void, ptr, tl, ptr, env, i32)
+DEF_HELPER_5(vse_v_w, void, ptr, tl, ptr, env, i32)
+DEF_HELPER_5(vse_v_w_mask, void, ptr, tl, ptr, env, i32)
+DEF_HELPER_5(vse_v_d, void, ptr, tl, ptr, env, i32)
+DEF_HELPER_5(vse_v_d_mask, void, ptr, tl, ptr, env, i32)
diff --git a/target/riscv/insn32.decode b/target/riscv/insn32.decode
index 5dc009c3cd..dad3ed91c7 100644
--- a/target/riscv/insn32.decode
+++ b/target/riscv/insn32.decode
@@ -43,6

[PATCH v3 2/5] target/riscv: add vector stride load and store instructions

Vector strided operations access the first memory element at the base address,
and then access subsequent elements at address increments given by the byte
offset contained in the x register specified by rs2.

Signed-off-by: LIU Zhiwei 
---
 target/riscv/helper.h   |  35 +
 target/riscv/insn32.decode  |  14 ++
 target/riscv/insn_trans/trans_rvv.inc.c | 138 +++
 target/riscv/vector_helper.c| 169 
 4 files changed, 356 insertions(+)

diff --git a/target/riscv/helper.h b/target/riscv/helper.h
index 74c483ef9e..19c1bfc317 100644
--- a/target/riscv/helper.h
+++ b/target/riscv/helper.h
@@ -148,3 +148,38 @@ DEF_HELPER_5(vse_v_w, void, ptr, tl, ptr, env, i32)
 DEF_HELPER_5(vse_v_w_mask, void, ptr, tl, ptr, env, i32)
 DEF_HELPER_5(vse_v_d, void, ptr, tl, ptr, env, i32)
 DEF_HELPER_5(vse_v_d_mask, void, ptr, tl, ptr, env, i32)
+DEF_HELPER_6(vlsb_v_b_mask, void, ptr, tl, tl, ptr, env, i32)
+DEF_HELPER_6(vlsb_v_h_mask, void, ptr, tl, tl, ptr, env, i32)
+DEF_HELPER_6(vlsb_v_w_mask, void, ptr, tl, tl, ptr, env, i32)
+DEF_HELPER_6(vlsb_v_d_mask, void, ptr, tl, tl, ptr, env, i32)
+DEF_HELPER_6(vlsh_v_h_mask, void, ptr, tl, tl, ptr, env, i32)
+DEF_HELPER_6(vlsh_v_w_mask, void, ptr, tl, tl, ptr, env, i32)
+DEF_HELPER_6(vlsh_v_d_mask, void, ptr, tl, tl, ptr, env, i32)
+DEF_HELPER_6(vlsw_v_w_mask, void, ptr, tl, tl, ptr, env, i32)
+DEF_HELPER_6(vlsw_v_d_mask, void, ptr, tl, tl, ptr, env, i32)
+DEF_HELPER_6(vlse_v_b_mask, void, ptr, tl, tl, ptr, env, i32)
+DEF_HELPER_6(vlse_v_h_mask, void, ptr, tl, tl, ptr, env, i32)
+DEF_HELPER_6(vlse_v_w_mask, void, ptr, tl, tl, ptr, env, i32)
+DEF_HELPER_6(vlse_v_d_mask, void, ptr, tl, tl, ptr, env, i32)
+DEF_HELPER_6(vlsbu_v_b_mask, void, ptr, tl, tl, ptr, env, i32)
+DEF_HELPER_6(vlsbu_v_h_mask, void, ptr, tl, tl, ptr, env, i32)
+DEF_HELPER_6(vlsbu_v_w_mask, void, ptr, tl, tl, ptr, env, i32)
+DEF_HELPER_6(vlsbu_v_d_mask, void, ptr, tl, tl, ptr, env, i32)
+DEF_HELPER_6(vlshu_v_h_mask, void, ptr, tl, tl, ptr, env, i32)
+DEF_HELPER_6(vlshu_v_w_mask, void, ptr, tl, tl, ptr, env, i32)
+DEF_HELPER_6(vlshu_v_d_mask, void, ptr, tl, tl, ptr, env, i32)
+DEF_HELPER_6(vlswu_v_w_mask, void, ptr, tl, tl, ptr, env, i32)
+DEF_HELPER_6(vlswu_v_d_mask, void, ptr, tl, tl, ptr, env, i32)
+DEF_HELPER_6(vssb_v_b_mask, void, ptr, tl, tl, ptr, env, i32)
+DEF_HELPER_6(vssb_v_h_mask, void, ptr, tl, tl, ptr, env, i32)
+DEF_HELPER_6(vssb_v_w_mask, void, ptr, tl, tl, ptr, env, i32)
+DEF_HELPER_6(vssb_v_d_mask, void, ptr, tl, tl, ptr, env, i32)
+DEF_HELPER_6(vssh_v_h_mask, void, ptr, tl, tl, ptr, env, i32)
+DEF_HELPER_6(vssh_v_w_mask, void, ptr, tl, tl, ptr, env, i32)
+DEF_HELPER_6(vssh_v_d_mask, void, ptr, tl, tl, ptr, env, i32)
+DEF_HELPER_6(vssw_v_w_mask, void, ptr, tl, tl, ptr, env, i32)
+DEF_HELPER_6(vssw_v_d_mask, void, ptr, tl, tl, ptr, env, i32)
+DEF_HELPER_6(vsse_v_b_mask, void, ptr, tl, tl, ptr, env, i32)
+DEF_HELPER_6(vsse_v_h_mask, void, ptr, tl, tl, ptr, env, i32)
+DEF_HELPER_6(vsse_v_w_mask, void, ptr, tl, tl, ptr, env, i32)
+DEF_HELPER_6(vsse_v_d_mask, void, ptr, tl, tl, ptr, env, i32)
diff --git a/target/riscv/insn32.decode b/target/riscv/insn32.decode
index dad3ed91c7..2f2d3d13b3 100644
--- a/target/riscv/insn32.decode
+++ b/target/riscv/insn32.decode
@@ -44,6 +44,7 @@
  shamt rs1 rd
 aq rl rs2 rs1 rd
 vm rd rs1 nf
+ vm rd rs1 rs2 nf
 
 # Formats 32:
 @r   ...   . . ... . ... %rs2 %rs1 
%rd
@@ -64,6 +65,7 @@
 @r2_rm   ...   . . ... . ... %rs1 %rm %rd
 @r2  ...   . . ... . ... %rs1 %rd
 @r2_nfvm nf:3 ... vm:1 . . ... . ...  %rs1 %rd
+@r_nfvm  nf:3 ... vm:1 . . ... . ...  %rs2 %rs1 %rd
 @r2_zimm . zimm:11  . ... . ... %rs1 %rd
 
 @sfence_vma ... . .   ... . ... %rs2 %rs1
@@ -222,6 +224,18 @@ vsh_v  ... 000 . 0 . 101 . 0100111 @r2_nfvm
 vsw_v  ... 000 . 0 . 110 . 0100111 @r2_nfvm
 vse_v  ... 000 . 0 . 111 . 0100111 @r2_nfvm
 
+vlsb_v ... 110 . . . 000 . 111 @r_nfvm
+vlsh_v ... 110 . . . 101 . 111 @r_nfvm
+vlsw_v ... 110 . . . 110 . 111 @r_nfvm
+vlse_v ... 010 . . . 111 . 111 @r_nfvm
+vlsbu_v... 010 . . . 000 . 111 @r_nfvm
+vlshu_v... 010 . . . 101 . 111 @r_nfvm
+vlswu_v... 010 . . . 110 . 111 @r_nfvm
+vssb_v ... 010 . . . 000 . 0100111 @r_nfvm
+vssh_v ... 010 . . . 101 . 0100111 @r_nfvm
+vssw_v ... 010 . . . 110 . 0100111 @r_nfvm
+vsse_v ... 010 . . . 111 . 0100111 @r_nfvm
+
 # *** new major opcode OP-V ***
 vsetvli 0 ... . 111 . 1010111  @r2_zimm
 vsetvl  100 . . 111 . 1010111  @r
diff --git a/target/riscv/insn_trans/trans_rvv.inc.c

[PATCH v3 4/5] target/riscv: add fault-only-first unit stride load

The unit-stride fault-only-fault load instructions are used to
vectorize loops with data-dependent exit conditions(while loops).
These instructions execute as a regular load except that they
will only take a trap on element 0.

Signed-off-by: LIU Zhiwei 
---
 target/riscv/helper.h   |  22 
 target/riscv/insn32.decode  |   7 ++
 target/riscv/insn_trans/trans_rvv.inc.c |  88 +++
 target/riscv/vector_helper.c| 138 
 4 files changed, 255 insertions(+)

diff --git a/target/riscv/helper.h b/target/riscv/helper.h
index 5ebd3d6ccd..893dfc0fb8 100644
--- a/target/riscv/helper.h
+++ b/target/riscv/helper.h
@@ -218,3 +218,25 @@ DEF_HELPER_6(vsxe_v_b_mask, void, ptr, tl, ptr, ptr, env, 
i32)
 DEF_HELPER_6(vsxe_v_h_mask, void, ptr, tl, ptr, ptr, env, i32)
 DEF_HELPER_6(vsxe_v_w_mask, void, ptr, tl, ptr, ptr, env, i32)
 DEF_HELPER_6(vsxe_v_d_mask, void, ptr, tl, ptr, ptr, env, i32)
+DEF_HELPER_5(vlbff_v_b_mask, void, ptr, tl, ptr, env, i32)
+DEF_HELPER_5(vlbff_v_h_mask, void, ptr, tl, ptr, env, i32)
+DEF_HELPER_5(vlbff_v_w_mask, void, ptr, tl, ptr, env, i32)
+DEF_HELPER_5(vlbff_v_d_mask, void, ptr, tl, ptr, env, i32)
+DEF_HELPER_5(vlhff_v_h_mask, void, ptr, tl, ptr, env, i32)
+DEF_HELPER_5(vlhff_v_w_mask, void, ptr, tl, ptr, env, i32)
+DEF_HELPER_5(vlhff_v_d_mask, void, ptr, tl, ptr, env, i32)
+DEF_HELPER_5(vlwff_v_w_mask, void, ptr, tl, ptr, env, i32)
+DEF_HELPER_5(vlwff_v_d_mask, void, ptr, tl, ptr, env, i32)
+DEF_HELPER_5(vleff_v_b_mask, void, ptr, tl, ptr, env, i32)
+DEF_HELPER_5(vleff_v_h_mask, void, ptr, tl, ptr, env, i32)
+DEF_HELPER_5(vleff_v_w_mask, void, ptr, tl, ptr, env, i32)
+DEF_HELPER_5(vleff_v_d_mask, void, ptr, tl, ptr, env, i32)
+DEF_HELPER_5(vlbuff_v_b_mask, void, ptr, tl, ptr, env, i32)
+DEF_HELPER_5(vlbuff_v_h_mask, void, ptr, tl, ptr, env, i32)
+DEF_HELPER_5(vlbuff_v_w_mask, void, ptr, tl, ptr, env, i32)
+DEF_HELPER_5(vlbuff_v_d_mask, void, ptr, tl, ptr, env, i32)
+DEF_HELPER_5(vlhuff_v_h_mask, void, ptr, tl, ptr, env, i32)
+DEF_HELPER_5(vlhuff_v_w_mask, void, ptr, tl, ptr, env, i32)
+DEF_HELPER_5(vlhuff_v_d_mask, void, ptr, tl, ptr, env, i32)
+DEF_HELPER_5(vlwuff_v_w_mask, void, ptr, tl, ptr, env, i32)
+DEF_HELPER_5(vlwuff_v_d_mask, void, ptr, tl, ptr, env, i32)
diff --git a/target/riscv/insn32.decode b/target/riscv/insn32.decode
index 6a363a6b7e..973ac63fda 100644
--- a/target/riscv/insn32.decode
+++ b/target/riscv/insn32.decode
@@ -219,6 +219,13 @@ vle_v  ... 000 . 0 . 111 . 111 @r2_nfvm
 vlbu_v ... 000 . 0 . 000 . 111 @r2_nfvm
 vlhu_v ... 000 . 0 . 101 . 111 @r2_nfvm
 vlwu_v ... 000 . 0 . 110 . 111 @r2_nfvm
+vlbff_v... 100 . 1 . 000 . 111 @r2_nfvm
+vlhff_v... 100 . 1 . 101 . 111 @r2_nfvm
+vlwff_v... 100 . 1 . 110 . 111 @r2_nfvm
+vleff_v... 000 . 1 . 111 . 111 @r2_nfvm
+vlbuff_v   ... 000 . 1 . 000 . 111 @r2_nfvm
+vlhuff_v   ... 000 . 1 . 101 . 111 @r2_nfvm
+vlwuff_v   ... 000 . 1 . 110 . 111 @r2_nfvm
 vsb_v  ... 000 . 0 . 000 . 0100111 @r2_nfvm
 vsh_v  ... 000 . 0 . 101 . 0100111 @r2_nfvm
 vsw_v  ... 000 . 0 . 110 . 0100111 @r2_nfvm
diff --git a/target/riscv/insn_trans/trans_rvv.inc.c 
b/target/riscv/insn_trans/trans_rvv.inc.c
index 13033b3906..66caa16d18 100644
--- a/target/riscv/insn_trans/trans_rvv.inc.c
+++ b/target/riscv/insn_trans/trans_rvv.inc.c
@@ -663,3 +663,91 @@ static bool trans_vsuxe_v(DisasContext *s, arg_rnfvm* a)
 {
 return trans_vsxe_v(s, a);
 }
+
+/* unit stride fault-only-first load */
+typedef void gen_helper_vext_ldff(TCGv_ptr, TCGv, TCGv_ptr,
+TCGv_env, TCGv_i32);
+
+static bool do_vext_ldff_trans(uint32_t vd, uint32_t rs1, uint32_t data,
+gen_helper_vext_ldff *fn, DisasContext *s)
+{
+TCGv_ptr dest, mask;
+TCGv base;
+TCGv_i32 desc;
+
+dest = tcg_temp_new_ptr();
+mask = tcg_temp_new_ptr();
+base = tcg_temp_new();
+desc = tcg_const_i32(simd_desc(0, maxsz_part1(s->maxsz), data));
+
+gen_get_gpr(base, rs1);
+tcg_gen_addi_ptr(dest, cpu_env, vreg_ofs(s, vd));
+tcg_gen_addi_ptr(mask, cpu_env, vreg_ofs(s, 0));
+
+fn(dest, base, mask, cpu_env, desc);
+
+tcg_temp_free_ptr(dest);
+tcg_temp_free_ptr(mask);
+tcg_temp_free(base);
+tcg_temp_free_i32(desc);
+return true;
+}
+
+static bool vext_ldff_trans(DisasContext *s, arg_r2nfvm *a, uint8_t seq)
+{
+uint8_t nf = a->nf + 1;
+uint32_t data = s->mlen | (a->vm << 8) | (maxsz_part2(s->maxsz) << 9)
+| (nf << 12);
+gen_helper_vext_ldff *fn;
+static gen_helper_vext_ldff * const fns[7][4] = {
+/* masked unit stride fault-only-first load */
+{ gen_helper_vlbff_v_b_mask,  gen_helper_vlbff_v_h_mask,
+  gen_helper_vlbff_v_w_mask,  gen_helper_vlbff_v_d_mask },
+{ NULL,

[PATCH v3 5/5] target/riscv: add vector amo operations

Vector AMOs operate as if aq and rl bits were zero on each element
with regard to ordering relative to other instructions in the same hart.
Vector AMOs provide no ordering guarantee between element operations
in the same vector AMO instruction

Signed-off-by: LIU Zhiwei 
---
 target/riscv/helper.h   |  57 +
 target/riscv/insn32-64.decode   |  11 +
 target/riscv/insn32.decode  |  13 ++
 target/riscv/insn_trans/trans_rvv.inc.c | 167 ++
 target/riscv/vector_helper.c| 292 
 5 files changed, 540 insertions(+)

diff --git a/target/riscv/helper.h b/target/riscv/helper.h
index 893dfc0fb8..3624a20262 100644
--- a/target/riscv/helper.h
+++ b/target/riscv/helper.h
@@ -240,3 +240,60 @@ DEF_HELPER_5(vlhuff_v_w_mask, void, ptr, tl, ptr, env, i32)
 DEF_HELPER_5(vlhuff_v_d_mask, void, ptr, tl, ptr, env, i32)
 DEF_HELPER_5(vlwuff_v_w_mask, void, ptr, tl, ptr, env, i32)
 DEF_HELPER_5(vlwuff_v_d_mask, void, ptr, tl, ptr, env, i32)
+#ifdef TARGET_RISCV64
+DEF_HELPER_6(vamoswapw_v_d_a_mask, void, ptr, tl, ptr, ptr, env, i32)
+DEF_HELPER_6(vamoswapd_v_d_a_mask, void, ptr, tl, ptr, ptr, env, i32)
+DEF_HELPER_6(vamoaddw_v_d_a_mask,  void, ptr, tl, ptr, ptr, env, i32)
+DEF_HELPER_6(vamoaddd_v_d_a_mask,  void, ptr, tl, ptr, ptr, env, i32)
+DEF_HELPER_6(vamoxorw_v_d_a_mask,  void, ptr, tl, ptr, ptr, env, i32)
+DEF_HELPER_6(vamoxord_v_d_a_mask,  void, ptr, tl, ptr, ptr, env, i32)
+DEF_HELPER_6(vamoandw_v_d_a_mask,  void, ptr, tl, ptr, ptr, env, i32)
+DEF_HELPER_6(vamoandd_v_d_a_mask,  void, ptr, tl, ptr, ptr, env, i32)
+DEF_HELPER_6(vamoorw_v_d_a_mask,   void, ptr, tl, ptr, ptr, env, i32)
+DEF_HELPER_6(vamoord_v_d_a_mask,   void, ptr, tl, ptr, ptr, env, i32)
+DEF_HELPER_6(vamominw_v_d_a_mask,  void, ptr, tl, ptr, ptr, env, i32)
+DEF_HELPER_6(vamomind_v_d_a_mask,  void, ptr, tl, ptr, ptr, env, i32)
+DEF_HELPER_6(vamomaxw_v_d_a_mask,  void, ptr, tl, ptr, ptr, env, i32)
+DEF_HELPER_6(vamomaxd_v_d_a_mask,  void, ptr, tl, ptr, ptr, env, i32)
+DEF_HELPER_6(vamominuw_v_d_a_mask, void, ptr, tl, ptr, ptr, env, i32)
+DEF_HELPER_6(vamominud_v_d_a_mask, void, ptr, tl, ptr, ptr, env, i32)
+DEF_HELPER_6(vamomaxuw_v_d_a_mask, void, ptr, tl, ptr, ptr, env, i32)
+DEF_HELPER_6(vamomaxud_v_d_a_mask, void, ptr, tl, ptr, ptr, env, i32)
+DEF_HELPER_6(vamoswapw_v_d_mask, void, ptr, tl, ptr, ptr, env, i32)
+DEF_HELPER_6(vamoswapd_v_d_mask, void, ptr, tl, ptr, ptr, env, i32)
+DEF_HELPER_6(vamoaddw_v_d_mask,  void, ptr, tl, ptr, ptr, env, i32)
+DEF_HELPER_6(vamoaddd_v_d_mask,  void, ptr, tl, ptr, ptr, env, i32)
+DEF_HELPER_6(vamoxorw_v_d_mask,  void, ptr, tl, ptr, ptr, env, i32)
+DEF_HELPER_6(vamoxord_v_d_mask,  void, ptr, tl, ptr, ptr, env, i32)
+DEF_HELPER_6(vamoandw_v_d_mask,  void, ptr, tl, ptr, ptr, env, i32)
+DEF_HELPER_6(vamoandd_v_d_mask,  void, ptr, tl, ptr, ptr, env, i32)
+DEF_HELPER_6(vamoorw_v_d_mask,   void, ptr, tl, ptr, ptr, env, i32)
+DEF_HELPER_6(vamoord_v_d_mask,   void, ptr, tl, ptr, ptr, env, i32)
+DEF_HELPER_6(vamominw_v_d_mask,  void, ptr, tl, ptr, ptr, env, i32)
+DEF_HELPER_6(vamomind_v_d_mask,  void, ptr, tl, ptr, ptr, env, i32)
+DEF_HELPER_6(vamomaxw_v_d_mask,  void, ptr, tl, ptr, ptr, env, i32)
+DEF_HELPER_6(vamomaxd_v_d_mask,  void, ptr, tl, ptr, ptr, env, i32)
+DEF_HELPER_6(vamominuw_v_d_mask, void, ptr, tl, ptr, ptr, env, i32)
+DEF_HELPER_6(vamominud_v_d_mask, void, ptr, tl, ptr, ptr, env, i32)
+DEF_HELPER_6(vamomaxuw_v_d_mask, void, ptr, tl, ptr, ptr, env, i32)
+DEF_HELPER_6(vamomaxud_v_d_mask, void, ptr, tl, ptr, ptr, env, i32)
+#endif
+DEF_HELPER_6(vamoswapw_v_w_a_mask, void, ptr, tl, ptr, ptr, env, i32)
+DEF_HELPER_6(vamoaddw_v_w_a_mask,  void, ptr, tl, ptr, ptr, env, i32)
+DEF_HELPER_6(vamoxorw_v_w_a_mask,  void, ptr, tl, ptr, ptr, env, i32)
+DEF_HELPER_6(vamoandw_v_w_a_mask,  void, ptr, tl, ptr, ptr, env, i32)
+DEF_HELPER_6(vamoorw_v_w_a_mask,   void, ptr, tl, ptr, ptr, env, i32)
+DEF_HELPER_6(vamominw_v_w_a_mask,  void, ptr, tl, ptr, ptr, env, i32)
+DEF_HELPER_6(vamomaxw_v_w_a_mask,  void, ptr, tl, ptr, ptr, env, i32)
+DEF_HELPER_6(vamominuw_v_w_a_mask, void, ptr, tl, ptr, ptr, env, i32)
+DEF_HELPER_6(vamomaxuw_v_w_a_mask, void, ptr, tl, ptr, ptr, env, i32)
+DEF_HELPER_6(vamoswapw_v_w_mask, void, ptr, tl, ptr, ptr, env, i32)
+DEF_HELPER_6(vamoaddw_v_w_mask,  void, ptr, tl, ptr, ptr, env, i32)
+DEF_HELPER_6(vamoxorw_v_w_mask,  void, ptr, tl, ptr, ptr, env, i32)
+DEF_HELPER_6(vamoandw_v_w_mask,  void, ptr, tl, ptr, ptr, env, i32)
+DEF_HELPER_6(vamoorw_v_w_mask,   void, ptr, tl, ptr, ptr, env, i32)
+DEF_HELPER_6(vamominw_v_w_mask,  void, ptr, tl, ptr, ptr, env, i32)
+DEF_HELPER_6(vamomaxw_v_w_mask,  void, ptr, tl, ptr, ptr, env, i32)
+DEF_HELPER_6(vamominuw_v_w_mask, void, ptr, tl, ptr, ptr, env, i32)
+DEF_HELPER_6(vamomaxuw_v_w_mask, void, ptr, tl, ptr, ptr, env, i32)
+
diff --git a/target/riscv/insn32-64.decode b/target/riscv/insn32-64.decode
index 380bf791bc..86153d93fa 100644
--- a/target/riscv/insn32-64.decode
+++

[PATCH v3 0/5] target/riscv: support vector extension part 2

This is the second part of v3 patchset. This changelog of v3 is only coverd
the part2.

Features:
  * support specification riscv-v-spec-0.7.1.
  * support basic vector extension.
  * support Zvlsseg.
  * support Zvamo.
  * not support Zvediv as it is changing.
  * fixed SLEN 128bit.
  * element width support 8bit, 16bit, 32bit, 64bit.

Changelog:
v3
  * move check code from execution time to translation time.
  * probe pages before real load or store access.
  * use probe_page_check for no-fault operations in linux user mode.
  * add atomic and noatomic operation for vector amo instructions.
V2
  * use float16_compare{_quiet}
  * only use GETPC() in outer most helper
  * add ctx.ext_v Property

LIU Zhiwei (5):
  target/riscv: add vector unit stride load and store instructions
  target/riscv: add vector stride load and store instructions
  target/riscv: add vector index load and store instructions
  target/riscv: add fault-only-first unit stride load
  target/riscv: add vector amo operations

 target/riscv/helper.h   |  219 
 target/riscv/insn32-64.decode   |   11 +
 target/riscv/insn32.decode  |   67 ++
 target/riscv/insn_trans/trans_rvv.inc.c |  851 +++
 target/riscv/translate.c|2 +
 target/riscv/vector_helper.c| 1251 +++
 6 files changed, 2401 insertions(+)

-- 
2.23.0

[PATCH v3 3/5] target/riscv: add vector index load and store instructions

Vector indexed operations add the contents of each element of the
vector offset operand specified by vs2 to the base effective address
to give the effective address of each element.

Signed-off-by: LIU Zhiwei 
---
 target/riscv/helper.h   |  35 
 target/riscv/insn32.decode  |  16 ++
 target/riscv/insn_trans/trans_rvv.inc.c | 164 ++
 target/riscv/vector_helper.c| 214 
 4 files changed, 429 insertions(+)

diff --git a/target/riscv/helper.h b/target/riscv/helper.h
index 19c1bfc317..5ebd3d6ccd 100644
--- a/target/riscv/helper.h
+++ b/target/riscv/helper.h
@@ -183,3 +183,38 @@ DEF_HELPER_6(vsse_v_b_mask, void, ptr, tl, tl, ptr, env, 
i32)
 DEF_HELPER_6(vsse_v_h_mask, void, ptr, tl, tl, ptr, env, i32)
 DEF_HELPER_6(vsse_v_w_mask, void, ptr, tl, tl, ptr, env, i32)
 DEF_HELPER_6(vsse_v_d_mask, void, ptr, tl, tl, ptr, env, i32)
+DEF_HELPER_6(vlxb_v_b_mask, void, ptr, tl, ptr, ptr, env, i32)
+DEF_HELPER_6(vlxb_v_h_mask, void, ptr, tl, ptr, ptr, env, i32)
+DEF_HELPER_6(vlxb_v_w_mask, void, ptr, tl, ptr, ptr, env, i32)
+DEF_HELPER_6(vlxb_v_d_mask, void, ptr, tl, ptr, ptr, env, i32)
+DEF_HELPER_6(vlxh_v_h_mask, void, ptr, tl, ptr, ptr, env, i32)
+DEF_HELPER_6(vlxh_v_w_mask, void, ptr, tl, ptr, ptr, env, i32)
+DEF_HELPER_6(vlxh_v_d_mask, void, ptr, tl, ptr, ptr, env, i32)
+DEF_HELPER_6(vlxw_v_w_mask, void, ptr, tl, ptr, ptr, env, i32)
+DEF_HELPER_6(vlxw_v_d_mask, void, ptr, tl, ptr, ptr, env, i32)
+DEF_HELPER_6(vlxe_v_b_mask, void, ptr, tl, ptr, ptr, env, i32)
+DEF_HELPER_6(vlxe_v_h_mask, void, ptr, tl, ptr, ptr, env, i32)
+DEF_HELPER_6(vlxe_v_w_mask, void, ptr, tl, ptr, ptr, env, i32)
+DEF_HELPER_6(vlxe_v_d_mask, void, ptr, tl, ptr, ptr, env, i32)
+DEF_HELPER_6(vlxbu_v_b_mask, void, ptr, tl, ptr, ptr, env, i32)
+DEF_HELPER_6(vlxbu_v_h_mask, void, ptr, tl, ptr, ptr, env, i32)
+DEF_HELPER_6(vlxbu_v_w_mask, void, ptr, tl, ptr, ptr, env, i32)
+DEF_HELPER_6(vlxbu_v_d_mask, void, ptr, tl, ptr, ptr, env, i32)
+DEF_HELPER_6(vlxhu_v_h_mask, void, ptr, tl, ptr, ptr, env, i32)
+DEF_HELPER_6(vlxhu_v_w_mask, void, ptr, tl, ptr, ptr, env, i32)
+DEF_HELPER_6(vlxhu_v_d_mask, void, ptr, tl, ptr, ptr, env, i32)
+DEF_HELPER_6(vlxwu_v_w_mask, void, ptr, tl, ptr, ptr, env, i32)
+DEF_HELPER_6(vlxwu_v_d_mask, void, ptr, tl, ptr, ptr, env, i32)
+DEF_HELPER_6(vsxb_v_b_mask, void, ptr, tl, ptr, ptr, env, i32)
+DEF_HELPER_6(vsxb_v_h_mask, void, ptr, tl, ptr, ptr, env, i32)
+DEF_HELPER_6(vsxb_v_w_mask, void, ptr, tl, ptr, ptr, env, i32)
+DEF_HELPER_6(vsxb_v_d_mask, void, ptr, tl, ptr, ptr, env, i32)
+DEF_HELPER_6(vsxh_v_h_mask, void, ptr, tl, ptr, ptr, env, i32)
+DEF_HELPER_6(vsxh_v_w_mask, void, ptr, tl, ptr, ptr, env, i32)
+DEF_HELPER_6(vsxh_v_d_mask, void, ptr, tl, ptr, ptr, env, i32)
+DEF_HELPER_6(vsxw_v_w_mask, void, ptr, tl, ptr, ptr, env, i32)
+DEF_HELPER_6(vsxw_v_d_mask, void, ptr, tl, ptr, ptr, env, i32)
+DEF_HELPER_6(vsxe_v_b_mask, void, ptr, tl, ptr, ptr, env, i32)
+DEF_HELPER_6(vsxe_v_h_mask, void, ptr, tl, ptr, ptr, env, i32)
+DEF_HELPER_6(vsxe_v_w_mask, void, ptr, tl, ptr, ptr, env, i32)
+DEF_HELPER_6(vsxe_v_d_mask, void, ptr, tl, ptr, ptr, env, i32)
diff --git a/target/riscv/insn32.decode b/target/riscv/insn32.decode
index 2f2d3d13b3..6a363a6b7e 100644
--- a/target/riscv/insn32.decode
+++ b/target/riscv/insn32.decode
@@ -236,6 +236,22 @@ vssh_v ... 010 . . . 101 . 0100111 @r_nfvm
 vssw_v ... 010 . . . 110 . 0100111 @r_nfvm
 vsse_v ... 010 . . . 111 . 0100111 @r_nfvm
 
+vlxb_v ... 111 . . . 000 . 111 @r_nfvm
+vlxh_v ... 111 . . . 101 . 111 @r_nfvm
+vlxw_v ... 111 . . . 110 . 111 @r_nfvm
+vlxe_v ... 011 . . . 111 . 111 @r_nfvm
+vlxbu_v... 011 . . . 000 . 111 @r_nfvm
+vlxhu_v... 011 . . . 101 . 111 @r_nfvm
+vlxwu_v... 011 . . . 110 . 111 @r_nfvm
+vsxb_v ... 011 . . . 000 . 0100111 @r_nfvm
+vsxh_v ... 011 . . . 101 . 0100111 @r_nfvm
+vsxw_v ... 011 . . . 110 . 0100111 @r_nfvm
+vsxe_v ... 011 . . . 111 . 0100111 @r_nfvm
+vsuxb_v... 111 . . . 000 . 0100111 @r_nfvm
+vsuxh_v... 111 . . . 101 . 0100111 @r_nfvm
+vsuxw_v... 111 . . . 110 . 0100111 @r_nfvm
+vsuxe_v... 111 . . . 111 . 0100111 @r_nfvm
+
 # *** new major opcode OP-V ***
 vsetvli 0 ... . 111 . 1010111  @r2_zimm
 vsetvl  100 . . 111 . 1010111  @r
diff --git a/target/riscv/insn_trans/trans_rvv.inc.c 
b/target/riscv/insn_trans/trans_rvv.inc.c
index 5a7ea94c2d..13033b3906 100644
--- a/target/riscv/insn_trans/trans_rvv.inc.c
+++ b/target/riscv/insn_trans/trans_rvv.inc.c
@@ -499,3 +499,167 @@ GEN_VEXT_ST_STRIDE_TRANS(vssb_v, vext_st_stride_trans, 0)
 GEN_VEXT_ST_STRIDE_TRANS(vssh_v, vext_st_stride_trans, 1)
 GEN_VEXT_ST_STRIDE_TRANS(vssw_v,

Re: [PATCH rc4 06/29] target/avr: Add defintions of AVR core types

2020-02-09 Thread Michael Rolnik

Hi all.

When I decided to implement AVR 8 bit CPU support for QEMU I found this
document

which
listed all AVR instructions.
After that I learned that there are several CPU flavours, I looked into
this GCC file
 to
figure out what are they as I could not find any official document
explaining it.
Then I downloaded several datasheets and created a list of instructions by
CPU type (attached).It turned out that there are some variations
e.g.
- AVTTINY - some have LDS, some don't
- AVR1, AVR25 - some have short SP, some don't
- AVRXMEGA2, AVRXMEGA4, AVRXMEGA5, AVRXMEGA6, AVRXMEGA7 - some have RMW,
some don't
- AVRXMEGA3 - some have RCALL, some don't

I decided to leave CPU flavour definition as suggested by GCC
gcc/config/avr/avr-devices.c

file and when a specific MCU is created it will set / reset CPU features
relevant to it.

I hope this helps.

Best Regards,
Michael Rolnik







On Sat, Feb 8, 2020 at 9:35 AM Aleksandar Markovic <
aleksandar.m.m...@gmail.com> wrote:

>
>
> On Sunday, February 2, 2020, Joaquin de Andres 
> wrote:
>
>> On 1/31/20 1:02 AM, Aleksandar Markovic wrote:
>>
>>> From: Michael Rolnik 
>>>
>>> AVR core types are:
>>>
>>>- avr1
>>>- avr2
>>>- avr25
>>>- avr3
>>>- avr31
>>>- avr35
>>>- avr4
>>>- avr5
>>>- avr51
>>>- avr6
>>>- avrtiny
>>>- xmega2
>>>- xmega3
>>>- xmega4
>>>- xmega5
>>>- xmega6
>>>- xmega7
>>>
>>> Each core type covers multiple AVR MCUs, mentioned in the comments
>>> before definition of particular AVR core type (part of this patch).
>>>
>>> AVR core type defines shared features that are valid for all AVR
>>> MCUs belonging in that type.
>>>
>>> [AM: Split a larger AVR introduction patch into logical units]
>>> Suggested-by: Aleksandar Markovic 
>>>
>>> Co-developed-by: Michael Rolnik 
>>> Co-developed-by: Sarah Harris 
>>> Signed-off-by: Michael Rolnik 
>>> Signed-off-by: Sarah Harris 
>>> Signed-off-by: Michael Rolnik 
>>> Acked-by: Igor Mammedov 
>>> Tested-by: Philippe Mathieu-Daudé 
>>> Signed-off-by: Richard Henderson 
>>> Signed-off-by: Aleksandar Markovic 
>>> ---
>>>   target/avr/cpu.c | 601
>>> +++
>>>   1 file changed, 601 insertions(+)
>>>
>>> diff --git a/target/avr/cpu.c b/target/avr/cpu.c
>>> index f41a887..e0ae055 100644
>>> --- a/target/avr/cpu.c
>>> +++ b/target/avr/cpu.c
>>> @@ -215,3 +215,604 @@ static void avr_cpu_class_init(ObjectClass *oc,
>>> void *data)
>>>   cc->gdb_num_core_regs = 35;
>>>   cc->gdb_core_xml_file = "avr-cpu.xml";
>>>   }
>>> +
>>> +/*
>>> + * Setting features of AVR core type avr1
>>> + * --
>>> + *
>>> + * This type of AVR core is present in the following AVR MCUs:
>>> + *
>>> + * at90s1200, attiny11, attiny12, attiny15, attiny28
>>> + */
>>> +static void avr_avr1_initfn(Object *obj)
>>> +{
>>> +AVRCPU *cpu = AVR_CPU(obj);
>>> +CPUAVRState *env = >env;
>>> +
>>> +set_avr_feature(env, AVR_FEATURE_LPM);
>>> +set_avr_feature(env, AVR_FEATURE_2_BYTE_SP);
>>> +set_avr_feature(env, AVR_FEATURE_2_BYTE_PC);
>>> +}
>>> +
>>> +/*
>>> + * Setting features of AVR core type avr2
>>> + * --
>>> + *
>>> + * This type of AVR core is present in the following AVR MCUs:
>>> + *
>>> + * at90s2313, at90s2323, at90s2333, at90s2343, attiny22, attiny26,
>>> at90s4414,
>>> + * at90s4433, at90s4434, at90s8515, at90c8534, at90s8535
>>> + */
>>> +static void avr_avr2_initfn(Object *obj)
>>> +{
>>> +AVRCPU *cpu = AVR_CPU(obj);
>>> +CPUAVRState *env = >env;
>>> +
>>> +set_avr_feature(env, AVR_FEATURE_LPM);
>>> +set_avr_feature(env, AVR_FEATURE_IJMP_ICALL);
>>> +set_avr_feature(env, AVR_FEATURE_ADIW_SBIW);
>>> +set_avr_feature(env, AVR_FEATURE_SRAM);
>>> +set_avr_feature(env, AVR_FEATURE_BREAK);
>>> +
>>> +set_avr_feature(env, AVR_FEATURE_2_BYTE_PC);
>>> +set_avr_feature(env, AVR_FEATURE_2_BYTE_SP);
>>> +}
>>> +
>>> +/*
>>> + * Setting features of AVR core type avr25
>>> + * --
>>> + *
>>> + * This type of AVR core is present in the following AVR MCUs:
>>> + *
>>> + * ata5272, ata6616c, attiny13, attiny13a, attiny2313, attiny2313a,
>>> attiny24,
>>> + * attiny24a, attiny4313, attiny44, attiny44a, attiny441, attiny84,
>>> attiny84a,
>>> + * attiny25, attiny45, attiny85, attiny261, attiny261a, attiny461,
>>> attiny461a,
>>> + * attiny861, attiny861a, attiny43u, attiny87, attiny48, attiny88,
>>> attiny828,
>>> + * attiny841, at86rf401
>>> + */
>>> +static void avr_avr25_initfn(Object *obj)
>>> +{
>>> +AVRCPU *cpu = AVR_CPU(obj);
>>> +CPUAVRState *env = >env;
>>> +
>>> +set_avr_feature(env, AVR_FEATURE_LPM);
>>> +

[Bug 1759522] Re: windows qemu-img create vpc/vhdx error

2020-02-09 Thread Qi Zhou

I confirm this is still exists using qemu-4.2.0.

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

Title:
  windows qemu-img create vpc/vhdx error

Status in QEMU:
  New

Bug description:
  On windows, using qemu-img (version 2.11.90) to create vpc/vhdx
  virtual disk tends to fail. Here's the way to reproduce:

  1. Install qemu-w64-setup-20180321.exe

  2. Use `qemu-img create -f vhdx -o subformat=fixed disk.vhdx 512M` to create 
a vhdx:
 Formatting 'disk.vhdx', fmt=vhdx size=536870912 log_size=1048576 
block_size=0 subformat=fixed

  3. Execute `qemu-img info disk.vhdx` gives the result, (note the `disk size` 
is incorrect):
 image: disk.vhdx
 file format: vhdx
 virtual size: 512M (536870912 bytes)
 disk size: 1.4M
 cluster_size: 8388608

  4. On Windows 10 (V1709), double click disk.vhdx gives an error:
 Make sure the file is in an NTFS volume and isn't in a compressed folder 
or volume.

 Using Disk Management -> Action -> Attach VHD gives an error:
 The requested operation could not be completed due to a virtual disk 
system limitation. Virtual hard disk files must be uncompressed and uneccrypted 
and must not be sparse.

  Comparison with Windows 10 created VHDX:

  1. Using Disk Management -> Action -> Create VHD:
 File name: win.vhdx
 Virtual hard disk size: 512MB
 Virtual hard disk format: VHDX
 Virtual hard disk type: Fixed size

  2. Detach VHDX

  3. Execute `qemu-img info win.vhdx` gives the result:
 image: win.vhdx
 file format: vhdx
 virtual size: 512M (536870912 bytes)
 disk size: 516M
 cluster_size: 33554432

  Comparison with qemu-img under Ubuntu:

  1. Version: qemu-img version 2.5.0 (Debian 1:2.5+dfsg-5ubuntu10.16),
  Copyright (c) 2004-2008 Fabrice Bellard

  2. qemu-img create -f vhdx -o subformat=fixed lin.vhdx 512M
 Formatting 'lin.vhdx', fmt=vhdx size=536870912 log_size=1048576 
block_size=0 subformat=fixed

  3. qemu-img info lin.vhdx
 image: lin.vhdx
 file format: vhdx
 virtual size: 512M (536870912 bytes)
 disk size: 520M
 cluster_size: 8388608

  4. Load lin.vhdx under Windows 10 is ok

  The same thing happens on `vpc` format with or without
  `oformat=fixed`, it seems that windows version of qemu-img has some
  incorrect operation? My guess is that windows version of qemu-img
  doesn't handle the description field of vpc/vhdx, which leads to an
  incorrect `disk size` field.

To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/1759522/+subscriptions

Re: [PATCH] migration: Optimization about wait-unplug migration state

2020-02-09 Thread zhukeqian




On 2020/2/4 17:14, Juan Quintela wrote:
> Keqian Zhu  wrote:
>> qemu_savevm_nr_failover_devices() is originally designed to
>> get the number of failover devices, but it actually returns
>> the number of "unplug-pending" failover devices now. Moreover,
>> what drives migration state to wait-unplug should be the number
>> of "unplug-pending" failover devices, not all failover devices.
>>
>> We can also notice that qemu_savevm_state_guest_unplug_pending()
>> and qemu_savevm_nr_failover_devices() is equivalent almost (from
>> the code view). So the latter is incorrect semantically and
>> useless, just delete it.
>>
>> In the qemu_savevm_state_guest_unplug_pending(), once hit a
>> unplug-pending failover device, then it can return true right
>> now to save cpu time.
>>
>> Signed-off-by: Keqian Zhu 
> 
> Reviewed-by: Juan Quintela 
> 
> For my reading you are right:
> - 1st function naming is not right
> - 2nd function achieves exactly the same effect
> 
> I will wait until Jens says anything, but then I will queue it.
> 
> Thanks, Juan.
> 
> 
> .
> 
Thanks,
Keqian.

Re: [PATCH] migration: Optimization about wait-unplug migration state

2020-02-09 Thread zhukeqian




On 2020/2/5 22:40, Jens Freimann wrote:
> On Tue, Feb 04, 2020 at 01:08:41PM +0800, Keqian Zhu wrote:
>> qemu_savevm_nr_failover_devices() is originally designed to
>> get the number of failover devices, but it actually returns
>> the number of "unplug-pending" failover devices now. Moreover,
>> what drives migration state to wait-unplug should be the number
>> of "unplug-pending" failover devices, not all failover devices.
>>
>> We can also notice that qemu_savevm_state_guest_unplug_pending()
>> and qemu_savevm_nr_failover_devices() is equivalent almost (from
>> the code view). So the latter is incorrect semantically and
>> useless, just delete it.
>>
>> In the qemu_savevm_state_guest_unplug_pending(), once hit a
>> unplug-pending failover device, then it can return true right
>> now to save cpu time.
>>
>> Signed-off-by: Keqian Zhu 
>> ---
>> Cc: jfreim...@redhat.com
>> Cc: Juan Quintela 
>> Cc: "Dr. David Alan Gilbert" 
>> ---
>> migration/migration.c |  2 +-
>> migration/savevm.c| 24 +++-
>> migration/savevm.h|  1 -
>> 3 files changed, 4 insertions(+), 23 deletions(-)
>>
>> diff --git a/migration/migration.c b/migration/migration.c
>> index 3a21a4686c..deedc968cf 100644
>> --- a/migration/migration.c
>> +++ b/migration/migration.c
>> @@ -,7 +,7 @@ static void *migration_thread(void *opaque)
>>
>> qemu_savevm_state_setup(s->to_dst_file);
>>
>> -if (qemu_savevm_nr_failover_devices()) {
>> +if (qemu_savevm_state_guest_unplug_pending()) {
>> migrate_set_state(>state, MIGRATION_STATUS_SETUP,
>>   MIGRATION_STATUS_WAIT_UNPLUG);
>>
>> diff --git a/migration/savevm.c b/migration/savevm.c
>> index f19cb9ec7a..1d4220ece8 100644
>> --- a/migration/savevm.c
>> +++ b/migration/savevm.c
>> @@ -1140,36 +1140,18 @@ void qemu_savevm_state_header(QEMUFile *f)
>> }
>> }
>>
>> -int qemu_savevm_nr_failover_devices(void)
>> +bool qemu_savevm_state_guest_unplug_pending(void)
>> {
>> SaveStateEntry *se;
>> -int n = 0;
>>
>> QTAILQ_FOREACH(se, _state.handlers, entry) {
>> if (se->vmsd && se->vmsd->dev_unplug_pending &&
>> se->vmsd->dev_unplug_pending(se->opaque)) {
>> -n++;
>> -}
>> -}
>> -
>> -return n;
>> -}
>> -
>> -bool qemu_savevm_state_guest_unplug_pending(void)
>> -{
>> -SaveStateEntry *se;
>> -int n = 0;
>> -
>> -QTAILQ_FOREACH(se, _state.handlers, entry) {
>> -if (!se->vmsd || !se->vmsd->dev_unplug_pending) {
>> -continue;
>> -}
>> -if (se->vmsd->dev_unplug_pending(se->opaque)) {
>> -n++;
>> +return true;
>> }
>> }
>>
>> -return n > 0;
>> +return false;
>> }
>>
>> void qemu_savevm_state_setup(QEMUFile *f)
>> diff --git a/migration/savevm.h b/migration/savevm.h
>> index c42b9c80ee..ba64a7e271 100644
>> --- a/migration/savevm.h
>> +++ b/migration/savevm.h
>> @@ -31,7 +31,6 @@
>>
>> bool qemu_savevm_state_blocked(Error **errp);
>> void qemu_savevm_state_setup(QEMUFile *f);
>> -int qemu_savevm_nr_failover_devices(void);
>> bool qemu_savevm_state_guest_unplug_pending(void);
>> int qemu_savevm_state_resume_prepare(MigrationState *s);
>> void qemu_savevm_state_header(QEMUFile *f);
>> -- 
>> 2.19.1
> 
> Looks good to me. I tested it and it still works, so
> Tested-by: Jens Freimann 
> Reviewed-by: Jens Freimann 
> regards
> Jens
> 
> 
> .
> 
Thanks,
Keqian.

[PATCH v6 4/4] spapr: Add Hcalls to support PAPR NVDIMM device

This patch implements few of the necessary hcalls for the nvdimm support.

PAPR semantics is such that each NVDIMM device is comprising of multiple
SCM(Storage Class Memory) blocks. The guest requests the hypervisor to
bind each of the SCM blocks of the NVDIMM device using hcalls. There can
be SCM block unbind requests in case of driver errors or unplug(not
supported now) use cases. The NVDIMM label read/writes are done through
hcalls.

Since each virtual NVDIMM device is divided into multiple SCM blocks,
the bind, unbind, and queries using hcalls on those blocks can come
independently. This doesn't fit well into the qemu device semantics,
where the map/unmap are done at the (whole)device/object level granularity.
The patch doesnt actually bind/unbind on hcalls but let it happen at the
device_add/del phase itself instead.

The guest kernel makes bind/unbind requests for the virtual NVDIMM device
at the region level granularity. Without interleaving, each virtual NVDIMM
device is presented as a separate guest physical address range. So, there
is no way a partial bind/unbind request can come for the vNVDIMM in a
hcall for a subset of SCM blocks of a virtual NVDIMM. Hence it is safe to
do bind/unbind everything during the device_add/del.

Signed-off-by: Shivaprasad G Bhat 
---
 hw/ppc/spapr_nvdimm.c  |  298 
 include/hw/ppc/spapr.h |8 +
 2 files changed, 305 insertions(+), 1 deletion(-)

diff --git a/hw/ppc/spapr_nvdimm.c b/hw/ppc/spapr_nvdimm.c
index d03c8d3a5c..74eeb8bb74 100644
--- a/hw/ppc/spapr_nvdimm.c
+++ b/hw/ppc/spapr_nvdimm.c
@@ -28,6 +28,7 @@
 #include "hw/mem/nvdimm.h"
 #include "qemu/nvdimm-utils.h"
 #include "hw/ppc/fdt.h"
+#include "qemu/range.h"
 
 void spapr_nvdimm_validate_opts(NVDIMMDevice *nvdimm, uint64_t size,
 Error **errp)
@@ -175,3 +176,300 @@ void spapr_dt_persistent_memory(void *fdt)
 
 return;
 }
+
+static target_ulong h_scm_read_metadata(PowerPCCPU *cpu,
+SpaprMachineState *spapr,
+target_ulong opcode,
+target_ulong *args)
+{
+uint32_t drc_index = args[0];
+uint64_t offset = args[1];
+uint64_t len = args[2];
+SpaprDrc *drc = spapr_drc_by_index(drc_index);
+NVDIMMDevice *nvdimm;
+NVDIMMClass *ddc;
+uint64_t data = 0;
+uint8_t buf[8] = { 0 };
+
+if (!drc || !drc->dev ||
+spapr_drc_type(drc) != SPAPR_DR_CONNECTOR_TYPE_PMEM) {
+return H_PARAMETER;
+}
+
+if (len != 1 && len != 2 &&
+len != 4 && len != 8) {
+return H_P3;
+}
+
+nvdimm = NVDIMM(drc->dev);
+if ((offset + len < offset) ||
+(nvdimm->label_size < len + offset)) {
+return H_P2;
+}
+
+ddc = NVDIMM_GET_CLASS(nvdimm);
+ddc->read_label_data(nvdimm, buf, len, offset);
+
+switch (len) {
+case 1:
+data = ldub_p(buf);
+break;
+case 2:
+data = lduw_be_p(buf);
+break;
+case 4:
+data = ldl_be_p(buf);
+break;
+case 8:
+data = ldq_be_p(buf);
+break;
+default:
+g_assert_not_reached();
+}
+
+args[0] = data;
+
+return H_SUCCESS;
+}
+
+static target_ulong h_scm_write_metadata(PowerPCCPU *cpu,
+ SpaprMachineState *spapr,
+ target_ulong opcode,
+ target_ulong *args)
+{
+uint32_t drc_index = args[0];
+uint64_t offset = args[1];
+uint64_t data = args[2];
+uint64_t len = args[3];
+SpaprDrc *drc = spapr_drc_by_index(drc_index);
+NVDIMMDevice *nvdimm;
+NVDIMMClass *ddc;
+uint8_t buf[8] = { 0 };
+
+if (!drc || !drc->dev ||
+spapr_drc_type(drc) != SPAPR_DR_CONNECTOR_TYPE_PMEM) {
+return H_PARAMETER;
+}
+
+if (len != 1 && len != 2 &&
+len != 4 && len != 8) {
+return H_P4;
+}
+
+nvdimm = NVDIMM(drc->dev);
+if ((offset + len < offset) ||
+(nvdimm->label_size < len + offset)) {
+return H_P2;
+}
+
+switch (len) {
+case 1:
+if (data & 0xff00) {
+return H_P2;
+}
+stb_p(buf, data);
+break;
+case 2:
+if (data & 0x) {
+return H_P2;
+}
+stw_be_p(buf, data);
+break;
+case 4:
+if (data & 0x) {
+return H_P2;
+}
+stl_be_p(buf, data);
+break;
+case 8:
+stq_be_p(buf, data);
+break;
+default:
+g_assert_not_reached();
+}
+
+ddc = NVDIMM_GET_CLASS(nvdimm);
+ddc->write_label_data(nvdimm, buf, len, offset);
+
+return H_SUCCESS;
+}
+
+static target_ulong h_scm_bind_mem(PowerPCCPU *cpu, SpaprMachineState *spapr,
+   target_ulong opcode, target_ulong *args)

[PATCH v6 2/4] nvdimm: add uuid property to nvdimm

For ppc64, PAPR requires the nvdimm device to have UUID property
set in the device tree. Add an option to get it from the user.

Signed-off-by: Shivaprasad G Bhat 
Reviewed-by: David Gibson 
Reviewed-by: Igor Mammedov 
---
 hw/mem/nvdimm.c |   40 
 include/hw/mem/nvdimm.h |7 +++
 2 files changed, 47 insertions(+)

diff --git a/hw/mem/nvdimm.c b/hw/mem/nvdimm.c
index 39f1426d1f..8e426d24bb 100644
--- a/hw/mem/nvdimm.c
+++ b/hw/mem/nvdimm.c
@@ -69,11 +69,51 @@ out:
 error_propagate(errp, local_err);
 }
 
+static void nvdimm_get_uuid(Object *obj, Visitor *v, const char *name,
+  void *opaque, Error **errp)
+{
+NVDIMMDevice *nvdimm = NVDIMM(obj);
+char *value = NULL;
+
+value = qemu_uuid_unparse_strdup(>uuid);
+
+visit_type_str(v, name, , errp);
+g_free(value);
+}
+
+
+static void nvdimm_set_uuid(Object *obj, Visitor *v, const char *name,
+  void *opaque, Error **errp)
+{
+NVDIMMDevice *nvdimm = NVDIMM(obj);
+Error *local_err = NULL;
+char *value;
+
+visit_type_str(v, name, , _err);
+if (local_err) {
+goto out;
+}
+
+if (qemu_uuid_parse(value, >uuid) != 0) {
+error_setg(errp, "Property '%s.%s' has invalid value",
+   object_get_typename(obj), name);
+goto out;
+}
+g_free(value);
+
+out:
+error_propagate(errp, local_err);
+}
+
+
 static void nvdimm_init(Object *obj)
 {
 object_property_add(obj, NVDIMM_LABEL_SIZE_PROP, "int",
 nvdimm_get_label_size, nvdimm_set_label_size, NULL,
 NULL, NULL);
+
+object_property_add(obj, NVDIMM_UUID_PROP, "QemuUUID", nvdimm_get_uuid,
+nvdimm_set_uuid, NULL, NULL, NULL);
 }
 
 static void nvdimm_finalize(Object *obj)
diff --git a/include/hw/mem/nvdimm.h b/include/hw/mem/nvdimm.h
index 523a9b3d4a..4807ca615b 100644
--- a/include/hw/mem/nvdimm.h
+++ b/include/hw/mem/nvdimm.h
@@ -25,6 +25,7 @@
 
 #include "hw/mem/pc-dimm.h"
 #include "hw/acpi/bios-linker-loader.h"
+#include "qemu/uuid.h"
 
 #define NVDIMM_DEBUG 0
 #define nvdimm_debug(fmt, ...)\
@@ -49,6 +50,7 @@
TYPE_NVDIMM)
 
 #define NVDIMM_LABEL_SIZE_PROP "label-size"
+#define NVDIMM_UUID_PROP   "uuid"
 #define NVDIMM_UNARMED_PROP"unarmed"
 
 struct NVDIMMDevice {
@@ -83,6 +85,11 @@ struct NVDIMMDevice {
  * the guest write persistence.
  */
 bool unarmed;
+
+/*
+ * The PPC64 - spapr requires each nvdimm device have a uuid.
+ */
+QemuUUID uuid;
 };
 typedef struct NVDIMMDevice NVDIMMDevice;

[PATCH v6 3/4] spapr: Add NVDIMM device support

Add support for NVDIMM devices for sPAPR. Piggyback on existing nvdimm
device interface in QEMU to support virtual NVDIMM devices for Power.
Create the required DT entries for the device (some entries have
dummy values right now).

The patch creates the required DT node and sends a hotplug
interrupt to the guest. Guest is expected to undertake the normal
DR resource add path in response and start issuing PAPR SCM hcalls.

The device support is verified based on the machine version unlike x86.

This is how it can be used ..
Ex :
For coldplug, the device to be added in qemu command line as shown below
-object 
memory-backend-file,id=memnvdimm0,prealloc=yes,mem-path=/tmp/nvdimm0,share=yes,size=1073872896
-device 
nvdimm,label-size=128k,uuid=75a3cdd7-6a2f-4791-8d15-fe0a920e8e9e,memdev=memnvdimm0,id=nvdimm0,slot=0

For hotplug, the device to be added from monitor as below
object_add 
memory-backend-file,id=memnvdimm0,prealloc=yes,mem-path=/tmp/nvdimm0,share=yes,size=1073872896
device_add 
nvdimm,label-size=128k,uuid=75a3cdd7-6a2f-4791-8d15-fe0a920e8e9e,memdev=memnvdimm0,id=nvdimm0,slot=0

Signed-off-by: Shivaprasad G Bhat 
Signed-off-by: Bharata B Rao 
   [Early implementation]
---
 default-configs/ppc64-softmmu.mak |1 
 hw/mem/Kconfig|2 
 hw/ppc/Makefile.objs  |2 
 hw/ppc/spapr.c|   69 +-
 hw/ppc/spapr_drc.c|   19 
 hw/ppc/spapr_events.c |4 +
 hw/ppc/spapr_nvdimm.c |  177 +
 include/hw/ppc/spapr_drc.h|9 ++
 include/hw/ppc/spapr_nvdimm.h |   37 
 9 files changed, 309 insertions(+), 11 deletions(-)
 create mode 100644 hw/ppc/spapr_nvdimm.c
 create mode 100644 include/hw/ppc/spapr_nvdimm.h

diff --git a/default-configs/ppc64-softmmu.mak 
b/default-configs/ppc64-softmmu.mak
index cca52665d9..ae0841fa3a 100644
--- a/default-configs/ppc64-softmmu.mak
+++ b/default-configs/ppc64-softmmu.mak
@@ -8,3 +8,4 @@ CONFIG_POWERNV=y
 
 # For pSeries
 CONFIG_PSERIES=y
+CONFIG_NVDIMM=y
diff --git a/hw/mem/Kconfig b/hw/mem/Kconfig
index 620fd4cb59..2ad052a536 100644
--- a/hw/mem/Kconfig
+++ b/hw/mem/Kconfig
@@ -8,4 +8,4 @@ config MEM_DEVICE
 config NVDIMM
 bool
 default y
-depends on PC
+depends on (PC || PSERIES)
diff --git a/hw/ppc/Makefile.objs b/hw/ppc/Makefile.objs
index a4bac57be6..c3d3cc56eb 100644
--- a/hw/ppc/Makefile.objs
+++ b/hw/ppc/Makefile.objs
@@ -7,7 +7,7 @@ obj-$(CONFIG_PSERIES) += spapr.o spapr_caps.o spapr_vio.o 
spapr_events.o
 obj-$(CONFIG_PSERIES) += spapr_hcall.o spapr_iommu.o spapr_rtas.o
 obj-$(CONFIG_PSERIES) += spapr_pci.o spapr_rtc.o spapr_drc.o
 obj-$(CONFIG_PSERIES) += spapr_cpu_core.o spapr_ovec.o spapr_irq.o
-obj-$(CONFIG_PSERIES) += spapr_tpm_proxy.o
+obj-$(CONFIG_PSERIES) += spapr_tpm_proxy.o spapr_nvdimm.o
 obj-$(CONFIG_SPAPR_RNG) +=  spapr_rng.o
 obj-$(call land,$(CONFIG_PSERIES),$(CONFIG_LINUX)) += spapr_pci_vfio.o 
spapr_pci_nvlink2.o
 # IBM PowerNV
diff --git a/hw/ppc/spapr.c b/hw/ppc/spapr.c
index c9b2e0a5e0..d3cb8b4c7b 100644
--- a/hw/ppc/spapr.c
+++ b/hw/ppc/spapr.c
@@ -80,6 +80,7 @@
 #include "hw/ppc/spapr_cpu_core.h"
 #include "hw/mem/memory-device.h"
 #include "hw/ppc/spapr_tpm_proxy.h"
+#include "hw/ppc/spapr_nvdimm.h"
 
 #include "monitor/monitor.h"
 
@@ -675,6 +676,14 @@ static int spapr_populate_drmem_v2(SpaprMachineState 
*spapr, void *fdt,
 size = di->size;
 node = di->node;
 
+/*
+ * The NVDIMM area is hotpluggable after the NVDIMM is unplugged. The
+ * area is marked hotpluggable in the next iteration for the bigger
+ * chunk including the NVDIMM occupied area.
+ */
+if (info->value->type == MEMORY_DEVICE_INFO_KIND_NVDIMM)
+continue;
+
 /* Entry for hot-pluggable area */
 if (cur_addr < addr) {
 drc = spapr_drc_by_id(TYPE_SPAPR_DRC_LMB, cur_addr / lmb_size);
@@ -1266,6 +1275,11 @@ void *spapr_build_fdt(SpaprMachineState *spapr, bool 
reset, size_t space)
 }
 }
 
+/* NVDIMM devices */
+if (mc->nvdimm_supported) {
+spapr_dt_persistent_memory(fdt);
+}
+
 return fdt;
 }
 
@@ -2629,6 +2643,7 @@ static void spapr_machine_init(MachineState *machine)
 {
 SpaprMachineState *spapr = SPAPR_MACHINE(machine);
 SpaprMachineClass *smc = SPAPR_MACHINE_GET_CLASS(machine);
+MachineClass *mc = MACHINE_GET_CLASS(machine);
 const char *kernel_filename = machine->kernel_filename;
 const char *initrd_filename = machine->initrd_filename;
 PCIHostState *phb;
@@ -2861,6 +2876,10 @@ static void spapr_machine_init(MachineState *machine)
 "may run and log hardware error on the destination");
 }
 
+if (mc->nvdimm_supported) {
+spapr_create_nvdimm_dr_connectors(spapr);
+}
+
 /* Set up RTAS event infrastructure */
 spapr_events_init(spapr);
 
@@ -3430,7 +3449,8 @@ static void

[PATCH v6 1/4] mem: move nvdimm_device_list to utilities

nvdimm_device_list is required for parsing the list for devices
in subsequent patches. Move it to common utility area.

Signed-off-by: Shivaprasad G Bhat 
Reviewed-by: Igor Mammedov 
Reviewed-by: David Gibson 
---
 hw/acpi/nvdimm.c|   28 +---
 include/qemu/nvdimm-utils.h |7 +++
 util/Makefile.objs  |1 +
 util/nvdimm-utils.c |   29 +
 4 files changed, 38 insertions(+), 27 deletions(-)
 create mode 100644 include/qemu/nvdimm-utils.h
 create mode 100644 util/nvdimm-utils.c

diff --git a/hw/acpi/nvdimm.c b/hw/acpi/nvdimm.c
index 9fdad6dc3f..5219dd0e2e 100644
--- a/hw/acpi/nvdimm.c
+++ b/hw/acpi/nvdimm.c
@@ -32,33 +32,7 @@
 #include "hw/acpi/bios-linker-loader.h"
 #include "hw/nvram/fw_cfg.h"
 #include "hw/mem/nvdimm.h"
-
-static int nvdimm_device_list(Object *obj, void *opaque)
-{
-GSList **list = opaque;
-
-if (object_dynamic_cast(obj, TYPE_NVDIMM)) {
-*list = g_slist_append(*list, DEVICE(obj));
-}
-
-object_child_foreach(obj, nvdimm_device_list, opaque);
-return 0;
-}
-
-/*
- * inquire NVDIMM devices and link them into the list which is
- * returned to the caller.
- *
- * Note: it is the caller's responsibility to free the list to avoid
- * memory leak.
- */
-static GSList *nvdimm_get_device_list(void)
-{
-GSList *list = NULL;
-
-object_child_foreach(qdev_get_machine(), nvdimm_device_list, );
-return list;
-}
+#include "qemu/nvdimm-utils.h"
 
 #define NVDIMM_UUID_LE(a, b, c, d0, d1, d2, d3, d4, d5, d6, d7) \
{ (a) & 0xff, ((a) >> 8) & 0xff, ((a) >> 16) & 0xff, ((a) >> 24) & 0xff, \
diff --git a/include/qemu/nvdimm-utils.h b/include/qemu/nvdimm-utils.h
new file mode 100644
index 00..4b8b198ba7
--- /dev/null
+++ b/include/qemu/nvdimm-utils.h
@@ -0,0 +1,7 @@
+#ifndef NVDIMM_UTILS_H
+#define NVDIMM_UTILS_H
+
+#include "qemu/osdep.h"
+
+GSList *nvdimm_get_device_list(void);
+#endif
diff --git a/util/Makefile.objs b/util/Makefile.objs
index 11262aafaf..6b38b67cf1 100644
--- a/util/Makefile.objs
+++ b/util/Makefile.objs
@@ -20,6 +20,7 @@ util-obj-y += envlist.o path.o module.o
 util-obj-y += host-utils.o
 util-obj-y += bitmap.o bitops.o hbitmap.o
 util-obj-y += fifo8.o
+util-obj-y += nvdimm-utils.o
 util-obj-y += cacheinfo.o
 util-obj-y += error.o qemu-error.o
 util-obj-y += qemu-print.o
diff --git a/util/nvdimm-utils.c b/util/nvdimm-utils.c
new file mode 100644
index 00..5cc768ca47
--- /dev/null
+++ b/util/nvdimm-utils.c
@@ -0,0 +1,29 @@
+#include "qemu/nvdimm-utils.h"
+#include "hw/mem/nvdimm.h"
+
+static int nvdimm_device_list(Object *obj, void *opaque)
+{
+GSList **list = opaque;
+
+if (object_dynamic_cast(obj, TYPE_NVDIMM)) {
+*list = g_slist_append(*list, DEVICE(obj));
+}
+
+object_child_foreach(obj, nvdimm_device_list, opaque);
+return 0;
+}
+
+/*
+ * inquire NVDIMM devices and link them into the list which is
+ * returned to the caller.
+ *
+ * Note: it is the caller's responsibility to free the list to avoid
+ * memory leak.
+ */
+GSList *nvdimm_get_device_list(void)
+{
+GSList *list = NULL;
+
+object_child_foreach(qdev_get_machine(), nvdimm_device_list, );
+return list;
+}

[PATCH v6 0/4] ppc: spapr: virtual NVDIMM support

The patchset attempts to implement the virtual NVDIMM for pseries.

PAPR semantics is such that each NVDIMM device is comprising of
multiple SCM(Storage Class Memory) blocks. The hypervisor is expected
to prepare the FDT for the NVDIMM device and send guest a hotplug
interrupt with new type RTAS_LOG_V6_HP_TYPE_PMEM currently handled by
the upstream kernel. In response to that interrupt, the guest requests
the hypervisor to bind each of the SCM blocks of the NVDIMM device
using hcalls. There can be SCM block unbind requests in case of driver
errors or unplug(not supported now) use cases. The NVDIMM label
read/writes are done through hcalls.

Since each virtual NVDIMM device is divided into multiple SCM blocks,
the bind, unbind, and queries using hcalls on those blocks can come
independently. This doesnt fit well into the qemu device semantics,
where the map/unmap are done at the (whole)device/object level
granularity. The patchset uses the existing NVDIMM class structures
for the implementation. The bind/unbind is left to happen at the
device_add/del phase itself instead of at hcalls on-demand.

The guest kernel makes bind/unbind requests for the virtual NVDIMM
device at the region level granularity. Without interleaving, each
virtual NVDIMM device is presented as separate region. Hence it is
safe to do bind/unbind everything during the object_add/del.

The free device-memory region which is used for memory hotplug are
done using multiple LMBs of size(256MiB) and are expected to be
aligned to 256 MiB. As the SCM blocks are mapped to the same region,
the SCM blocks also need to be aligned to this size for the subsequent
memory hotplug to work. The minimum SCM block size is set to this size
for that reason and can be made user configurable in future if required.

The first patch moves around the existing static function to common
area for using it in the subsequent patches. Second patch adds new uuid
property to the nvdimm device. Third patch adds FDT entries and basic
device support, the fourth patch adds the hcalls implementation.

The patches are also available at
https://github.com/ShivaprasadGBhat/qemu.git - pseries-nvdimm-v6 branch
and can be used with the upstream kernel. ndctl can be used for
configuring the nvdimms inside the guest.
This is how it can be used ..
Ex :
For coldplug, the device to be added in qemu command line as shown below
-object
memory-backend-file,id=memnvdimm0,prealloc=yes,mem-path=/tmp/nvdimm0,share=yes,size=1073872896
-device
nvdimm,label-size=128k,uuid=75a3cdd7-6a2f-4791-8d15-fe0a920e8e9e,memdev=memnvdimm0,id=nvdimm0,slot=0

For hotplug, the device to be added from monitor as below
object_add
memory-backend-file,id=memnvdimm0,prealloc=yes,mem-path=/tmp/nvdimm0,share=yes,size=1073872896
device_add
nvdimm,label-size=128k,uuid=75a3cdd7-6a2f-4791-8d15-fe0a920e8e9e,memdev=memnvdimm0,id=nvdimm0,slot=0

---
v5: https://lists.nongnu.org/archive/html/qemu-devel/2020-01/msg07472.html
Changes from v5:
- Moved most of the nvdimm code from spapr.c to spapr_nvdimm.c
- Addressed all style/logic comments.
v4: https://lists.gnu.org/archive/html/qemu-devel/2019-12/msg03455.html
Changes from v4:
- The nvdimm occupied GPA area is marked as available for hotplug, the
existing code takes care of if the dimm device is actually present there
or used by nvdimm.
- fixed all comments for hcall implementation code on style/logic issues.
v3: https://lists.gnu.org/archive/html/qemu-devel/2019-10/msg03452.html
Changes from v3:
- Moved NVDIMM uuid property addition to new patch.
- Moved the SCM hcalls to new file
- Changed the metadata read/write hcalls to use st/ldX_be_p macros.
- Fixed all comments on v3
v2: https://lists.gnu.org/archive/html/qemu-devel/2019-05/msg02785.html
Changes from v2:
- Creating the drc indices for the nvdimm devices in advance as
suggested based on the number of user specified max slots property.
- Removed the hard dependency on -machine nvdimm=on, enabled by
default on the current latest pseries machine version.
- Renamed the functions to spapr_dt_X as suggested.
- Metadata is byteswapped before read/write to take care of endianness
semantics during the hcall.
v1 : http://lists.nongnu.org/archive/html/qemu-devel/2019-02/msg01545.html
Changes from v1:
- Rebased to upstream, this required required dt_populate implementation
for nvdimm hotplug support
- Added uuid option to nvdimm device
- Removed the memory region sizing down code as suggested by Igor,
now erroring out if NVDIMM size excluding the label area is not
aligned to 256MB, so patch 2 from previous series no longer needed.
- Removed un-implemented hcalls
- Changed the hcalls to different kinds of checks and return
different values.
- Addressed comments for v1
---

Shivaprasad G Bhat (4):
mem: move nvdimm_device_list to utilities
nvdimm: add uuid property to

Re: [PATCH v5 3/4] spapr: Add NVDIMM device support




On 02/04/2020 09:29 AM, David Gibson wrote:

On Thu, Jan 30, 2020 at 05:48:15AM -0600, Shivaprasad G Bhat wrote:

Add support for NVDIMM devices for sPAPR. Piggyback on existing nvdimm
device interface in QEMU to support virtual NVDIMM devices for Power.
Create the required DT entries for the device (some entries have
dummy values right now).

The patch creates the required DT node and sends a hotplug
interrupt to the guest. Guest is expected to undertake the normal
DR resource add path in response and start issuing PAPR SCM hcalls.

+   " must be a multiple of %" PRIu64 "MB",
+   SPAPR_MINIMUM_SCM_BLOCK_SIZE / MiB);
+return;
+}
+
+uuidstr = object_property_get_str(OBJECT(dimm), NVDIMM_UUID_PROP, 
NULL);
+qemu_uuid_parse(uuidstr, );

Uh.. couldn't we just look at nvdimm->uuid, rather than getting the
string property and parsing it again?


Addressing all except this one as discussed. Posting the next version in 
a while.


Thanks,
Shivaprasad

RE: [PATCH] Add support for a helper with 7 arguments

2020-02-09 Thread Taylor Simpson

> -Original Message-
> From: Taylor Simpson
> Sent: Sunday, February 9, 2020 2:51 PM
> To: Richard Henderson ; Richard Henderson
> ; qemu-devel@nongnu.org
> Cc: Paolo Bonzini 
> Subject: RE: [PATCH] Add support for a helper with 7 arguments
>
> > However, you should prefer to use tcg_gen_addi_* over tcg_gen_add_*
> > (etc) when
> > you know that one operand is constant.  This will optimize away the add
> zero
> > immediately as opposed to allocating memory and walking the data
> > structures to
> > eliminate it later.
>
> OK, will work on this.
>

One question I have from implementing this is
- Is there a way to pass a constant value to gen_helper_XXX?
It would be great if this would be possible instead of calling tcg_const_tl() 
and passing the TCGv.

AFAICT, the DEF_HELPER macros don't have an operand type that takes a constant. 
 I think s32, i32, and int all expect TCGv at the call site.

Thanks,
Taylor

Re: [PATCH 00/29] Convert QAPI doc comments to generate rST instead of texinfo

2020-02-09 Thread Aleksandar Markovic

On Thursday, February 6, 2020, Peter Maydell 
wrote:

>
> > This series switches all our QAPI doc > > > comments over from
> > texinfo format to rST.
>
>
Regardeless of the outcome of the discussions over this series, I just want
to say that I support it as a potential user of the document (there is no
"Supported-by:" mark or similar, so this is all I can do). Also, as a
general participant in QEMU community,  I seems to me this is a significant
step in shaping up QEMU documentation.

Best regards,
Aleksandar



>
>

Re: VW ELF loader

2020-02-09 Thread Alexey Kardashevskiy




On 07/02/2020 10:46, Paolo Bonzini wrote:
> On 07/02/20 00:23, Alexey Kardashevskiy wrote:
>>> Right, not unlike what you get with vof=on. :)  I'm not against at all
>>> that idea.  I just don't understand what you refer to below as (2).
>>> Does petitboot not have the problem because it kexecs the new kernel?
>>
>> Petitboot does not have this problem *if* it runs without SLOF, i.e.
>> directly via -kernel and -initrd and uses OF CI (cut down version, about
>> v3-v4 of my patchset, without block devices and grub lookup). In this
>> case there is one device tree instance, fully synchronized with the
>> machine state.
>>
>> If there is still SLOF and (2) is happening, then petitboot is screwed
>> as any other kernel.
> 
> Ok, so "minimal pseudo-OpenFirmware in QEMU" is doable and can get
> everything right;

I am not convinced that ditching drivers is not right; I am moving elf +
mbr + gpt + grub loading to the guest though so 20 bytes blob becomes
FDT-less firmmare, a few kbytes big.

> it's just work to set up PCI and do all that other
> do_driver_stuff(), so you can either do it yourself or use
> Linux+petitboot.  Is this correct?

Except using the "just" word, yes, correct ;)

> Also, can a normal distro kernel run via -kernel/-initrd + the minimal
> firmware in QEMU?

Yes.


-- 
Alexey

Re: [PATCH v3 0/7] Some cleanup in arm/virt/acpi

2020-02-09 Thread Heyi Guo


Hi Peter,

Do you have any other comments? If not, could you help to merge into 
your tree?


Thanks,

Heyi

On 2020/2/4 9:43, Heyi Guo wrote:

Remove conflict _ADR objects, and fix and refine PCI device definition in
ACPI/DSDT.

History:

v3 -> v2:
- update commit message for patch 4/7.
- remove diff keywords in commit message of patch 7/7 to avoid applying patch
   failure.

v1 -> v2:
- flow the work flow in tests/qtest/bios-table-test.c to post ACPI related
   patches.
- update commit messages for removing "RP0" and "_ADR".
- add 3 more cleanup patches.

Cc: Peter Maydell 
Cc: "Michael S. Tsirkin" 
Cc: Igor Mammedov 
Cc: Shannon Zhao 
Cc: qemu-...@nongnu.org
Cc: qemu-devel@nongnu.org

Heyi Guo (7):
   bios-tables-test: prepare to change ARM virt ACPI DSDT
   arm/virt/acpi: remove meaningless sub device "RP0" from PCI0
   arm/virt/acpi: remove _ADR from devices identified by _HID
   arm/acpi: fix PCI _PRT definition
   arm/acpi: fix duplicated _UID of PCI interrupt link devices
   arm/acpi: simplify the description of PCI _CRS
   virt/acpi: update golden masters for DSDT update

  hw/arm/virt-acpi-build.c  |  25 ++---
  tests/data/acpi/virt/DSDT | Bin 18462 -> 5307 bytes
  tests/data/acpi/virt/DSDT.memhp   | Bin 19799 -> 6644 bytes
  tests/data/acpi/virt/DSDT.numamem | Bin 18462 -> 5307 bytes
  4 files changed, 6 insertions(+), 19 deletions(-)

Re: [PATCH v3 02/13] hw/arm/raspi: Correct the board descriptions

2020-02-09 Thread Philippe Mathieu-Daudé

On 2/9/20 11:51 PM, Niek Linnenbank wrote:
> Hi Philippe,
> 
> 
> On Sat, Feb 8, 2020 at 5:57 PM Philippe Mathieu-Daudé  > wrote:
> 
> We hardcode the board revision as 0xa21041 for the raspi2, and
> 0xa02082 for the raspi3:
> 
>   166 static void raspi_init(MachineState *machine, int version)
>   167 {
>   ...
>   194     int board_rev = version == 3 ? 0xa02082 : 0xa21041;
> 
> These revision codes are for the 2B and 3B models, see:
> 
> https://www.raspberrypi.org/documentation/hardware/raspberrypi/revision-codes/README.md
> 
> Correct the board description.
> 
> Signed-off-by: Philippe Mathieu-Daudé  >
> ---
>  hw/arm/raspi.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/hw/arm/raspi.c b/hw/arm/raspi.c
> index f2ccabc662..818146fdbb 100644
> --- a/hw/arm/raspi.c
> +++ b/hw/arm/raspi.c
> @@ -221,7 +221,7 @@ static void raspi2_init(MachineState *machine)
> 
>  static void raspi2_machine_init(MachineClass *mc)
>  {
> -    mc->desc = "Raspberry Pi 2";
> +    mc->desc = "Raspberry Pi 2B";
>      mc->init = raspi2_init;
>      mc->block_default_type = IF_SD;
>      mc->no_parallel = 1;
> @@ -243,7 +243,7 @@ static void raspi3_init(MachineState *machine)
> 
>  static void raspi3_machine_init(MachineClass *mc)
>  {
> -    mc->desc = "Raspberry Pi 3";
> +    mc->desc = "Raspberry Pi 3B";
> 
> 
> Could this patch be replaced by patch #11 "hw/arm/raspi: Extract the
> board model from the board revision"?

It has to be changed before patch #8, and while patch #8 is tiny, it is
complex. I prefer to keep #8 as simple as possible, by making this
trivial change first (I don't want to do 2 different changes in the same
patch). If you want I can move this #2 as #7 just before #8, but I'm not
sure this makes things clearer.
> 
>      mc->init = raspi3_init;
>      mc->block_default_type = IF_SD;
>      mc->no_parallel = 1;
> -- 
> 2.21.1
> 
> 
> 
> -- 
> Niek Linnenbank
>

Re: [PATCH v3 01/13] hw/arm/raspi: Use BCM2708 machine type with pre Device Tree kernels

2020-02-09 Thread Niek Linnenbank

On Sat, Feb 8, 2020 at 5:57 PM Philippe Mathieu-Daudé 
wrote:

> When booting without device tree, the Linux kernels uses the $R1
> register to determine the machine type. The list of values is
> registered at [1].
>
> There are two entries for the Raspberry Pi:
>
> - https://www.arm.linux.org.uk/developer/machines/list.php?mid=3138
>   name: MACH_TYPE_BCM2708
>   value: 0xc42 (3138)
>   status: Active, not mainlined
>   date: 15 Oct 2010
>
> - https://www.arm.linux.org.uk/developer/machines/list.php?mid=4828
>   name: MACH_TYPE_BCM2835
>   value: 4828
>   status: Active, mainlined
>   date: 6 Dec 2013
>
> QEMU always used the non-mainlined type MACH_TYPE_BCM2708.
> The value 0xc43 is registered to 'MX51_GGC' (processor i.MX51), and
> 0xc44 to 'Western Digital Sharespace NAS' (processor Marvell 88F5182).
>
> The Raspberry Pi foundation bootloader only sets the BCM2708 machine
> type, see [2] or [3]:
>
>  133 9:
>  134 mov r0, #0
>  135 ldr r1, =3138   @ BCM2708 machine id
>  136 ldr r2, atags   @ ATAGS
>  137 bx  r4
>
> U-Boot only uses MACH_TYPE_BCM2708 (see [4]):
>
>  25 /*
>  26  * 2835 is a SKU in a series for which the 2708 is the first or
> primary SoC,
>  27  * so 2708 has historically been used rather than a dedicated 2835 ID.
>  28  *
>  29  * We don't define a machine type for bcm2709/bcm2836 since the RPi
> Foundation
>  30  * chose to use someone else's previously registered machine ID (3139,
> MX51_GGC)
>  31  * rather than obtaining a valid ID:-/
>  32  *
>  33  * For the bcm2837, hopefully a machine type is not needed, since
> everything
>  34  * is DT.
>  35  */
>
> While the definition MACH_BCM2709 with value 0xc43 was introduced in
> a commit described "Add 2709 platform for Raspberry Pi 2" out of the
> mainline Linux kernel, it does not seem used, and the platform is
> introduced with Device Tree support anyway (see [5] and [6]).
>
> Remove the unused values (0xc43 introduced in commit 1df7d1f9303aef
> "raspi: add raspberry pi 2 machine" and 0xc44 in commit bade58166f4
> "raspi: Raspberry Pi 3 support"), keeping only MACH_TYPE_BCM2708.
>
> [1] https://www.arm.linux.org.uk/developer/machines/
> [2]
> https://github.com/raspberrypi/tools/blob/920c7ed2e/armstubs/armstub7.S#L135
> [3]
> https://github.com/raspberrypi/tools/blob/49719d554/armstubs/armstub7.S#L64
> [4]
> https://gitlab.denx.de/u-boot/u-boot/blob/v2015.04/include/configs/rpi-common.h#L18
> [5]
> https://github.com/raspberrypi/linux/commit/d9fac63adac#diff-6722037d79570df5b392a49e0e006573R526
> [6]
> http://lists.infradead.org/pipermail/linux-rpi-kernel/2015-February/001268.html
>
> Cc: Zoltán Baldaszti 
> Cc: Pekka Enberg 
> Cc: Stephen Warren 
> Cc: Kshitij Soni 
> Cc: Michael Chan 
> Cc: Andrew Baumann 
> Reviewed-by: Alistair Francis 
> Signed-off-by: Philippe Mathieu-Daudé 
>

Reviewed-by: Niek Linnenbank 


> ---
> v3: Improved MACH_TYPE_BCM2708 comment (Zoltán)
> ---
>  hw/arm/raspi.c | 6 +++---
>  1 file changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/hw/arm/raspi.c b/hw/arm/raspi.c
> index 3996f6c63a..f2ccabc662 100644
> --- a/hw/arm/raspi.c
> +++ b/hw/arm/raspi.c
> @@ -29,8 +29,8 @@
>  #define FIRMWARE_ADDR_3 0x8 /* Pi 3 loads kernel.img here by default
> */
>  #define SPINTABLE_ADDR  0xd8 /* Pi 3 bootloader spintable */
>
> -/* Table of Linux board IDs for different Pi versions */
> -static const int raspi_boardid[] = {[1] = 0xc42, [2] = 0xc43, [3] =
> 0xc44};
> +/* Registered machine type (matches RPi Foundation bootloader and U-Boot)
> */
> +#define MACH_TYPE_BCM2708   3138
>
>  typedef struct RasPiState {
>  BCM283XState soc;
> @@ -116,7 +116,7 @@ static void setup_boot(MachineState *machine, int
> version, size_t ram_size)
>  static struct arm_boot_info binfo;
>  int r;
>
> -binfo.board_id = raspi_boardid[version];
> +binfo.board_id = MACH_TYPE_BCM2708;
>  binfo.ram_size = ram_size;
>  binfo.nb_cpus = machine->smp.cpus;
>
> --
> 2.21.1
>
>

-- 
Niek Linnenbank

Re: [PATCH v3 02/13] hw/arm/raspi: Correct the board descriptions

2020-02-09 Thread Niek Linnenbank

Hi Philippe,


On Sat, Feb 8, 2020 at 5:57 PM Philippe Mathieu-Daudé 
wrote:

> We hardcode the board revision as 0xa21041 for the raspi2, and
> 0xa02082 for the raspi3:
>
>   166 static void raspi_init(MachineState *machine, int version)
>   167 {
>   ...
>   194 int board_rev = version == 3 ? 0xa02082 : 0xa21041;
>
> These revision codes are for the 2B and 3B models, see:
>
> https://www.raspberrypi.org/documentation/hardware/raspberrypi/revision-codes/README.md
>
> Correct the board description.
>
> Signed-off-by: Philippe Mathieu-Daudé 
> ---
>  hw/arm/raspi.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/hw/arm/raspi.c b/hw/arm/raspi.c
> index f2ccabc662..818146fdbb 100644
> --- a/hw/arm/raspi.c
> +++ b/hw/arm/raspi.c
> @@ -221,7 +221,7 @@ static void raspi2_init(MachineState *machine)
>
>  static void raspi2_machine_init(MachineClass *mc)
>  {
> -mc->desc = "Raspberry Pi 2";
> +mc->desc = "Raspberry Pi 2B";
>  mc->init = raspi2_init;
>  mc->block_default_type = IF_SD;
>  mc->no_parallel = 1;
> @@ -243,7 +243,7 @@ static void raspi3_init(MachineState *machine)
>
>  static void raspi3_machine_init(MachineClass *mc)
>  {
> -mc->desc = "Raspberry Pi 3";
> +mc->desc = "Raspberry Pi 3B";
>

Could this patch be replaced by patch #11 "hw/arm/raspi: Extract the board
model from the board revision"?

Regards,
Niek


>  mc->init = raspi3_init;
>  mc->block_default_type = IF_SD;
>  mc->no_parallel = 1;
> --
> 2.21.1
>
>

-- 
Niek Linnenbank

Re: [PATCH v14 08/11] virtio-iommu-pci: Introduce the x-dt-binding option

2020-02-09 Thread Michael S. Tsirkin

On Fri, Feb 07, 2020 at 06:04:05PM -0500, Peter Xu wrote:
> On Fri, Feb 07, 2020 at 05:24:54AM -0500, Michael S. Tsirkin wrote:
> > On Fri, Feb 07, 2020 at 11:05:40AM +0100, Jean-Philippe Brucker wrote:
> > > Hi Eric,
> > > 
> > > On Fri, Feb 07, 2020 at 10:32:00AM +0100, Eric Auger wrote:
> > > > At the moment, the kernel only supports device tree
> > > > integration of the virtio-iommu. DT bindings between the
> > > > PCI root complex and the IOMMU must be created by the machine
> > > > in conformance to:
> > > > 
> > > > Documentation/devicetree/bindings/virtio/iommu.txt.
> > > > 
> > > > To make sure the end-user is aware of this, force him to use the
> > > > temporary device option "x-dt-binding" and also double check the
> > > > machine has a hotplug handler for the virtio-iommu-pci device.
> > > > This hotplug handler is in charge of creating those DT bindings.
> > > > 
> > > > Signed-off-by: Eric Auger 
> > > > Suggested-by: Michael S. Tsirkin 
> > > [...]
> > > > @@ -39,6 +42,21 @@ static void virtio_iommu_pci_realize(VirtIOPCIProxy 
> > > > *vpci_dev, Error **errp)
> > > >  VirtIOIOMMUPCI *dev = VIRTIO_IOMMU_PCI(vpci_dev);
> > > >  DeviceState *vdev = DEVICE(>vdev);
> > > >  
> > > > +if (!dev->dt_binding) {
> > > > +error_setg(errp,
> > > > +   "Instantiation currently only is possible if the 
> > > > machine "
> > > > +   "creates device tree iommu-map bindings, ie. ACPI 
> > > > is not "
> > > > +   "yet supported");
> > > > +error_append_hint(errp, "use 
> > > > -virtio-iommu-pci,x-dt-binding\n");
> > > 
> > > "use -device virtio-iommu-pci,x-dt-binding"?
> > > 
> > > Can the option be safely removed as soon as we implement a topology
> > > description for the remaining platforms?  Or will we need to carry it
> > > forever for backward-compatibility (ie. ensure that an old command-line
> > > invocation that contains this option still works)?
> > > 
> > > Thanks,
> > > Jean
> > 
> > I'd worry that if we actually document it then users will come to
> > depend on it for sure, even though it starts with x-.
> 
> I thought x- parameters can be dropped directly with totally no
> grarantee...  Otherwise how do we differenciate x- with the common
> parameters, and how do we introduce remove-prone parameters?
> 
> Thanks,

It's all about not breaking users. Yes we document that x-
interfaces are unstable. But that documentation is only 
good for well-behaved users such as libvirt. End-users
tend not to read the docs and the subtleties of
stable/unstable interface are lost on them, so we really must never
actively ask end users to set an x- flag.


> -- 
> Peter Xu

RE: [PATCH] Add support for a helper with 7 arguments

2020-02-09 Thread Taylor Simpson



> -Original Message-
> From: Richard Henderson 
> Sent: Sunday, February 9, 2020 12:18 PM
> To: Taylor Simpson ; Richard Henderson
> ; qemu-devel@nongnu.org
> Cc: Paolo Bonzini 
> Subject: Re: [PATCH] Add support for a helper with 7 arguments
> We can optimize them.
>
> However, you should prefer to use tcg_gen_addi_* over tcg_gen_add_*
> (etc) when
> you know that one operand is constant.  This will optimize away the add zero
> immediately as opposed to allocating memory and walking the data
> structures to
> eliminate it later.

OK, will work on this.

>
> Why are you using a local temporary for EA?  That should be dead
> immediately
> after this slot is complete.

The declaration of EA is added by the generator.  It's declared as a local temp 
to be conservative in case there is control flow.  I'll work on making the 
generator smarter.  I think it will work to check if the instruction is 
predicated and use a temp if it isn't.


>
> What's with two temporaries both named "new_value"?
>

It's actually an array that parallels the GPRs.  I'm just passing the same 
string to each call to tcg_global_mem_new.  I'll change it to be a unique 
string for each.

> >> For a conditional load in slot 0, we can load directly into the final
> >> destination register and skip the temporary.
> >
> > In general, there will be lots of checks we would need to perform before
> > concluding that an instruction can write directly into the destination.  For
> > example, we have to make sure no other instruction later in the packet
> reads
> > r7.
>
> Which is of course all trivial for slot 0, being last.

Slot 0 might be last in the encoding, but that doesn't mean it is the last one 
to execute.  Remember that the packet gets reordered before TCG generation so 
that .new definitions are before their uses.  So, if the result of the slot 0 
instruction is used by a .new reference, it won't be last.

Re: [PATCH 01/17] qcow2: Comment typo fixes

2020-02-09 Thread Alberto Garcia

On Fri 31 Jan 2020 06:44:20 PM CET, Eric Blake wrote:
> Various trivial typos noticed while working on this file.
>
> Signed-off-by: Eric Blake 

Reviewed-by: Alberto Garcia 

Berto

Re: [PATCH 03/17] qcow2: Avoid feature name extension on small cluster size

2020-02-09 Thread Alberto Garcia

On Fri 31 Jan 2020 06:44:22 PM CET, Eric Blake wrote:
> As the feature name table can be quite large (over 9k if all 64 bits
> of all three feature fields have names; a mere 8 features leaves only
> 8 bytes for a backing file name in a 512-byte cluster), it is unwise
> to emit this optional header in images with small cluster sizes.
>
> Update iotest 036 to skip running on small cluster sizes; meanwhile,
> note that iotest 061 never passed on alternative cluster sizes
> (however, I limited this patch to tests with output affected by adding
> feature names, rather than auditing for other tests that are not
> robust to alternative cluster sizes).
>
> Signed-off-by: Eric Blake 

Reviewed-by: Alberto Garcia 

Berto

Re: [PATCH v1 1/5] docs/devel: document query handle lifetimes

2020-02-09 Thread Richard Henderson

On 2/7/20 3:01 PM, Alex Bennée wrote:
> I forgot to document the lifetime of handles in the developer
> documentation. Do so now.
> 
> Signed-off-by: Alex Bennée 
> ---
>  docs/devel/tcg-plugins.rst | 13 +++--
>  1 file changed, 11 insertions(+), 2 deletions(-)

Reviewed-by: Richard Henderson 


r~

Re: [PATCH] Add support for a helper with 7 arguments

2020-02-09 Thread Richard Henderson

On 2/8/20 5:08 AM, Taylor Simpson wrote:
>> {
>>   r6 = memb(r1)
>>   r7 = memb(r2)
>> }
>>
>> qemu_ld   t0, r1, MO_UB, mmu_idx
>> qemu_ld   t1, r2, MO_UB, mmu_idx
>> mov   r6, t0
>> mov   r7, t1
>>
> 
> Here is the TCG we generate currently.
>  movi_i32 tmp0,$0x0
>  add_i32 loc2,r1,tmp0
>  qemu_ld_i32 loc3,loc2,sb,0
>  mov_i32 new_value,loc3
>  movi_i32 tmp0,$0x0
>  add_i32 loc2,r2,tmp0
>  qemu_ld_i32 loc3,loc2,sb,0
>  mov_i32 new_value,loc3
>  mov_i32 r6,new_value
>  mov_i32 r7,new_value
> I could work on eliminating the add of zero and the extra copies.  Is TCG
> able to optimize these before emitting the host code?
We can optimize them.

However, you should prefer to use tcg_gen_addi_* over tcg_gen_add_* (etc) when
you know that one operand is constant.  This will optimize away the add zero
immediately as opposed to allocating memory and walking the data structures to
eliminate it later.

Why are you using a local temporary for EA?  That should be dead immediately
after this slot is complete.

What's with two temporaries both named "new_value"?

>> For a conditional load in slot 0, we can load directly into the final
>> destination register and skip the temporary.
> 
> In general, there will be lots of checks we would need to perform before
> concluding that an instruction can write directly into the destination.  For
> example, we have to make sure no other instruction later in the packet reads
> r7.

Which is of course all trivial for slot 0, being last.

r~

[PATCH] block/vvfat: Do not unref qcow on closing backing bdrv

2020-02-09 Thread Hikaru Nishida

Before this commit, BDRVVVFATState.qcow is unrefed in write_target_close
on closing backing bdrv of vvfat. However, qcow bdrv is opend as a child
of vvfat in enable_write_target() so it will be also unrefed on closing
vvfat itself. This causes use-after-free of qcow on freeing vvfat which
has backing bdrv and qcow bdrv as children in this order because
bdrv_close(vvfat) tries to free qcow bdrv after freeing backing bdrv
as QLIST_FOREACH_SAFE() loop keeps next pointer, but BdrvChild of qcow
is already freed in bdrv_close(backing bdrv).

Signed-off-by: Hikaru Nishida 
---
 block/vvfat.c | 7 ---
 1 file changed, 7 deletions(-)

diff --git a/block/vvfat.c b/block/vvfat.c
index 019b8f1341..ab800c4887 100644
--- a/block/vvfat.c
+++ b/block/vvfat.c
@@ -3124,17 +3124,10 @@ write_target_commit(BlockDriverState *bs, uint64_t 
offset, uint64_t bytes,
 return ret;
 }
 
-static void write_target_close(BlockDriverState *bs) {
-BDRVVVFATState* s = *((BDRVVVFATState**) bs->opaque);
-bdrv_unref_child(s->bs, s->qcow);
-g_free(s->qcow_filename);
-}
-
 static BlockDriver vvfat_write_target = {
 .format_name= "vvfat_write_target",
 .instance_size  = sizeof(void*),
 .bdrv_co_pwritev= write_target_commit,
-.bdrv_close = write_target_close,
 };
 
 static void vvfat_qcow_options(int *child_flags, QDict *child_options,
-- 
2.21.0 (Apple Git-122.2)

Re: [PATCH v4 53/80] mips/mips_jazz: use memdev for RAM

2020-02-09 Thread Philippe Mathieu-Daudé

On 1/31/20 4:09 PM, Igor Mammedov wrote:
> memory_region_allocate_system_memory() API is going away, so
> replace it with memdev allocated MemoryRegion. The later is
> initialized by generic code, so board only needs to opt in
> to memdev scheme by providing
>   MachineClass::default_ram_id
> and using MachineState::ram instead of manually initializing
> RAM memory region.

FYI Jazz can not have more than 256MB of DRAM.

> 
> Signed-off-by: Igor Mammedov 
> Reviewed-by: Philippe Mathieu-Daudé 
> ---
>  hw/mips/mips_jazz.c | 7 +++
>  1 file changed, 3 insertions(+), 4 deletions(-)
> 
> diff --git a/hw/mips/mips_jazz.c b/hw/mips/mips_jazz.c
> index 66fd4d8..85d49cf 100644
> --- a/hw/mips/mips_jazz.c
> +++ b/hw/mips/mips_jazz.c
> @@ -159,7 +159,6 @@ static void mips_jazz_init(MachineState *machine,
>  ISABus *isa_bus;
>  ISADevice *pit;
>  DriveInfo *fds[MAX_FD];
> -MemoryRegion *ram = g_new(MemoryRegion, 1);
>  MemoryRegion *bios = g_new(MemoryRegion, 1);
>  MemoryRegion *bios2 = g_new(MemoryRegion, 1);
>  SysBusESPState *sysbus_esp;
> @@ -191,9 +190,7 @@ static void mips_jazz_init(MachineState *machine,
>  cc->do_transaction_failed = mips_jazz_do_transaction_failed;
>  
>  /* allocate RAM */
> -memory_region_allocate_system_memory(ram, NULL, "mips_jazz.ram",
> - machine->ram_size);
> -memory_region_add_subregion(address_space, 0, ram);
> +memory_region_add_subregion(address_space, 0, machine->ram);
>  
>  memory_region_init_ram(bios, NULL, "mips_jazz.bios", MAGNUM_BIOS_SIZE,
> _fatal);
> @@ -393,6 +390,7 @@ static void mips_magnum_class_init(ObjectClass *oc, void 
> *data)
>  mc->init = mips_magnum_init;
>  mc->block_default_type = IF_SCSI;
>  mc->default_cpu_type = MIPS_CPU_TYPE_NAME("R4000");
> +mc->default_ram_id = "mips_jazz.ram";
>  }
>  
>  static const TypeInfo mips_magnum_type = {
> @@ -409,6 +407,7 @@ static void mips_pica61_class_init(ObjectClass *oc, void 
> *data)
>  mc->init = mips_pica61_init;
>  mc->block_default_type = IF_SCSI;
>  mc->default_cpu_type = MIPS_CPU_TYPE_NAME("R4000");
> +mc->default_ram_id = "mips_jazz.ram";
>  }
>  
>  static const TypeInfo mips_pica61_type = {
>

Question: SiFive U SPI and SD

2020-02-09 Thread Nikita Ermakov

Hello!

I am trying to make an SD card working on the sifive_u
(hw/riscv/sifive_u.c) SoC machine.
As far as I understand there is no way to connect an SD card to the SoC
with cmdline for now. So, I started to dig in to the QEMU internals and
especially sifive_u SoC implementation to try to understand how I could
connect SD card to this SoC.

>From what I understood I need to:
1) Implement SiFive U SPI controller.
2) Implement spi-sd adapter in a way like the hw/sd/ssi-sd.c

Probably I should merge 1) and 2) into one hw/riscv/sifive_u_spi.c source
file.

Could somebody correct me please if I am wrong at some point?
I am newbie in the QEMU internals :)

The purpose is why I want to implement this is to boot up the Linux kernel
on '-machine sifive_u' and load rootfs from SD.

-- 
Thanks,
Nikita
B8 00 4C CD 21

Re: [PATCH 1/2] spapr: Disable legacy virtio devices for pseries-5.0 and later