Re: [Qemu-devel] Minutes of KVM Forum BoF on deprecating stuff

2018-10-27 Thread Markus Armbruster
Daniel P. Berrangé  writes:

> On Fri, Oct 26, 2018 at 04:03:51PM +0200, Markus Armbruster wrote:
>> This is from my (imperfect) notes, corrections welcome.
>> 
>> Motivation: QEMU contains stuff of dubious value, which gets in the way
>> in various (sometimes painful and expensive) ways.
>>
>> Deprecation is the marking of an external interface as "we intend to
>> remove this, you should stop using it" (preferably with advice on what
>> to use instead).  We have a deprecation policy to guide us through this
>> process.
>
>
> Something I meant to bring up but forgot is about the classification
> of devices, especially with a view towards security. It is not directly
> about deprecation, but it is somewhat related as it is related  to the
> state of maintainence and quality level
>
> We've got alot of devices, but only a subset are written and maintained
> to a level where we'd consider them robust wrt malcious guests. Other
> devices are only suitable for friendly guest environments. We should
> clearly document which are the devices that we consider to provide
> a secure boundary to guests, so users can make suitably informed choices.
> I'd guess this means all virtio devices, and then few of the emulated
> devices that are commonly used & maintained in a KVM environment.

A machine whose mandatory devices don't all provide a security boundary
also doesn't provide one.  Thus, classification of devices leads to a
classification of machines.

> This would be useful for distros/vendors/users who wish to limit their
> potential attack surface once we have a KConfig system for fine grained
> disablement of features.

Yes.



Re: [Qemu-devel] [PATCH 04/10] cputlb: Split large page tracking per mmu_idx

2018-10-27 Thread Richard Henderson
On 10/27/18 1:16 AM, Emilio G. Cota wrote:
> On Tue, Oct 23, 2018 at 08:02:47 +0100, Richard Henderson wrote:
>> +static void tlb_flush_page_locked(CPUArchState *env, int midx,
>> +  target_ulong addr)
>> +{
>> +target_ulong lp_addr = env->tlb_d[midx].large_page_addr;
>> +target_ulong lp_mask = env->tlb_d[midx].large_page_mask;
>> +
>> +/* Check if we need to flush due to large pages.  */
>> +if ((addr & lp_mask) == lp_addr) {
>> +tlb_debug("forcing full flush midx %d ("
>> +  TARGET_FMT_lx "/" TARGET_FMT_lx ")\n",
>> +  midx, lp_addr, lp_mask);
>> +tlb_flush_one_mmuidx_locked(env, midx);
>> +} else {
>> +int pidx = (addr >> TARGET_PAGE_BITS) & (CPU_TLB_SIZE - 1);
>> +tlb_flush_entry_locked(>tlb_table[midx][pidx], addr);
>> +tlb_flush_vtlb_page_locked(env, midx, addr);
> 
> Just noticed that we should use tlb_entry here, e.g.:
> 
>  } else {
> -int pidx = (addr >> TARGET_PAGE_BITS) & (CPU_TLB_SIZE - 1);
> -tlb_flush_entry_locked(>tlb_table[midx][pidx], addr);
> +CPUTLBEntry *entry = tlb_entry(env, midx, addr);
> +
> +tlb_flush_entry_locked(entry, addr);
>  tlb_flush_vtlb_page_locked(env, midx, addr);
>  }

Fixed, thanks.

r~



Re: [Qemu-devel] [PULL v2 00/28] pci, pc, virtio: fixes, features

2018-10-27 Thread Peter Maydell
On 26 October 2018 at 03:00, Michael S. Tsirkin  wrote:
> OK  I fixed 32 bit issues. Could not reproduce the test issues,
> could it be that it was a side effect of build issues maybe?
>
> Could you retyr?
> If it still ails I will drop the test for now.

Compiles OK, but still asserts
ERROR:/home/pm215/qemu/tests/bios-tables-test.c:398:load_expected_aml: assertion
 failed: (exp_sdt.aml_file)

on Linux/aarch64, Linux/arm32, Linux/SPARC, Linux/s390x.

pm215@gcc113:~/qemu/build/all$
QTEST_QEMU_BINARY=i386-softmmu/qemu-system-i386
./tests/bios-tables-test
/i386/acpi/piix4: OK
/i386/acpi/q35: ^[[AOK
/i386/acpi/piix4/bridge: OK
/i386/acpi/piix4/ipmi: OK
/i386/acpi/piix4/cpuhp: OK
/i386/acpi/piix4/memhp: OK
/i386/acpi/piix4/numamem: OK
/i386/acpi/piix4/dimmpxm: OK
/i386/acpi/q35/bridge: OK
/i386/acpi/q35/mmio64: **
ERROR:/home/pm215/qemu/tests/bios-tables-test.c:398:load_expected_aml:
assertion failed: (exp_sdt.aml_file)
Aborted (core dumped)

With V=1 it says
/i386/acpi/q35/mmio64:
Looking for expected file 'tests/acpi-test-data/q35/DSDT.mmio64'

Looking for expected file 'tests/acpi-test-data/q35/DSDT'

Using expected file 'tests/acpi-test-data/q35/DSDT'

Looking for expected file 'tests/acpi-test-data/q35/FACP.mmio64'

Looking for expected file 'tests/acpi-test-data/q35/FACP'

Using expected file 'tests/acpi-test-data/q35/FACP'

Looking for expected file 'tests/acpi-test-data/q35/APIC.mmio64'

Looking for expected file 'tests/acpi-test-data/q35/APIC'

Using expected file 'tests/acpi-test-data/q35/APIC'

Looking for expected file 'tests/acpi-test-data/q35/HPET.mmio64'

Looking for expected file 'tests/acpi-test-data/q35/HPET'

Using expected file 'tests/acpi-test-data/q35/HPET'

Looking for expected file 'tests/acpi-test-data/q35/SRAT.mmio64'

Looking for expected file 'tests/acpi-test-data/q35/SRAT'
**
ERROR:/home/pm215/qemu/tests/bios-tables-test.c:398:load_expected_aml:
assertion failed: (exp_sdt.aml_file)

ET'

On an x86-64 host which works it says
/i386/acpi/q35/mmio64:
Looking for expected file 'tests/acpi-test-data/q35/DSDT.mmio64'

Using expected file 'tests/acpi-test-data/q35/DSDT.mmio64'

Looking for expected file 'tests/acpi-test-data/q35/FACP.mmio64'

Looking for expected file 'tests/acpi-test-data/q35/FACP'

Using expected file 'tests/acpi-test-data/q35/FACP'

Looking for expected file 'tests/acpi-test-data/q35/APIC.mmio64'

Looking for expected file 'tests/acpi-test-data/q35/APIC'

Using expected file 'tests/acpi-test-data/q35/APIC'

Looking for expected file 'tests/acpi-test-data/q35/HPET.mmio64'

Looking for expected file 'tests/acpi-test-data/q35/HPET'

Using expected file 'tests/acpi-test-data/q35/HPET'

Looking for expected file 'tests/acpi-test-data/q35/SRAT.mmio64'

Using expected file 'tests/acpi-test-data/q35/SRAT.mmio64'

Looking for expected file 'tests/acpi-test-data/q35/MCFG.mmio64'

Looking for expected file 'tests/acpi-test-data/q35/MCFG'

Using expected file 'tests/acpi-test-data/q35/MCFG'
OK

So the difference is that the failing setup doesn't use
the SRAT.mmio64, and there is no SRAT file available for
fallback. (It also doesn't use DSDT.mmio64, but there there
is a fallback DSDT file in the tests/acpi-test-data/ directory.)

It looks like the test/acpi-test-data/ in the build directory
has not been populated with the MCFG.mmio64 file -- some of
the data files have symlinks from that directory back to the
source directory, but some do not. This seems to be done in
configure, but there is nothing in the makefile rules which
causes configure to be rerun because there is a new file
in your test data directory. A manual rerun of configure
adds the missing symlinks and causes the test to pass.

So I would characterise this as a makefile issue.

(PS: can we fix the extraneous extra blank lines in the test output
when run with V=1, please?)

thanks
-- PMM



Re: [Qemu-devel] [PATCH 1/2] docs: tpm: Mention implemented TPM CRB interface emulation and specs

2018-10-27 Thread Marc-André Lureau
On Thu, Oct 18, 2018 at 10:21 PM Stefan Berger
 wrote:
>
> Add a few sentences about the implemented emulation of the TPM CRB
> interface and its specification.
>
> Signed-off-by: Stefan Berger 

Reviewed-by: Marc-André Lureau 

> ---
>  docs/specs/tpm.txt | 15 +++
>  1 file changed, 15 insertions(+)
>
> diff --git a/docs/specs/tpm.txt b/docs/specs/tpm.txt
> index 0e9bbebe1d..1af82bba86 100644
> --- a/docs/specs/tpm.txt
> +++ b/docs/specs/tpm.txt
> @@ -20,6 +20,21 @@ QEMU files related to TPM TIS interface:
>   - hw/tpm/tpm_tis.h
>
>
> +QEMU also implements a TPM CRB interface following the Trusted Computing
> +Group's specification "TCG PC Client Platform TPM Profile (PTP)
> +Specification", Family "2.0", Level 00 Revision 01.03 v22, May 22, 2017.
> +This specification, or a later version of it, can be accessed from the
> +following URL:
> +
> +https://trustedcomputinggroup.org/resource/pc-client-platform-tpm-profile-ptp-specification/
> +
> +The CRB interface makes a memory mapped IO region in the area 0xfed4 -
> +0xfed40fff (1 locality) available to the guest operating system.
> +
> +QEMU files related to TPM CRB interface:
> + - hw/tpm/tpm_crb.c
> +
> +
>  = ACPI Interface =
>
>  The TPM device is defined with ACPI ID "PNP0C31". QEMU builds a SSDT and 
> passes
> --
> 2.17.1
>


-- 
Marc-André Lureau



Re: [Qemu-devel] [PATCH RFC 4/4] net/slirp: add ipv6-hostfwd option for user netdev type

2018-10-27 Thread Samuel Thibault
Maxim Samoylov, le ven. 26 oct. 2018 03:03:43 +0300, a ecrit:
> +void hmp_ipv6_hostfwd_remove(Monitor *mon, const QDict *qdict)
> +{

Similarly, a lot can be shared, by introducing 

const char *hmp_hostfwd_lookup(Monitor *mon, const QDict *qdict, int is_v6)

which will contain all the lookup and tcp/udp parsing part, and
just return the src_str (is_v6 to avoid testing only arg1).
hmp_hostfwd_remove and hmp_ipv6_hostfwd_remove can then just start by
calling it and get src_str that it can then use to parse the IPs.

> +struct in6_addr host_addr = in6addr_any;
> +if (*(p++) != '[') {
> +goto fail_syntax;
> +}

As mentioned, better explicit this in the helper message.

> +static int slirp_ipv6_hostfwd(SlirpState *s, const char *redir_str,
> +  Error **errp)

For this one I wouldn't bother factorizing, though.

Samuel



Re: [Qemu-devel] [PATCH RFC 3/4] slirp: add helpers for ipv6 hostfwd manipulation

2018-10-27 Thread Samuel Thibault
Hello,

Maxim Samoylov, le ven. 26 oct. 2018 03:03:42 +0300, a ecrit:
> +int slirp_remove_ipv6_hostfwd(Slirp *slirp, int is_udp,
> +  struct in6_addr host_addr, int host_port)

Similarly, we'd rather share the code than duplicate it :)

Better put the existing slirp_remove_hostfwd code into a

slirp_remove_x_hostfwd(Slirp *slirp, int is_udp, struct sockaddr *addr)

by replacing the explicit ipv4 comparison with a call to a helper
which compares two struct sockaddr (starting with the so_family field,
then testing fields depending the family, and you can put it in
slirp/socket.h)

and then slirp_remove_hostfwd can be rewritten as putting its
parameters into a sockaddr_in and colling slirp_remove_x_hostfwd, and
slirp_remove_ipv6_hostfwd implemented similarly for ipv6.

> +int slirp_add_ipv6_hostfwd(Slirp *slirp, int is_udp,
> +  struct in6_addr host_addr, int host_port,
> +  struct in6_addr guest_addr, int guest_port)
> +{
> +if (is_udp) {
> +if (!udp6_listen(slirp, host_addr, htons(host_port),
> + guest_addr, htons(guest_port), SS_HOSTFWD))
> +return -1;
> +} else {
> +if (!tcp6_listen(slirp, host_addr, htons(host_port),
> + guest_addr, htons(guest_port), SS_HOSTFWD))
> +return -1;
> +}
> +
> +return 0;
> +}

That one can remains so :)

Samuel



Re: [Qemu-devel] [PATCH RFC 2/4] slirp: add helper for udp6 socket creation

2018-10-27 Thread Samuel Thibault
Ditto :)

Samuel



Re: [Qemu-devel] [PATCH RFC 1/4] slirp: add helper for tcp6 socket creation

2018-10-27 Thread Samuel Thibault
Samuel Thibault, le sam. 27 oct. 2018 13:11:41 +0200, a ecrit:
> struct socket *
> tcp_listen(Slirp *slirp, uint32_t haddr, u_int hport, uint32_t laddr,
>u_int lport, int flags)
> {
>   struct sockaddr_in addr;
>   struct socket *so;
>   socklen_t addrsize = sizeof(addr);

Also  memset(, 0, sizeof(addr);

>   addr.sin_family = AF_INET;
>   addr.sin_addr.s_addr = haddr;
>   addr.sin_port = hport;



Re: [Qemu-devel] [PATCH RFC 1/4] slirp: add helper for tcp6 socket creation

2018-10-27 Thread Samuel Thibault
Hello,

Thanks for working on this!

There is a lot of overlap with tcp_listen. It'd be much better to
refactor it this way:

struct socket *
tcpx_listen(Slirp *slirp, struct sockaddr *addr, socklen_t *addrlen, int flags)
{
... The current content of tcp_listen, with all heading and
trailing addr manipulations removed...

... so->so_lfamily = addr->sa_family;...
... s = qemu_socket(addr->sa_family, SOCK_STREAM, 0);...
... (bind(s, addr, *addrlen) < 0) ||...
... getsockname(s, addr, addrlen);
}

struct socket *
tcp_listen(Slirp *slirp, uint32_t haddr, u_int hport, uint32_t laddr,
   u_int lport, int flags)
{
struct sockaddr_in addr;
struct socket *so;
socklen_t addrsize = sizeof(addr);

addr.sin_family = AF_INET;
addr.sin_addr.s_addr = haddr;
addr.sin_port = hport;

so = tcpx_listen(slirp, (struct sockaddr *) , , flags);

so->so_lport = lport; /* Kept in network format */
so->so_laddr.s_addr = laddr; /* Ditto */

so->so_ffamily = AF_INET;
so->so_fport = addr.sin_port;
if (addr.sin_addr.s_addr == 0 || addr.sin_addr.s_addr == 
loopback_addr.s_addr)
   so->so_faddr = slirp->vhost_addr;
else
   so->so_faddr = addr.sin_addr;
}

The v6 version then boils down to

struct socket *
tcp6_listen(Slirp *slirp, struct in6_addr haddr, u_int hport, struct
in6_addr laddr, u_int lport, int flags)
{
struct sockaddr_in6 addr;
struct socket *so;
socklen_t addrsize = sizeof(addr);

addr.sin6_family = AF_INET6;
addr.sin6_addr = haddr;
addr.sin6_port = hport;

so = tcpx_listen(slirp, (struct sockaddr *) , , flags);

so->so_lport6 = lport; /* Kept in network format */
so->so_laddr6 = laddr; /* Ditto */

so->fhost.sin6 = addr;

if (!memcmp(_addr, _any, sizeof(in6addr_any)) ||
!memcmp(_addr, _loopback,
sizeof(in6addr_loopback))) {

memcpy(>so_faddr6, >vhost_addr6, 
sizeof(slirp->vhost_addr6));
}
}

modulo all typos etc. I may have done.

Maxim Samoylov, le ven. 26 oct. 2018 03:03:40 +0300, a ecrit:
> +qemu_setsockopt(s, SOL_SOCKET, SO_OOBINLINE, , sizeof(int));

Is there a reason why you set SO_OOBINLINE, but not TCP_NODELAY? That's
the kind of discrepancy we don't want to let unseen, thus the reason for
a shared implementation :)

Samuel



Re: [Qemu-devel] [PATCH 0/2] Deprecate the "collie" machine and Strongarm devices

2018-10-27 Thread Guenter Roeck

On 10/26/18 3:12 AM, Peter Maydell wrote:

On 26 October 2018 at 11:06, Thomas Huth  wrote:

These files lack an entry in the MAINTAINERS file, and according to
the initial commits, the board and devices are incomplete. Since there
have hardly been any commits in the past to really improve them, we
should consider to mark them as deprecated now.

Thomas Huth (2):
   hw/arm: Deprecate the "collie" board
   arm: Deprecate the Strongarm sa1100 and sa1110 processors


Hi Guenter; there's a proposal here to deprecate (and eventually
remove) the 'collie' board (strongarm) from QEMU. Is that one of
the ones you're currently using in your automated testing of Linux
kernels on QEMU?



Yes. I can run the test with older versions of qemu, so it is ok for me
if it is removed (as long as that removal is not backported).

Guenter




[Qemu-devel] [PATCH V5 0/5] add pvpanic mmio support

2018-10-27 Thread Peng Hao
The first patches are simple cleanups:
- patch 1 move the pvpanic device with the 'ocmmon objects' so we compile
  it once for the x86/arm/aarch64 archs,
- patch 2 simply renames ISA fields/definitions to generic ones.

Then instead of add/use the MMIO pvpanic device in the virt machine in an
unique patch, I split it in two distinct patches:
- patch 3 uses Peng Hao's work, but add the MMIO interface to the existing
  device (no logical change).
- patch 4 is Peng Hao's work in the virt machine (no logical change).
- patch 5 add pvpanic device in acpi table in virt machine
v2 from Peng Hao is:
https://lists.gnu.org/archive/html/qemu-devel/2018-10/msg03433.html

v3 --> v4
  patch 1,2 no modification.
  patch 3, add TYPE_PANIC_MMIO for distinguishing different bus device,
   virt + isa_pvpanic will abnormally terminate virtual machine. 
  patch 4, "pvpanic,mmio" --> "qemu,pvpanic-mmio".
  patch 5, newly added.

v4 --> v5
  patch 1,2 no modification.
  patch 3 delete PvpanicCommonState structure.
  patch 4 VIRT_PVPANIC_MMIO --> VIRT_PVPANIC
  correct VIRT_PVPANIC's overlap start address
  patch 5 no modification.

Philippe Mathieu-Daudé (2):
  hw/misc/pvpanic: Build the pvpanic device in $(common-obj)
  hw/misc/pvpanic: Cosmetic renaming

Peng Hao (3):
  hw/misc/pvpanic: Add the MMIO interface
  hw/arm/virt: Use the pvpanic device
  hw/arm/virt: add pvpanic device in virt acpi table

 default-configs/aarch64-softmmu.mak |  1 +
 hw/arm/virt-acpi-build.c| 16 
 hw/arm/virt.c   | 21 ++
 hw/misc/Makefile.objs   |  2 +-
 hw/misc/pvpanic.c   | 78 ++---
 include/hw/arm/virt.h   |  1 +
 include/hw/misc/pvpanic.h   |  2 +
 7 files changed, 105 insertions(+), 16 deletions(-)

-- 
1.8.3.1




[Qemu-devel] [PATCH V5 3/5] hw/misc/pvpanic: Add the MMIO interface

2018-10-27 Thread Peng Hao
Signed-off-by: Peng Hao 
Signed-off-by: Philippe Mathieu-Daudé 
---
 hw/misc/pvpanic.c | 81 +--
 include/hw/misc/pvpanic.h |  1 +
 2 files changed, 65 insertions(+), 17 deletions(-)

diff --git a/hw/misc/pvpanic.c b/hw/misc/pvpanic.c
index dd3aef2..5d0fbc6 100644
--- a/hw/misc/pvpanic.c
+++ b/hw/misc/pvpanic.c
@@ -2,10 +2,12 @@
  * QEMU simulated pvpanic device.
  *
  * Copyright Fujitsu, Corp. 2013
+ * Copyright (c) 2018 ZTE Ltd.
  *
  * Authors:
  * Wen Congyang 
  * Hu Tao 
+ * Peng Hao 
  *
  * This work is licensed under the terms of the GNU GPL, version 2 or later.
  * See the COPYING file in the top-level directory.
@@ -25,9 +27,6 @@
 /* The pv event value */
 #define PVPANIC_PANICKED(1 << PVPANIC_F_PANICKED)
 
-#define PVPANIC(obj)\
-OBJECT_CHECK(PVPanicState, (obj), TYPE_PVPANIC)
-
 static void handle_event(int event)
 {
 static bool logged;
@@ -45,30 +44,50 @@ static void handle_event(int event)
 
 #include "hw/isa/isa.h"
 
-typedef struct PVPanicState {
-/* private */
-ISADevice isadev;
+/* PVPanicISAState for ISA device and
+ * use ioport.
+ */
+typedef struct PVPanicISAState {
+ /* private */
+ ISADevice isadev;
+ uint16_t ioport;
 
 /* public */
 MemoryRegion mr;
-uint16_t ioport;
-} PVPanicState;
+} PVPanicISAState;
+
+/* PVPanicMMIOState for sysbus device and
+ * use mmio.
+ */
+typedef struct PVPanicMMIOState {
+/* private */
+SysBusDevice busdev;
+
+ /* public */
+MemoryRegion mr;
+} PVPanicMMIOState;
+
+#define PVPANIC_ISA(obj)\
+OBJECT_CHECK(PVPanicISAState, (obj), TYPE_PVPANIC)
+
+#define PVPANIC_MMIO(obj)\
+OBJECT_CHECK(PVPanicMMIOState, (obj), TYPE_PVPANIC_MMIO)
 
 /* return supported events on read */
-static uint64_t pvpanic_ioport_read(void *opaque, hwaddr addr, unsigned size)
+static uint64_t pvpanic_read(void *opaque, hwaddr addr, unsigned size)
 {
 return PVPANIC_PANICKED;
 }
 
-static void pvpanic_ioport_write(void *opaque, hwaddr addr, uint64_t val,
+static void pvpanic_write(void *opaque, hwaddr addr, uint64_t val,
  unsigned size)
 {
 handle_event(val);
 }
 
 static const MemoryRegionOps pvpanic_ops = {
-.read = pvpanic_ioport_read,
-.write = pvpanic_ioport_write,
+.read = pvpanic_read,
+.write = pvpanic_write,
 .impl = {
 .min_access_size = 1,
 .max_access_size = 1,
@@ -77,15 +96,16 @@ static const MemoryRegionOps pvpanic_ops = {
 
 static void pvpanic_isa_initfn(Object *obj)
 {
-PVPanicState *s = PVPANIC(obj);
+PVPanicISAState *s = PVPANIC_ISA(obj);
 
-memory_region_init_io(>mr, OBJECT(s), _ops, s, "pvpanic", 1);
+memory_region_init_io(>mr, OBJECT(s), _ops, s,
+  TYPE_PVPANIC, 1);
 }
 
 static void pvpanic_isa_realizefn(DeviceState *dev, Error **errp)
 {
 ISADevice *d = ISA_DEVICE(dev);
-PVPanicState *s = PVPANIC(dev);
+PVPanicISAState *s = PVPANIC_ISA(dev);
 FWCfgState *fw_cfg = fw_cfg_find();
 uint16_t *pvpanic_port;
 
@@ -102,7 +122,7 @@ static void pvpanic_isa_realizefn(DeviceState *dev, Error 
**errp)
 }
 
 static Property pvpanic_isa_properties[] = {
-DEFINE_PROP_UINT16(PVPANIC_IOPORT_PROP, PVPanicState, ioport, 0x505),
+DEFINE_PROP_UINT16(PVPANIC_IOPORT_PROP, PVPanicISAState, ioport, 0x505),
 DEFINE_PROP_END_OF_LIST(),
 };
 
@@ -118,14 +138,41 @@ static void pvpanic_isa_class_init(ObjectClass *klass, 
void *data)
 static TypeInfo pvpanic_isa_info = {
 .name  = TYPE_PVPANIC,
 .parent= TYPE_ISA_DEVICE,
-.instance_size = sizeof(PVPanicState),
+.instance_size = sizeof(PVPanicISAState),
 .instance_init = pvpanic_isa_initfn,
 .class_init= pvpanic_isa_class_init,
 };
 
+
+static void pvpanic_mmio_initfn(Object *obj)
+{
+PVPanicMMIOState *s = PVPANIC_MMIO(obj);
+SysBusDevice *sbd = SYS_BUS_DEVICE(obj);
+
+memory_region_init_io(>mr, OBJECT(s), _ops, s,
+  TYPE_PVPANIC_MMIO, 2);
+sysbus_init_mmio(sbd, >mr);
+}
+
+static void pvpanic_mmio_class_init(ObjectClass *klass, void *data)
+{
+DeviceClass *dc = DEVICE_CLASS(klass);
+
+set_bit(DEVICE_CATEGORY_MISC, dc->categories);
+}
+
+static TypeInfo pvpanic_mmio_info = {
+.name  = TYPE_PVPANIC_MMIO,
+.parent= TYPE_SYS_BUS_DEVICE,
+.instance_size = sizeof(PVPanicMMIOState),
+.instance_init = pvpanic_mmio_initfn,
+.class_init= pvpanic_mmio_class_init,
+};
+
 static void pvpanic_register_types(void)
 {
 type_register_static(_isa_info);
+type_register_static(_mmio_info);
 }
 
 type_init(pvpanic_register_types)
diff --git a/include/hw/misc/pvpanic.h b/include/hw/misc/pvpanic.h
index 1ee071a..19c0fbb 100644
--- a/include/hw/misc/pvpanic.h
+++ b/include/hw/misc/pvpanic.h
@@ -17,6 +17,7 @@
 #define TYPE_PVPANIC "pvpanic"
 
 #define PVPANIC_IOPORT_PROP "ioport"
+#define TYPE_PVPANIC_MMIO "pvpanic-mmio"
 
 static 

[Qemu-devel] [PATCH V5 1/5] hw/misc/pvpanic: Build the pvpanic device in $(common-obj)

2018-10-27 Thread Peng Hao
From: Philippe Mathieu-Daudé 

The 'pvpanic' ISA device can be use by any machine with an ISA bus.

Signed-off-by: Philippe Mathieu-Daudé 
---
 hw/misc/Makefile.objs | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/hw/misc/Makefile.objs b/hw/misc/Makefile.objs
index 6d50b03..24997d6 100644
--- a/hw/misc/Makefile.objs
+++ b/hw/misc/Makefile.objs
@@ -8,6 +8,7 @@ common-obj-$(CONFIG_ISA_TESTDEV) += pc-testdev.o
 common-obj-$(CONFIG_PCI_TESTDEV) += pci-testdev.o
 common-obj-$(CONFIG_EDU) += edu.o
 common-obj-$(CONFIG_PCA9552) += pca9552.o
+common-obj-$(CONFIG_PVPANIC) += pvpanic.o
 
 common-obj-y += unimp.o
 common-obj-$(CONFIG_FW_CFG_DMA) += vmcoreinfo.o
@@ -70,7 +71,6 @@ obj-$(CONFIG_IOTKIT_SECCTL) += iotkit-secctl.o
 obj-$(CONFIG_IOTKIT_SYSCTL) += iotkit-sysctl.o
 obj-$(CONFIG_IOTKIT_SYSINFO) += iotkit-sysinfo.o
 
-obj-$(CONFIG_PVPANIC) += pvpanic.o
 obj-$(CONFIG_HYPERV_TESTDEV) += hyperv_testdev.o
 obj-$(CONFIG_AUX) += auxbus.o
 obj-$(CONFIG_ASPEED_SOC) += aspeed_scu.o aspeed_sdmc.o
-- 
1.8.3.1




[Qemu-devel] [PATCH V5 2/5] hw/misc/pvpanic: Cosmetic renaming

2018-10-27 Thread Peng Hao
From: Philippe Mathieu-Daudé 

To ease the MMIO device addition in the next patch, rename:
- ISA_PVPANIC_DEVICE -> PVPANIC (this just returns a generic Object),
- ISADevice parent_obj -> isadev,
- MemoryRegion io -> mr.

Signed-off-by: Philippe Mathieu-Daudé 
---
 hw/misc/pvpanic.c | 16 +---
 1 file changed, 9 insertions(+), 7 deletions(-)

diff --git a/hw/misc/pvpanic.c b/hw/misc/pvpanic.c
index 9d8961b..dd3aef2 100644
--- a/hw/misc/pvpanic.c
+++ b/hw/misc/pvpanic.c
@@ -25,7 +25,7 @@
 /* The pv event value */
 #define PVPANIC_PANICKED(1 << PVPANIC_F_PANICKED)
 
-#define ISA_PVPANIC_DEVICE(obj)\
+#define PVPANIC(obj)\
 OBJECT_CHECK(PVPanicState, (obj), TYPE_PVPANIC)
 
 static void handle_event(int event)
@@ -46,9 +46,11 @@ static void handle_event(int event)
 #include "hw/isa/isa.h"
 
 typedef struct PVPanicState {
-ISADevice parent_obj;
+/* private */
+ISADevice isadev;
 
-MemoryRegion io;
+/* public */
+MemoryRegion mr;
 uint16_t ioport;
 } PVPanicState;
 
@@ -75,15 +77,15 @@ static const MemoryRegionOps pvpanic_ops = {
 
 static void pvpanic_isa_initfn(Object *obj)
 {
-PVPanicState *s = ISA_PVPANIC_DEVICE(obj);
+PVPanicState *s = PVPANIC(obj);
 
-memory_region_init_io(>io, OBJECT(s), _ops, s, "pvpanic", 1);
+memory_region_init_io(>mr, OBJECT(s), _ops, s, "pvpanic", 1);
 }
 
 static void pvpanic_isa_realizefn(DeviceState *dev, Error **errp)
 {
 ISADevice *d = ISA_DEVICE(dev);
-PVPanicState *s = ISA_PVPANIC_DEVICE(dev);
+PVPanicState *s = PVPANIC(dev);
 FWCfgState *fw_cfg = fw_cfg_find();
 uint16_t *pvpanic_port;
 
@@ -96,7 +98,7 @@ static void pvpanic_isa_realizefn(DeviceState *dev, Error 
**errp)
 fw_cfg_add_file(fw_cfg, "etc/pvpanic-port", pvpanic_port,
 sizeof(*pvpanic_port));
 
-isa_register_ioport(d, >io, s->ioport);
+isa_register_ioport(d, >mr, s->ioport);
 }
 
 static Property pvpanic_isa_properties[] = {
-- 
1.8.3.1




[Qemu-devel] [PATCH V5 4/5] hw/arm/virt: Use the pvpanic device

2018-10-27 Thread Peng Hao
add pvpanic device in aarch64 virt machine.

Signed-off-by: Peng Hao 
Signed-off-by: Philippe Mathieu-Daudé 
---
 default-configs/aarch64-softmmu.mak |  1 +
 hw/arm/virt.c   | 21 +
 include/hw/arm/virt.h   |  1 +
 3 files changed, 23 insertions(+)

diff --git a/default-configs/aarch64-softmmu.mak 
b/default-configs/aarch64-softmmu.mak
index 6f790f0..57c6ca5 100644
--- a/default-configs/aarch64-softmmu.mak
+++ b/default-configs/aarch64-softmmu.mak
@@ -9,3 +9,4 @@ CONFIG_DPCD=y
 CONFIG_XLNX_ZYNQMP=y
 CONFIG_XLNX_ZYNQMP_ARM=y
 CONFIG_ARM_SMMUV3=y
+CONFIG_PVPANIC=y
diff --git a/hw/arm/virt.c b/hw/arm/virt.c
index 9f67782..ffe8d00 100644
--- a/hw/arm/virt.c
+++ b/hw/arm/virt.c
@@ -59,6 +59,7 @@
 #include "qapi/visitor.h"
 #include "standard-headers/linux/input.h"
 #include "hw/arm/smmuv3.h"
+#include "hw/misc/pvpanic.h"
 
 #define DEFINE_VIRT_MACHINE_LATEST(major, minor, latest) \
 static void virt_##major##_##minor##_class_init(ObjectClass *oc, \
@@ -143,6 +144,7 @@ static const MemMapEntry a15memmap[] = {
 [VIRT_GPIO] =   { 0x0903, 0x1000 },
 [VIRT_SECURE_UART] ={ 0x0904, 0x1000 },
 [VIRT_SMMU] =   { 0x0905, 0x0002 },
+[VIRT_PVPANIC] ={ 0x0907, 0x0002 },
 [VIRT_MMIO] =   { 0x0a00, 0x0200 },
 /* ...repeating for a total of NUM_VIRTIO_TRANSPORTS, each of that size */
 [VIRT_PLATFORM_BUS] =   { 0x0c00, 0x0200 },
@@ -190,6 +192,23 @@ static bool cpu_type_valid(const char *cpu)
 return false;
 }
 
+static void create_pvpanic_device(const VirtMachineState *vms)
+{
+char *nodename;
+hwaddr base = vms->memmap[VIRT_PVPANIC].base;
+hwaddr size = vms->memmap[VIRT_PVPANIC].size;
+
+sysbus_create_simple(TYPE_PVPANIC_MMIO, base, NULL);
+
+nodename = g_strdup_printf("/pvpanic-mmio@%" PRIx64, base);
+qemu_fdt_add_subnode(vms->fdt, nodename);
+qemu_fdt_setprop_string(vms->fdt, nodename,
+"compatible", "qemu,pvpanic-mmio");
+qemu_fdt_setprop_sized_cells(vms->fdt, nodename, "reg",
+ 2, base, 2, size);
+g_free(nodename);
+}
+
 static void create_fdt(VirtMachineState *vms)
 {
 void *fdt = create_device_tree(>fdt_size);
@@ -1531,6 +1550,8 @@ static void machvirt_init(MachineState *machine)
 
 create_flash(vms, sysmem, secure_sysmem ? secure_sysmem : sysmem);
 
+create_pvpanic_device(vms);
+
 create_gic(vms, pic);
 
 fdt_add_pmu_nodes(vms);
diff --git a/include/hw/arm/virt.h b/include/hw/arm/virt.h
index 4cc57a7..ba54b84 100644
--- a/include/hw/arm/virt.h
+++ b/include/hw/arm/virt.h
@@ -66,6 +66,7 @@ enum {
 VIRT_GIC_REDIST,
 VIRT_GIC_REDIST2,
 VIRT_SMMU,
+VIRT_PVPANIC,
 VIRT_UART,
 VIRT_MMIO,
 VIRT_RTC,
-- 
1.8.3.1




[Qemu-devel] [PATCH V5 5/5] hw/arm/virt: add pvpanic device in virt acpi table

2018-10-27 Thread Peng Hao
add pvpanic device in virt acpi table, so when kenrel command line uses
acpi=force, kernel can get info from acpi table in aarch64.

Signed-off-by: Peng Hao 
---
 hw/arm/virt-acpi-build.c | 16 
 1 file changed, 16 insertions(+)

diff --git a/hw/arm/virt-acpi-build.c b/hw/arm/virt-acpi-build.c
index 5785fb6..d126cee 100644
--- a/hw/arm/virt-acpi-build.c
+++ b/hw/arm/virt-acpi-build.c
@@ -61,6 +61,21 @@ static void acpi_dsdt_add_cpus(Aml *scope, int smp_cpus)
 }
 }
 
+static void acpi_dsdt_add_pvpanic(Aml *scope, const MemMapEntry 
*pvpanic_memmap)
+{
+Aml *dev = aml_device("PANC");
+aml_append(dev, aml_name_decl("_HID", aml_string("QEMU0001")));
+aml_append(dev, aml_name_decl("_UID", aml_int(0)));
+
+Aml *crs = aml_resource_template();
+aml_append(crs, aml_memory32_fixed(pvpanic_memmap->base,
+   pvpanic_memmap->size, AML_READ_WRITE));
+
+aml_append(dev, aml_name_decl("_CRS", crs));
+
+aml_append(scope, dev);
+}
+
 static void acpi_dsdt_add_uart(Aml *scope, const MemMapEntry *uart_memmap,
uint32_t uart_irq)
 {
@@ -770,6 +785,7 @@ build_dsdt(GArray *table_data, BIOSLinker *linker, 
VirtMachineState *vms)
 acpi_dsdt_add_cpus(scope, vms->smp_cpus);
 acpi_dsdt_add_uart(scope, [VIRT_UART],
(irqmap[VIRT_UART] + ARM_SPI_BASE));
+acpi_dsdt_add_pvpanic(scope, [VIRT_PVPANIC]);
 acpi_dsdt_add_flash(scope, [VIRT_FLASH]);
 acpi_dsdt_add_fw_cfg(scope, [VIRT_FW_CFG]);
 acpi_dsdt_add_virtio(scope, [VIRT_MMIO],
-- 
1.8.3.1




Re: [Qemu-devel] [Qemu-arm] [RFC v4 00/71] per-CPU locks

2018-10-27 Thread Alex Bennée


Emilio G. Cota  writes:

> [I forgot to add the cover letter to git send-email; here it is]
>
> v3: https://lists.gnu.org/archive/html/qemu-devel/2018-10/msg04179.html
>
> "Why is this an RFC?" See v3 link above. Also, see comment at
> the bottom of this message regarding the last patch of this series.

I'm also seeing his hang on check-tcg, specifically qemu-aarch64 
./tests/linux-test



--
Alex Bennée



Re: [Qemu-devel] [PATCH v3 01/16] hw/cpu: introduce CPU clusters

2018-10-27 Thread Alistair Francis
On Fri, Oct 26, 2018 at 9:41 AM Luc Michel  wrote:
>
> This commit adds the cpu-cluster type. It aims at gathering CPUs from
> the same cluster in a machine.
>
> For now it only has a `cluster-id` property.
>
> Signed-off-by: Luc Michel 
> ---
>  include/hw/cpu/cluster.h | 38 +++
>  hw/cpu/cluster.c | 49 
>  hw/cpu/Makefile.objs |  2 +-
>  3 files changed, 88 insertions(+), 1 deletion(-)
>  create mode 100644 include/hw/cpu/cluster.h
>  create mode 100644 hw/cpu/cluster.c
>
> diff --git a/include/hw/cpu/cluster.h b/include/hw/cpu/cluster.h
> new file mode 100644
> index 00..f233a47a4a
> --- /dev/null
> +++ b/include/hw/cpu/cluster.h
> @@ -0,0 +1,38 @@
> +/*
> + * QEMU CPU cluster
> + *
> + * Copyright (c) 2018 GreenSocs SAS
> + *
> + * This program is free software; you can redistribute it and/or
> + * modify it under the terms of the GNU General Public License
> + * as published by the Free Software Foundation; either version 2
> + * of the License, or (at your option) any later version.
> + *
> + * This program is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> + * GNU General Public License for more details.
> + *
> + * You should have received a copy of the GNU General Public License
> + * along with this program; if not, see
> + * 
> + */
> +#ifndef QEMU_HW_CPU_CLUSTER_H
> +#define QEMU_HW_CPU_CLUSTER_H

You probably don't need the QEMU_ here, it's not ambiguous if this is QEMU :)

> +
> +#include "qemu/osdep.h"
> +#include "hw/qdev.h"
> +
> +#define TYPE_CPU_CLUSTER "cpu-cluster"
> +#define CPU_CLUSTER(obj) \
> +OBJECT_CHECK(CPUClusterState, (obj), TYPE_CPU_CLUSTER)
> +
> +typedef struct CPUClusterState {
> +/*< private >*/
> +DeviceState parent_obj;
> +
> +/*< public >*/
> +uint32_t cluster_id;
> +} CPUClusterState;
> +
> +#endif
> diff --git a/hw/cpu/cluster.c b/hw/cpu/cluster.c
> new file mode 100644
> index 00..11121e6f26
> --- /dev/null
> +++ b/hw/cpu/cluster.c
> @@ -0,0 +1,49 @@
> +/*
> + * QEMU CPU cluster
> + *
> + * Copyright (c) 2018 GreenSocs SAS
> + *
> + * This program is free software; you can redistribute it and/or
> + * modify it under the terms of the GNU General Public License
> + * as published by the Free Software Foundation; either version 2
> + * of the License, or (at your option) any later version.
> + *
> + * This program is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> + * GNU General Public License for more details.
> + *
> + * You should have received a copy of the GNU General Public License
> + * along with this program; if not, see
> + * 
> + */
> +

You should also include the OS deps here (the first include).

After that:

Reviewed-by: Alistair Francis 

Alistair

> +#include "hw/cpu/cluster.h"
> +#include "qapi/error.h"
> +#include "qemu/module.h"
> +
> +static Property cpu_cluster_properties[] = {
> +DEFINE_PROP_UINT32("cluster-id", CPUClusterState, cluster_id, 0),
> +DEFINE_PROP_END_OF_LIST()
> +};
> +
> +static void cpu_cluster_class_init(ObjectClass *klass, void *data)
> +{
> +DeviceClass *dc = DEVICE_CLASS(klass);
> +
> +dc->props = cpu_cluster_properties;
> +}
> +
> +static const TypeInfo cpu_cluster_type_info = {
> +.name = TYPE_CPU_CLUSTER,
> +.parent = TYPE_DEVICE,
> +.instance_size = sizeof(CPUClusterState),
> +.class_init = cpu_cluster_class_init,
> +};
> +
> +static void cpu_cluster_register_types(void)
> +{
> +type_register_static(_cluster_type_info);
> +}
> +
> +type_init(cpu_cluster_register_types)
> diff --git a/hw/cpu/Makefile.objs b/hw/cpu/Makefile.objs
> index cd52d20b65..8db9e8a7b3 100644
> --- a/hw/cpu/Makefile.objs
> +++ b/hw/cpu/Makefile.objs
> @@ -1,5 +1,5 @@
>  obj-$(CONFIG_ARM11MPCORE) += arm11mpcore.o
>  obj-$(CONFIG_REALVIEW) += realview_mpcore.o
>  obj-$(CONFIG_A9MPCORE) += a9mpcore.o
>  obj-$(CONFIG_A15MPCORE) += a15mpcore.o
> -common-obj-y += core.o
> +common-obj-y += core.o cluster.o
> --
> 2.19.1
>
>



Re: [Qemu-devel] [PATCH] target/riscv/pmp.c: pmpcfg_csr_read returns bogus value on RV64

2018-10-27 Thread Alistair Francis
On Fri, Oct 26, 2018 at 7:14 PM Dayeol Lee  wrote:
>
> Hi,
>
> I submitted the patch, but just found this has been already fixed by
> Michael Clark
> and pushed to riscv/riscv-qemu https://github.com/riscv/riscv-qemu/pull/166
> but not in the upstream.
>
> Do we still need this patch?

Yeah, this patch is still needed as it fixes the problem in mainline.

Reviewed-by: Alistair Francis 

Alistair

>
> Thanks,
>
> Dayeol
>
> On Fri, Oct 26, 2018 at 11:04 AM Dayeol Lee  wrote:
>
> > pmp_read_cfg() returns 8-bit value, which is combined together to form a
> > single pmpcfg CSR.
> > The default promotion rules will result in an integer here ("i*8" is
> > integer, which
> > flows through) resulting in a 32-bit signed value on most hosts.
> > That's bogus on RV64I, with the high bits of the CSR being wrong.
> >
> > Signed-off-by: Dayeol Lee 
> > Reviewed-by: Palmer Dabbelt 
> > ---
> >  target/riscv/pmp.c | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/target/riscv/pmp.c b/target/riscv/pmp.c
> > index c828950..3d3906a 100644
> > --- a/target/riscv/pmp.c
> > +++ b/target/riscv/pmp.c
> > @@ -330,7 +330,7 @@ target_ulong pmpcfg_csr_read(CPURISCVState *env,
> > uint32_t reg_index)
> >  {
> >  int i;
> >  target_ulong cfg_val = 0;
> > -uint8_t val = 0;
> > +target_ulong val = 0;
> >
> >  if(sizeof(target_ulong) == 8)
> >  reg_index /= 2;
> > --
> > 2.7.4
> >
> >



Re: [Qemu-devel] [PATCH v2 00/29] target/riscv: Convert to decodetree

2018-10-27 Thread Palmer Dabbelt

On Fri, 26 Oct 2018 03:53:11 PDT (-0700), kbast...@mail.uni-paderborn.de wrote:


On 10/25/18 12:21 AM, Palmer Dabbelt wrote:

On Sat, 20 Oct 2018 00:14:22 PDT (-0700),
kbast...@mail.uni-paderborn.de wrote:

Hi,

this patchset converts the RISC-V decoder to decodetree in three
major steps:

1) Convert 32-bit instructions to decodetree [Patch 1-14]:
    Many of the gen_* functions are called by the decode functions
for 16-bit
    and 32-bit functions. If we move translation code from the gen_*
    functions to the generated trans_* functions of decode-tree, we
get a lot of
    duplication. Therefore, we mostly generate calls to the old gen_*
function
    which are properly replaced after step 2).

    Each of the trans_ functions are grouped into files corresponding
to their
    ISA extension, e.g. addi which is in RV32I is translated in the file
    'trans_rvi.inc.c'.

2) Convert 16-bit instructions to decodetree [Patch 15-17]:
    All 16 bit instructions have a direct mapping to a 32 bit
instruction. Thus,
    we convert the arguments in the 16 bit trans_ function to the
arguments of
    the corresponding 32 bit instruction and call the 32 bit trans_
function.

3) Remove old manual decoding in gen_* function [Patch 17-28]:
    this move all manual translation code into the trans_*
instructions of
    decode tree, such that we can remove the old decode_* functions.

the full tree can be found here:
https://github.com/bkoppelmann/qemu/tree/riscv-dt-v2


Thanks!

I dropped this on top of master and it appears I'm getting a bunch of
oops when trying to boot Linux.  They're fairly far into the boot
process and may be a mistake on my end, I was just wondering if you'd
booted Linux?


Are there non fatal oops in booting Linux? I only checked whether I
could get a terminal on Fedora Linux.


Most of the stuff past early boot is, as if it's in a userspace process or 
kernel thread you can recover.  My system eventually made it to a shell, but 
there was a lot of carnage on the way in -- most system services blew up.


I tested the same kernel+rootfs on master and it booted cleanly.