Re: [Qemu-devel] [PATCH] migration: calculate expected_downtime with ram_bytes_remaining()
On Sun, Apr 01, 2018 at 12:25:36AM +0530, Balamuruhan S wrote:
> expected_downtime value is not accurate with dirty_pages_rate * page_size,
> using ram_bytes_remaining would yeild it correct.
>
> Signed-off-by: Balamuruhan S
> ---
> migration/migration.c | 3 +--
> 1 file changed, 1 insertion(+), 2 deletions(-)
>
> diff --git a/migration/migration.c b/migration/migration.c
> index 58bd382730..4e43dc4f92 100644
> --- a/migration/migration.c
> +++ b/migration/migration.c
> @@ -2245,8 +2245,7 @@ static void migration_update_counters(MigrationState *s,
> * recalculate. 1 is a small enough number for our purposes
> */
> if (ram_counters.dirty_pages_rate && transferred > 1) {
> -s->expected_downtime = ram_counters.dirty_pages_rate *
> -qemu_target_page_size() / bandwidth;
> +s->expected_downtime = ram_bytes_remaining() / bandwidth;
This field was removed in e4ed1541ac ("savevm: New save live migration
method: pending", 2012-12-20), in which remaing RAM was used.
And it was added back in 90f8ae724a ("migration: calculate
expected_downtime", 2013-02-22), in which dirty rate was used.
However I didn't find a clue on why we changed from using remaining
RAM to using dirty rate... So I'll leave this question to Juan.
Besides, I'm a bit confused on when we'll want such a value. AFAIU
precopy is mostly used by setting up the target downtime before hand,
so we should already know the downtime before hand. Then why we want
to observe such a thing?
Thanks,
--
Peter Xu
Re: [Qemu-devel] [Qemu-ppc] [PATCH for-2.13] Add host_memory_backend_pagesize() helper
On Thu, Mar 29, 2018 at 08:37:48AM +0200, Greg Kurz wrote:
> On Thu, 29 Mar 2018 16:25:37 +1100
> David Gibson wrote:
>
> > There are a couple places (one generic, one target specific) where we need
> > to get the host page size associated with a particular memory backend. I
> > have some upcoming code which will add another place which wants this. So,
> > for convenience, add a helper function to calculate this.
> >
> > host_memory_backend_pagesize() returns the host pagesize for a given
> > HostMemoryBackend object, or for the default backend (-mem-path) if passed
> > NULL.
> >
> > Signed-off-by: David Gibson
> > ---
>
> The idea is good but there's a small issue. See below.
>
> > backends/hostmem.c | 20
> > exec.c | 21 +
> > include/sysemu/hostmem.h | 2 ++
> > target/ppc/kvm.c | 10 +-
> > 4 files changed, 28 insertions(+), 25 deletions(-)
> >
> > diff --git a/backends/hostmem.c b/backends/hostmem.c
> > index f61093654e..b6a60cfc5d 100644
> > --- a/backends/hostmem.c
> > +++ b/backends/hostmem.c
> > @@ -18,6 +18,7 @@
> > #include "qapi/visitor.h"
> > #include "qemu/config-file.h"
> > #include "qom/object_interfaces.h"
> > +#include "qemu/mmap-alloc.h"
> >
> > #ifdef CONFIG_NUMA
> > #include
> > @@ -262,6 +263,25 @@ bool host_memory_backend_is_mapped(HostMemoryBackend
> > *backend)
> > return backend->is_mapped;
> > }
> >
> > +long host_memory_backend_pagesize(HostMemoryBackend *memdev)
> > +{
> > +const char *path = NULL;
> > +
> > +#ifdef __linux__
> > +if (memdev) {
> > +path = object_property_get_str(OBJECT(memdev), "mem-path", NULL);
>
> object_property_get_str() returns an allocated string. It should be freed
> before returning.
Ah, nice catch, I'll correct that.
--
David Gibson| I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
signature.asc
Description: PGP signature
Re: [Qemu-devel] [PATCH for-2.13] Add host_memory_backend_pagesize() helper
On Mon, Apr 02, 2018 at 11:22:06PM -0300, Eduardo Habkost wrote:
> On Thu, Mar 29, 2018 at 04:25:37PM +1100, David Gibson wrote:
> > There are a couple places (one generic, one target specific) where we need
> > to get the host page size associated with a particular memory backend. I
> > have some upcoming code which will add another place which wants this. So,
> > for convenience, add a helper function to calculate this.
> >
> > host_memory_backend_pagesize() returns the host pagesize for a given
> > HostMemoryBackend object, or for the default backend (-mem-path) if passed
> > NULL.
> >
> > Signed-off-by: David Gibson
> > ---
> > backends/hostmem.c | 20
> > exec.c | 21 +
> > include/sysemu/hostmem.h | 2 ++
> > target/ppc/kvm.c | 10 +-
> > 4 files changed, 28 insertions(+), 25 deletions(-)
> >
> > diff --git a/backends/hostmem.c b/backends/hostmem.c
> > index f61093654e..b6a60cfc5d 100644
> > --- a/backends/hostmem.c
> > +++ b/backends/hostmem.c
> > @@ -18,6 +18,7 @@
> > #include "qapi/visitor.h"
> > #include "qemu/config-file.h"
> > #include "qom/object_interfaces.h"
> > +#include "qemu/mmap-alloc.h"
> >
> > #ifdef CONFIG_NUMA
> > #include
> > @@ -262,6 +263,25 @@ bool host_memory_backend_is_mapped(HostMemoryBackend
> > *backend)
> > return backend->is_mapped;
> > }
> >
> > +long host_memory_backend_pagesize(HostMemoryBackend *memdev)
>
> qemu_mempath_getpagesize() returns size_t. Why are you using
> long here?
Because qemu_getrampagesize() returns long. But size_t is better, so
I've changed it.
> > +{
> > +const char *path = NULL;
> > +
> > +#ifdef __linux__
> > +if (memdev) {
> > +path = object_property_get_str(OBJECT(memdev), "mem-path", NULL);
> > +} else {
> > +path = mem_path;
> > +}
> > +#endif
> > +
> > +if (path) {
> > +return qemu_mempath_getpagesize(path);
> > +} else {
> > +return getpagesize();
>
> Isn't it simpler to make qemu_mempath_getpagesize() handle
> path==NULL?
Uh.. possibly not, but things you bring up later kind of make it moot.
> > +}
> > +}
> > +
> > static void
> > host_memory_backend_memory_complete(UserCreatable *uc, Error **errp)
> > {
> > diff --git a/exec.c b/exec.c
> > index c09bd93df3..04856c2402 100644
> > --- a/exec.c
> > +++ b/exec.c
> > @@ -1488,18 +1488,13 @@ void ram_block_dump(Monitor *mon)
> > */
> > static int find_max_supported_pagesize(Object *obj, void *opaque)
> > {
> > -char *mem_path;
> > long *hpsize_min = opaque;
> >
> > if (object_dynamic_cast(obj, TYPE_MEMORY_BACKEND)) {
> > -mem_path = object_property_get_str(obj, "mem-path", NULL);
> > -if (mem_path) {
> > -long hpsize = qemu_mempath_getpagesize(mem_path);
> > -if (hpsize < *hpsize_min) {
> > -*hpsize_min = hpsize;
> > -}
> > -} else {
> > -*hpsize_min = getpagesize();
> > +long hpsize = host_memory_backend_pagesize(MEMORY_BACKEND(obj));
>
> So in this caller, `backend` is always non-NULL...
>
> > +
> > +if (hpsize < *hpsize_min) {
> > +*hpsize_min = hpsize;
> > }
> > }
> >
> > @@ -1509,15 +1504,9 @@ static int find_max_supported_pagesize(Object *obj,
> > void *opaque)
> > long qemu_getrampagesize(void)
> > {
> > long hpsize = LONG_MAX;
> > -long mainrampagesize;
> > +long mainrampagesize = host_memory_backend_pagesize(NULL);
>
> ...on this caller `backend` is always NULL...
>
>
> > Object *memdev_root;
> >
> > -if (mem_path) {
> > -mainrampagesize = qemu_mempath_getpagesize(mem_path);
> > -} else {
> > -mainrampagesize = getpagesize();
> > -}
> > -
> > /* it's possible we have memory-backend objects with
> > * hugepage-backed RAM. these may get mapped into system
> > * address space via -numa parameters or memory hotplug
> [...]
> > diff --git a/target/ppc/kvm.c b/target/ppc/kvm.c
> > index b329cd8173..0adcf18c9f 100644
> > --- a/target/ppc/kvm.c
> > +++ b/target/ppc/kvm.c
> > @@ -493,15 +493,7 @@ static void kvm_fixup_page_sizes(PowerPCCPU *cpu)
> > bool kvmppc_is_mem_backend_page_size_ok(const char *obj_path)
> > {
> > Object *mem_obj = object_resolve_path(obj_path, NULL);
> > -char *mempath = object_property_get_str(mem_obj, "mem-path", NULL);
> > -long pagesize;
> > -
> > -if (mempath) {
> > -pagesize = qemu_mempath_getpagesize(mempath);
> > -g_free(mempath);
> > -} else {
> > -pagesize = getpagesize();
> > -}
> > +long pagesize = host_memory_backend_pagesize(MEMORY_BACKEND(mem_obj));
> >
>
> ...and here `backend` is always non-NULL.
>
> If there's no caller that relies on both code paths, why overload
> a single function for two different operations?
Good point.
> I would simply make qemu_mempath_getpagesize() work if path is
> NULL,
[Qemu-devel] [PATCH for-2.12] monitor: bind dispatch bh to iohandler context
Eric Auger reported the problem days ago that OOB broke ARM when running with libvirt: http://lists.gnu.org/archive/html/qemu-devel/2018-03/msg06231.html This patch fixes the problem. It's not really needed now since we have turned OOB off now, but it's still a bug fix, and it'll start to work when we turn OOB on for ARM. The problem was that the monitor dispatcher bottom half was bound to qemu_aio_context, but that context seems to be for block only. For the rest of the QEMU world we should be using iohandler context. So assigning monitor dispatcher bottom half to that context. If without this change, QMP dispatcher might be run even before reaching main loop in block IO path, for example, in a stack like: #0 qmp_cont () #1 0x006bd210 in qmp_marshal_cont () #2 0x00ac05c4 in do_qmp_dispatch () #3 0x00ac07a0 in qmp_dispatch () #4 0x00472d60 in monitor_qmp_dispatch_one () #5 0x0047302c in monitor_qmp_bh_dispatcher () #6 0x00acf374 in aio_bh_call () #7 0x00acf428 in aio_bh_poll () #8 0x00ad5110 in aio_poll () #9 0x00a08ab8 in blk_prw () #10 0x00a091c4 in blk_pread () #11 0x00734f94 in pflash_cfi01_realize () #12 0x0075a3a4 in device_set_realized () #13 0x009a26cc in property_set_bool () #14 0x009a0a40 in object_property_set () #15 0x009a3a08 in object_property_set_qobject () #16 0x009a0c8c in object_property_set_bool () #17 0x00758f94 in qdev_init_nofail () #18 0x0058e190 in create_one_flash () #19 0x0058e2f4 in create_flash () #20 0x005902f0 in machvirt_init () #21 0x007635cc in machine_run_board_init () #22 0x006b135c in main () This can cause ARM to crash when used with both OOB capability enabled and libvirt as upper layer, since libvirt will start QEMU with "-S" and the first "cont" command will arrive very early if the context is not correct (which is what above stack shows). Then, the vcpu threads will start to run right after the qmp_cont() call, even when GICs have not been setup correctly yet (which is done in kvm_arm_machine_init_done()). My sincere thanks to Eric Auger who offered great help during both debugging and verifying the problem. The ARM test was carried out by applying this patch upon QEMU 2.12.0-rc0 and problem is gone after the patch. A quick test of mine shows that after this patch applied we can pass all raw iotests even with OOB on by default. CC: Eric Blake CC: Markus Armbruster CC: Stefan Hajnoczi CC: Fam Zheng Reported-by: Eric Auger Tested-by: Eric Auger Signed-off-by: Peter Xu --- This patch will fix all known OOB breakages I know so far, but I think for better safety I'll still keep OOB off, and I'll send another patch to turn default OOB on after 2.12 release. --- monitor.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/monitor.c b/monitor.c index 51f4cf480f..39f8ee17ba 100644 --- a/monitor.c +++ b/monitor.c @@ -4467,7 +4467,7 @@ static void monitor_iothread_init(void) * have assumption to be run on main loop thread. It would be * nice that one day we can remove this assumption in the future. */ -mon_global.qmp_dispatcher_bh = aio_bh_new(qemu_get_aio_context(), +mon_global.qmp_dispatcher_bh = aio_bh_new(iohandler_get_aio_context(), monitor_qmp_bh_dispatcher, NULL); -- 2.14.3
[Qemu-devel] [PATCH for-2.12] block: handle invalid lseek returns gracefully
In commit 223a23c198787328ae75bc65d84edf5fde33c0b6, we implemented a
workaround in the gluster driver to handle invalid values returned for
SEEK_DATA or SEEK_HOLE.
In some instances, these same invalid values can be seen in the posix
file handler as well - for example, it has been reported on FUSE gluster
mounts.
Calling assert() for these invalid values is overly harsh; we can safely
return -EIO and allow this case to be treated as a "learned nothing"
case (e.g., D4 / H4, as commented in the code).
This patch does the same thing that 223a23c198787 did for gluster.c,
except in file-posix.c
Signed-off-by: Jeff Cody
---
block/file-posix.c | 14 --
1 file changed, 12 insertions(+), 2 deletions(-)
diff --git a/block/file-posix.c b/block/file-posix.c
index d7fb772c14..a2f6d8a8c8 100644
--- a/block/file-posix.c
+++ b/block/file-posix.c
@@ -2114,7 +2114,12 @@ static int find_allocation(BlockDriverState *bs, off_t
start,
if (offs < 0) {
return -errno; /* D3 or D4 */
}
-assert(offs >= start);
+
+if (offs < start) {
+/* This is not a valid return by lseek(). We are safe to just return
+ * -EIO in this case, and we'll treat it like D4. */
+return -EIO;
+}
if (offs > start) {
/* D2: in hole, next data at offs */
@@ -2146,7 +2151,12 @@ static int find_allocation(BlockDriverState *bs, off_t
start,
if (offs < 0) {
return -errno; /* D1 and (H3 or H4) */
}
-assert(offs >= start);
+
+if (offs < start) {
+/* This is not a valid return by lseek(). We are safe to just return
+ * -EIO in this case, and we'll treat it like H4. */
+return -EIO;
+}
if (offs > start) {
/*
--
2.13.6
Re: [Qemu-devel] [PATCH qemu] vfio: Print address space address when cannot map MMIO for DMA
On 29/3/18 9:14 pm, Auger Eric wrote:
> Hi Alexey,
> On 29/03/18 03:55, Alexey Kardashevskiy wrote:
>> On 29/3/18 8:03 am, Auger Eric wrote:
>>> Hi Alexey, Alex,
>>> On 22/03/18 09:18, Alexey Kardashevskiy wrote:
The 567b5b309abe ("vfio/pci: Relax DMA map errors for MMIO regions") added
an error message if a passed memory section address or size is not aligned
to the minimal IOMMU page size. However although it checks
offset_within_address_space for the alignment, offset_within_region is
printed instead which makes it harder to find out what device caused
the message so this replaces offset_within_region with
offset_within_address_space.
While we are here, this replaces '..' with 'size=' (as the second number
is a size, not an end offset) and adds a memory region name.
Fixes: 567b5b309abe "vfio/pci: Relax DMA map errors for MMIO regions"
Signed-off-by: Alexey Kardashevskiy
>>> The patch indeed fixes the reported format issues.
>>>
>>> However I have some other concerns with the info that is reported to the
>>> end-user. See below.
>>>
>>> Assigning an e1000e device with a 64kB host, here are the traces I get:
>>>
>>> Region XXX is not aligned to 0x1 and cannot be mapped for DMA
>>>
>>> "0004:01:00.0 BAR 3 mmaps[0]" 0x100a0050 size=0x3fb0
>>> "0004:01:00.0 BAR 3 mmaps[0]" 0x100a0050 size=0xffb0
>>> "0004:01:00.0 BAR 3 mmaps[0]" 0x100a0050 size=0x3fb0
>>> "0004:01:00.0 BAR 3 mmaps[0]" 0x100a0050 size=0xffb0
>>> "0004:01:00.0 BAR 3 mmaps[0]" 0x100a0050 size=0x3fb0
>>> "0004:01:00.0 BAR 3 mmaps[0]" 0x100a4808 size=0xb7f8
>>> "0004:01:00.0 BAR 3 mmaps[0]" 0x100e0050 size=0x3fb0
>>> "0004:01:00.0 BAR 3 mmaps[0]" 0x100e4808 size=0xb7f8
>>>
>>> It took me some time to understand what happens but here is now my
>>> understanding:
>>>
>>> 1) When looking at vfio_pci_write_config() pdev->io_regions[bar].addr =
>>> bar_addr in vfio_sub_page_bar_update_mapping() I see the following values:
>>>
>>> UNMAPPED -> 0x0 ->UNMAPPED -> 0x100a -> UNMAPPED -> 0x100a ->
>>> UNMAPPED -> 0x100e
>>>
>>> vfio_sub_page_bar_update_mapping() create mrs with base bar at
>>> 0x100a and 0x100e successively, hence the
>>> vfio_listener_region_add on 0x100a. Indeed, 0x0-0x50 msix-table mmio
>>> region induces some memory section at 0x100a0050 and 0x100e50 successively.
>>>
>>> However this is confusing for the end-user who only has access to the
>>> final mapping (0x100e) through lspi [1].
>>
>>
>> The trace shows that at least at some point the BAR actually was
>> 0x100a, I find this info rather useful than confusing as it might
>> expose a bug of some sort, for example.
>>
>> The user also has access to the MR name which is the host PCI address + BAR
>> index, how is that confusing?
>
> To me it is confusing since it does not match the final location of bar3
> as output by lspci. I couldn't understanding how 0x100a related to bar3.
PCI resource reallocation is not that rate on PPC, at least, so I am kinda
used to it...
>>> 2) The changes in the size (0x3fb0 <-> 0xffb0) relate to the extension
>>> of the 16kB bar to 64kB in vfio_sub_page_bar_update_mapping
3) Also it happens that I have a virtio-scsi-pci device that is put just
>>> after the BAR3 at 0x100a4000 and 0x100e4000 successively. The device has
>>
>> e1000e gets aligned to 64k but this one avoids the alignment for some reason?
>
> Yes I will enquire about the allocation policy
>>
>>
>>> its own msi-table and pba mmio regions[2]. As mmaps[0] is extended to
>>> 64kB (with prio 0), we have those MMIO regions which result in new
>>> memory sections, which cause vfio_listener_region_add calls. This
>>> typically explains why we get a warning on 0x100e4808 (0xb7f8). By the
>>> way I don't get why we don't have a trace for "0004:01:00.0 BAR 3
>>> mmaps[0]" 0x100e4040 size=0x7c0, ie. mmaps[0] space between
>>> virtio-scsi-pci msic-table and pba.
>>
>>
>> "info mtree -f" might give a hint how MRs got resolved, could it end up
>> being emulated (==skipped by the vfio listener)?
>
> Actually that's what is strange as I can see it in info mtree -f output. See
> at the end of the mail.
Hm. Looks strange. Would be nice to know why...
>>> So at the end of the day, my fear is all those info become really
>>> frightening and confusing for the end-user and even not relevant
>>> (0x100a stuff). So I would rather simply remove the trace in 2.12
>>> until we find a place where we could generate a clear hint for the
>>> end-user, suggesting to relocate the msix bar.
>>>
>>> Thoughts?
>>
>> Please post complete "lspci -v" output for both pci devices and "info mtree
>> -f" (in addition to "info mtree", not instead).
>
> see at the end
>>
>> In general, the error_report() could be removed as we did not have any
>> indication of not mapping before so we do not have to start now, I am just
>> missing the point here - the message exposes potentially not-working P2P
>> which is useful
Re: [Qemu-devel] Loadable block drivers?
On Tue, 04/03 13:17, Lindsay Mathieson wrote: > On 3 April 2018 at 13:11, Fam Zheng wrote: > > > On Tue, 04/03 12:59, Lindsay Mathieson wrote: > > > Hi all, was looking at developing a block driver for qemu - have examined > > > the drivers at: > > > > > > https://github.com/qemu/qemu/tree/master/block > > > > > > And it seems straightforward enough. > > > > > > One thing that is unclear - all the drivers appear to be compiled > > directly > > > into qemu. Is there no way to load them dynamically as .so modules? > > > > './configure --enable-modules' will enable building block drivers as .so > > objects, and they are loaded dynamically. These are in-tree .so modules; > > out-of-tree modules like in Linux kernel are intentionally forbidden. > > > > Fam > > > > > > Rats, I take it that means I can't develop a testing block module and load > it with an pre-existing qemu install. No, that's not possible. Fam
Re: [Qemu-devel] Loadable block drivers?
On 3 April 2018 at 13:11, Fam Zheng wrote: > On Tue, 04/03 12:59, Lindsay Mathieson wrote: > > Hi all, was looking at developing a block driver for qemu - have examined > > the drivers at: > > > > https://github.com/qemu/qemu/tree/master/block > > > > And it seems straightforward enough. > > > > One thing that is unclear - all the drivers appear to be compiled > directly > > into qemu. Is there no way to load them dynamically as .so modules? > > './configure --enable-modules' will enable building block drivers as .so > objects, and they are loaded dynamically. These are in-tree .so modules; > out-of-tree modules like in Linux kernel are intentionally forbidden. > > Fam > Rats, I take it that means I can't develop a testing block module and load it with an pre-existing qemu install. thanks. -- Lindsay
Re: [Qemu-devel] Loadable block drivers?
On Tue, 04/03 12:59, Lindsay Mathieson wrote: > Hi all, was looking at developing a block driver for qemu - have examined > the drivers at: > > https://github.com/qemu/qemu/tree/master/block > > And it seems straightforward enough. > > One thing that is unclear - all the drivers appear to be compiled directly > into qemu. Is there no way to load them dynamically as .so modules? './configure --enable-modules' will enable building block drivers as .so objects, and they are loaded dynamically. These are in-tree .so modules; out-of-tree modules like in Linux kernel are intentionally forbidden. Fam
[Qemu-devel] Loadable block drivers?
Hi all, was looking at developing a block driver for qemu - have examined the drivers at: https://github.com/qemu/qemu/tree/master/block And it seems straightforward enough. One thing that is unclear - all the drivers appear to be compiled directly into qemu. Is there no way to load them dynamically as .so modules? Thanks, -- Lindsay
Re: [Qemu-devel] [PULL 0/1] RISC-V: Critical fixes for QEMU 2.12
On Sun, Apr 1, 2018 at 11:49 AM, Richard W.M. Jones wrote: > On Fri, Mar 30, 2018 at 10:08:23AM -0700, Michael Clark wrote: > > Hi Peter, > > > > I had tested Richard's proper fix but we didn't have a PR or the required > > Reviewed-by and Signed-off-by so I made the PR for the conservative fix, > > "Richard" is me or Richard Henderson? Anyway if you meant Stefan > O'Rear's fix (https://github.com/rwmjones/fedora-riscv-bootstrap/blob/ > master/stage1-riscv-qemu/force-float-save.patch) > then it is my understanding that this is also just a workaround. Apologies for not being precise. Richard Henderson has a comprehensive fix that correctly marks mstatus.FS dirty inside of FP arithmetic and FP loads. This logic is missing in the current QEMU, hence the bug. i.e. QEMU currently only has logic to throw exceptions if mstatus.FS state is set of off, but FP arithmetic and FP loads do not cause state change to dirty. I submitted the pull request for your's/Stefan's workaround so that QEMU 2.12 has working FP context switching under Linux (always returning dirty or off is valid implementation choice according to the specification), given Richard Henderson had not made a PR for his more comprehensive fix, with the rationale that we could implement the comprehensive fix for QEMU 2.13. At this point, I think neither of the fixes have gone in due to timing i.e. the Easter Holidays, so vendors will need either your's/Stefan's workaround or Richard Henderson's 2 patch series which he sent to the mailing list. - https://lists.nongnu.org/archive/html/qemu-devel/2018-03/msg07034.html
Re: [Qemu-devel] [PATCH v2] i386: add KnightsMill cpu model
On Mon, Apr 02, 2018 at 01:14:30PM +0800, Boqun Feng wrote:
> Ping ;-)
It missed soft feature freeze (March 13th), so I will queue this
for 2.13. Thanks!
>
> Regards,
> Boqun
>
> On Tue, Mar 20, 2018 at 08:08:15AM +0800, Boqun Feng wrote:
> > A new cpu model called "KnightsMill" is added to model Knights Mill
> > processors. Compared to "Skylake-Server" cpu model, the following
> > features are added:
> >
> > avx512_4vnniw avx512_4fmaps avx512pf avx512er avx512_vpopcntdq
> >
> > and the following features are removed:
> >
> > pcid invpcid clflushopt avx512dq avx512bw clwb smap rtm mpx
> > xsavec xgetbv1 hle
> >
> > Signed-off-by: Boqun Feng
> > ---
> > v1 --> v2:
> >
> > * Change the model name to "KnightsMill" as per Daniel's
> > suggestion.
> >
> > target/i386/cpu.c | 42 ++
> > 1 file changed, 42 insertions(+)
> >
> > diff --git a/target/i386/cpu.c b/target/i386/cpu.c
> > index 2c04645ceac9..c484afdb7023 100644
> > --- a/target/i386/cpu.c
> > +++ b/target/i386/cpu.c
> > @@ -1795,6 +1795,48 @@ static X86CPUDefinition builtin_x86_defs[] = {
> > .xlevel = 0x8008,
> > .model_id = "Intel Xeon Processor (Skylake, IBRS)",
> > },
> > +{
> > +.name = "KnightsMill",
> > +.level = 0xd,
> > +.vendor = CPUID_VENDOR_INTEL,
> > +.family = 6,
> > +.model = 133,
> > +.stepping = 0,
> > +.features[FEAT_1_EDX] =
> > +CPUID_VME | CPUID_SS | CPUID_SSE2 | CPUID_SSE | CPUID_FXSR |
> > +CPUID_MMX | CPUID_CLFLUSH | CPUID_PSE36 | CPUID_PAT |
> > CPUID_CMOV |
> > +CPUID_MCA | CPUID_PGE | CPUID_MTRR | CPUID_SEP | CPUID_APIC |
> > +CPUID_CX8 | CPUID_MCE | CPUID_PAE | CPUID_MSR | CPUID_TSC |
> > +CPUID_PSE | CPUID_DE | CPUID_FP87,
> > +.features[FEAT_1_ECX] =
> > +CPUID_EXT_AVX | CPUID_EXT_XSAVE | CPUID_EXT_AES |
> > +CPUID_EXT_POPCNT | CPUID_EXT_X2APIC | CPUID_EXT_SSE42 |
> > +CPUID_EXT_SSE41 | CPUID_EXT_CX16 | CPUID_EXT_SSSE3 |
> > +CPUID_EXT_PCLMULQDQ | CPUID_EXT_SSE3 |
> > +CPUID_EXT_TSC_DEADLINE_TIMER | CPUID_EXT_FMA | CPUID_EXT_MOVBE
> > |
> > +CPUID_EXT_F16C | CPUID_EXT_RDRAND,
> > +.features[FEAT_8000_0001_EDX] =
> > +CPUID_EXT2_LM | CPUID_EXT2_PDPE1GB | CPUID_EXT2_RDTSCP |
> > +CPUID_EXT2_NX | CPUID_EXT2_SYSCALL,
> > +.features[FEAT_8000_0001_ECX] =
> > +CPUID_EXT3_ABM | CPUID_EXT3_LAHF_LM | CPUID_EXT3_3DNOWPREFETCH,
> > +.features[FEAT_7_0_EBX] =
> > +CPUID_7_0_EBX_FSGSBASE | CPUID_7_0_EBX_BMI1 |
> > CPUID_7_0_EBX_AVX2 |
> > +CPUID_7_0_EBX_SMEP | CPUID_7_0_EBX_BMI2 | CPUID_7_0_EBX_ERMS |
> > +CPUID_7_0_EBX_RDSEED | CPUID_7_0_EBX_ADX |
> > CPUID_7_0_EBX_AVX512F |
> > +CPUID_7_0_EBX_AVX512CD | CPUID_7_0_EBX_AVX512PF |
> > +CPUID_7_0_EBX_AVX512ER,
> > +.features[FEAT_7_0_ECX] =
> > +CPUID_7_0_ECX_AVX512_VPOPCNTDQ,
> > +.features[FEAT_7_0_EDX] =
> > +CPUID_7_0_EDX_AVX512_4VNNIW | CPUID_7_0_EDX_AVX512_4FMAPS,
> > +.features[FEAT_XSAVE] =
> > +CPUID_XSAVE_XSAVEOPT,
> > +.features[FEAT_6_EAX] =
> > +CPUID_6_EAX_ARAT,
> > +.xlevel = 0x8008,
> > +.model_id = "Intel Xeon Phi Processor (Knights Mill)",
> > +},
> > {
> > .name = "Opteron_G1",
> > .level = 5,
> > --
> > 2.16.1
> >
--
Eduardo
Re: [Qemu-devel] [PATCH for-2.13] Add host_memory_backend_pagesize() helper
On Thu, Mar 29, 2018 at 04:25:37PM +1100, David Gibson wrote:
> There are a couple places (one generic, one target specific) where we need
> to get the host page size associated with a particular memory backend. I
> have some upcoming code which will add another place which wants this. So,
> for convenience, add a helper function to calculate this.
>
> host_memory_backend_pagesize() returns the host pagesize for a given
> HostMemoryBackend object, or for the default backend (-mem-path) if passed
> NULL.
>
> Signed-off-by: David Gibson
> ---
> backends/hostmem.c | 20
> exec.c | 21 +
> include/sysemu/hostmem.h | 2 ++
> target/ppc/kvm.c | 10 +-
> 4 files changed, 28 insertions(+), 25 deletions(-)
>
> diff --git a/backends/hostmem.c b/backends/hostmem.c
> index f61093654e..b6a60cfc5d 100644
> --- a/backends/hostmem.c
> +++ b/backends/hostmem.c
> @@ -18,6 +18,7 @@
> #include "qapi/visitor.h"
> #include "qemu/config-file.h"
> #include "qom/object_interfaces.h"
> +#include "qemu/mmap-alloc.h"
>
> #ifdef CONFIG_NUMA
> #include
> @@ -262,6 +263,25 @@ bool host_memory_backend_is_mapped(HostMemoryBackend
> *backend)
> return backend->is_mapped;
> }
>
> +long host_memory_backend_pagesize(HostMemoryBackend *memdev)
qemu_mempath_getpagesize() returns size_t. Why are you using
long here?
> +{
> +const char *path = NULL;
> +
> +#ifdef __linux__
> +if (memdev) {
> +path = object_property_get_str(OBJECT(memdev), "mem-path", NULL);
> +} else {
> +path = mem_path;
> +}
> +#endif
> +
> +if (path) {
> +return qemu_mempath_getpagesize(path);
> +} else {
> +return getpagesize();
Isn't it simpler to make qemu_mempath_getpagesize() handle
path==NULL?
> +}
> +}
> +
> static void
> host_memory_backend_memory_complete(UserCreatable *uc, Error **errp)
> {
> diff --git a/exec.c b/exec.c
> index c09bd93df3..04856c2402 100644
> --- a/exec.c
> +++ b/exec.c
> @@ -1488,18 +1488,13 @@ void ram_block_dump(Monitor *mon)
> */
> static int find_max_supported_pagesize(Object *obj, void *opaque)
> {
> -char *mem_path;
> long *hpsize_min = opaque;
>
> if (object_dynamic_cast(obj, TYPE_MEMORY_BACKEND)) {
> -mem_path = object_property_get_str(obj, "mem-path", NULL);
> -if (mem_path) {
> -long hpsize = qemu_mempath_getpagesize(mem_path);
> -if (hpsize < *hpsize_min) {
> -*hpsize_min = hpsize;
> -}
> -} else {
> -*hpsize_min = getpagesize();
> +long hpsize = host_memory_backend_pagesize(MEMORY_BACKEND(obj));
So in this caller, `backend` is always non-NULL...
> +
> +if (hpsize < *hpsize_min) {
> +*hpsize_min = hpsize;
> }
> }
>
> @@ -1509,15 +1504,9 @@ static int find_max_supported_pagesize(Object *obj,
> void *opaque)
> long qemu_getrampagesize(void)
> {
> long hpsize = LONG_MAX;
> -long mainrampagesize;
> +long mainrampagesize = host_memory_backend_pagesize(NULL);
...on this caller `backend` is always NULL...
> Object *memdev_root;
>
> -if (mem_path) {
> -mainrampagesize = qemu_mempath_getpagesize(mem_path);
> -} else {
> -mainrampagesize = getpagesize();
> -}
> -
> /* it's possible we have memory-backend objects with
> * hugepage-backed RAM. these may get mapped into system
> * address space via -numa parameters or memory hotplug
[...]
> diff --git a/target/ppc/kvm.c b/target/ppc/kvm.c
> index b329cd8173..0adcf18c9f 100644
> --- a/target/ppc/kvm.c
> +++ b/target/ppc/kvm.c
> @@ -493,15 +493,7 @@ static void kvm_fixup_page_sizes(PowerPCCPU *cpu)
> bool kvmppc_is_mem_backend_page_size_ok(const char *obj_path)
> {
> Object *mem_obj = object_resolve_path(obj_path, NULL);
> -char *mempath = object_property_get_str(mem_obj, "mem-path", NULL);
> -long pagesize;
> -
> -if (mempath) {
> -pagesize = qemu_mempath_getpagesize(mempath);
> -g_free(mempath);
> -} else {
> -pagesize = getpagesize();
> -}
> +long pagesize = host_memory_backend_pagesize(MEMORY_BACKEND(mem_obj));
>
...and here `backend` is always non-NULL.
If there's no caller that relies on both code paths, why overload
a single function for two different operations?
I would simply make qemu_mempath_getpagesize() work if path is
NULL, use qemu_mempath_getpagesize(mem_path) at
qemu_getrampagesize(), and make host_memory_backend_pagesize()
assume require a non-NULL `memdev`.
> +long host_memory_backend_pagesize(HostMemoryBackend *memdev)
Why is the code duplicated in target/ppc/kvm.c?
> +{
> +const char *path = NULL;
> +
> +#ifdef __linux__
> +if (memdev) {
> +path = object_property_get_str(OBJECT(memdev), "mem-path", NULL);
> +} else {
> +path = mem_path;
> +}
> +#endif
> +
> +if (path) {
> +return q
Re: [Qemu-devel] [PULL 0/2] Ide patches
On Mon, 04/02 12:34, John Snow wrote: > > > On 03/31/2018 03:08 AM, no-re...@patchew.org wrote: > > Hi, > > > > This series failed docker-build@min-glib build test. Please find the > > testing commands and > > their output below. If you have Docker installed, you can probably > > reproduce it > > locally. > > > > Type: series > > Message-id: 20180327045646.21112-1-js...@redhat.com > > Subject: [Qemu-devel] [PULL 0/2] Ide patches > > > > === TEST SCRIPT BEGIN === > > #!/bin/bash > > set -e > > git submodule update --init dtc > > # Let docker tests dump environment info > > export SHOW_ENV=1 > > export J=8 > > time make docker-test-build@min-glib > > === TEST SCRIPT END === > > > > Updating 3c8cf5a9c21ff8782164d1def7f44bd888713384 > > Switched to a new branch 'test' > > 49a0f26939 Merge remote-tracking branch > > 'remotes/rth/tags/pull-tcg-20180328' into staging > > a60769352d tcg: Mark muluh_i64 and mulsh_i64 as 64-bit ops > > > > === OUTPUT BEGIN === > > Submodule 'dtc' (git://git.qemu-project.org/dtc.git) registered for path > > 'dtc' > > Cloning into '/var/tmp/patchew-tester-tmp-vi1_8690/src/dtc'... > > Submodule path 'dtc': checked out 'e54388015af1fb4bf04d0bca99caba1074d9cc42' > > BUILD min-glib > > make[1]: Entering directory '/var/tmp/patchew-tester-tmp-vi1_8690/src' > > GEN > > /var/tmp/patchew-tester-tmp-vi1_8690/src/docker-src.2018-03-31-03.07.40.30023/qemu.tar > > Cloning into > > '/var/tmp/patchew-tester-tmp-vi1_8690/src/docker-src.2018-03-31-03.07.40.30023/qemu.tar.vroot'... > > done. > > Your branch is up-to-date with 'origin/test'. > > Submodule 'dtc' (git://git.qemu-project.org/dtc.git) registered for path > > 'dtc' > > Cloning into > > '/var/tmp/patchew-tester-tmp-vi1_8690/src/docker-src.2018-03-31-03.07.40.30023/qemu.tar.vroot/dtc'... > > Submodule path 'dtc': checked out 'e54388015af1fb4bf04d0bca99caba1074d9cc42' > > Submodule 'ui/keycodemapdb' (git://git.qemu.org/keycodemapdb.git) > > registered for path 'ui/keycodemapdb' > > Cloning into > > '/var/tmp/patchew-tester-tmp-vi1_8690/src/docker-src.2018-03-31-03.07.40.30023/qemu.tar.vroot/ui/keycodemapdb'... > > Submodule path 'ui/keycodemapdb': checked out > > '6b3d716e2b6472eb7189d3220552280ef3d832ce' > > tar: > > /var/tmp/patchew-tester-tmp-vi1_8690/src/docker-src.2018-03-31-03.07.40.30023/qemu.tar: > > Wrote only 2048 of 10240 bytes > > tar: Error is not recoverable: exiting now > > failed to create tar file > > COPYRUNNER > > RUN test-build in qemu:min-glib > > tar: Unexpected EOF in archive > > tar: Unexpected EOF in archive > > tar: Error is not recoverable: exiting now > > /var/tmp/qemu/run: line 32: prep_fail: command not found > > Environment variables: > > HOSTNAME=d3de5b81f6a8 > > MAKEFLAGS= -j8 > > J=8 > > CCACHE_DIR=/var/tmp/ccache > > EXTRA_CONFIGURE_OPTS= > > V= > > SHOW_ENV=1 > > PATH=/usr/lib/ccache:/usr/lib64/ccache:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin > > PWD=/ > > TARGET_LIST= > > SHLVL=1 > > HOME=/root > > TEST_DIR=/tmp/qemu-test > > FEATURES= dtc > > DEBUG= > > _=/usr/bin/env > > > > Configure options: > > --enable-werror --target-list=x86_64-softmmu,aarch64-softmmu > > --prefix=/tmp/qemu-test/install > > > > ERROR: DTC (libfdt) version >= 1.4.2 not present. > >Please install the DTC (libfdt) devel package > > > > Environment problems? > > > Traceback (most recent call last): > > File "./tests/docker/docker.py", line 407, in > > sys.exit(main()) > > File "./tests/docker/docker.py", line 404, in main > > return args.cmdobj.run(args, argv) > > File "./tests/docker/docker.py", line 261, in run > > return Docker().run(argv, args.keep, quiet=args.quiet) > > File "./tests/docker/docker.py", line 229, in run > > quiet=quiet) > > File "./tests/docker/docker.py", line 147, in _do_check > > return subprocess.check_call(self._command + cmd, **kwargs) > > File "/usr/lib64/python2.7/subprocess.py", line 186, in check_call > > raise CalledProcessError(retcode, cmd) > > subprocess.CalledProcessError: Command '['docker', 'run', '--label', > > 'com.qemu.instance.uuid=3f76e41234b211e8813a52540069c830', '-u', '0', > > '--security-opt', 'seccomp=unconfined', '--rm', '--net=none', '-e', > > 'TARGET_LIST=', '-e', 'EXTRA_CONFIGURE_OPTS=', '-e', 'V=', '-e', 'J=8', > > '-e', 'DEBUG=', '-e', 'SHOW_ENV=1', '-e', 'CCACHE_DIR=/var/tmp/ccache', > > '-v', '/root/.cache/qemu-docker-ccache:/var/tmp/ccache:z', '-v', > > '/var/tmp/patchew-tester-tmp-vi1_8690/src/docker-src.2018-03-31-03.07.40.30023:/var/tmp/qemu:z,ro', > > 'qemu:min-glib', '/var/tmp/qemu/run', 'test-build']' returned non-zero > > exit status 1 > > make[1]: *** [tests/docker/Makefile.include:129: docker-run] Error 1 > > make[1]: Leaving directory '/var/tmp/patchew-tester-tmp-vi1_8690/src' > > make: *** [tests/docker/Makefile.include:163: > > docker-run-test-build@min-glib] Error 2 > > > > real0m51.988s > > user0m9.352s > > sys 0m6.949s > > === OUTP
Re: [Qemu-devel] [PATCH 3/3] sev/i386: fix memory leak in sev_guest_init()
On Thu, Mar 29, 2018 at 11:10:21AM +0200, Greg Kurz wrote: > The string returned by object_property_get_str() is dynamically allocated. > > Fixes: d8575c6c0242b > Signed-off-by: Greg Kurz Queued, thanks. -- Eduardo
Re: [Qemu-devel] [PATCH 1/3] exec: fix memory leak in find_max_supported_pagesize()
On Thu, Mar 29, 2018 at 11:09:46AM +0200, Greg Kurz wrote: > The string returned by object_property_get_str() is dynamically allocated. > > Signed-off-by: Greg Kurz Queued, thanks. -- Eduardo
Re: [Qemu-devel] [PATCH] WHPX fixes an issue with CPUID 1 not returning CPUID_EXT_HYPERVISOR
On Wed, Mar 28, 2018 at 08:48:54PM +, Justin Terry (VM) wrote:
> Hey Eduardo
>
> Responses inline. Thanks!
>
> > -Original Message-
> > From: Eduardo Habkost
> > Sent: Wednesday, March 28, 2018 10:51 AM
> > To: Justin Terry (VM)
> > Cc: qemu-devel@nongnu.org; pbonz...@redhat.com; r...@twiddle.net
> > Subject: Re: [PATCH] WHPX fixes an issue with CPUID 1 not returning
> > CPUID_EXT_HYPERVISOR
> >
> > On Mon, Mar 26, 2018 at 10:06:58AM -0700, Justin Terry (VM) wrote:
> > > Implements the CPUID trap for CPUID 1 to include the
> > > CPUID_EXT_HYPERVISOR flag in the ECX results. This was preventing some
> > > older linux kernels from booting when trying to access MSR's that dont
> > > make sense when virtualized.
> > >
> > > Signed-off-by: Justin Terry (VM)
> > > ---
> > > target/i386/whpx-all.c | 79
> > > +-
> > > 1 file changed, 78 insertions(+), 1 deletion(-)
> > >
> > > diff --git a/target/i386/whpx-all.c b/target/i386/whpx-all.c index
> > > bf33d320bf..58435178a4 100644
> > > --- a/target/i386/whpx-all.c
> > > +++ b/target/i386/whpx-all.c
> > > @@ -911,12 +911,62 @@ static int whpx_vcpu_run(CPUState *cpu)
> > > ret = 1;
> > > break;
> > >
> > > +case WHvRunVpExitReasonX64Cpuid: {
> > > +WHV_REGISTER_VALUE reg_values[5] = {0};
> > > +WHV_REGISTER_NAME reg_names[5];
> > > +UINT32 reg_count = 5;
> > > +UINT64 rip, rax, rcx, rdx, rbx;
> > > +
> > > +rip = vcpu->exit_ctx.VpContext.Rip +
> > > + vcpu->exit_ctx.VpContext.InstructionLength;
> > > +switch (vcpu->exit_ctx.CpuidAccess.Rax) {
> > > +case 1:
> > > +rax = vcpu->exit_ctx.CpuidAccess.DefaultResultRax;
> > > +/* Advertise that we are running on a hypervisor */
> > > +rcx =
> > > +vcpu->exit_ctx.CpuidAccess.DefaultResultRcx |
> > > +CPUID_EXT_HYPERVISOR;
> > > +
> > > +rdx = vcpu->exit_ctx.CpuidAccess.DefaultResultRdx;
> > > +rbx = vcpu->exit_ctx.CpuidAccess.DefaultResultRbx;
> > > +break;
> > > +default:
> > > +rax = vcpu->exit_ctx.CpuidAccess.DefaultResultRax;
> > > +rcx = vcpu->exit_ctx.CpuidAccess.DefaultResultRcx;
> > > +rdx = vcpu->exit_ctx.CpuidAccess.DefaultResultRdx;
> > > +rbx = vcpu->exit_ctx.CpuidAccess.DefaultResultRbx;
> >
> > Interesting, so the WHPX API already tries to provide default values for the
> > CPUID leaves. Would it make sense to try and use the values returned by
> > cpu_x86_cpuid() in the future?
> >
> > Is there a way to get the default CPUID results from the WHPX API without
> > calling WHvRunVirtualProcessor(), so QEMU can be aware of what exactly
> > the guest is seeing on CPUID?
>
> The platform now has two ways to interact with CPUID.
>
> 1. (As the code is doing now). At partition creation time you
> can register for specific CPUID exits and then respond to the
> CPUID with your custom answer or with the Hypervisor defaults
> that were forwarded to you. Unfortunately, QEMU has no way to
> know the Hypervisor default ahead of time but QEMU can make at
> least make a runtime decision about how to respond.
> 2. At partition creation time the platform allows QEMU to
> inject (set) the default responses for specific CPUID exits.
> This can now be done by setting the `WHV_X64_CPUID_RESULT` in
> the `CpuidResultList` of `WHV_PARTITION_PROPERTY` to the exit
> values QEMU wants. So effectively you can know the answers
> ahead of time for any that you set but the answers are not
> dynamic.
>
> The only issues/questions I have there are:
>
> If we use [1] (like the code is now) I don't see any way to
> keep the exits in cpu_x86_cpuid() matched up with the
> registered exits to WHPX. This means that WHPX would not be
> called in these cases and would instead get the Hypervisor
> default rather than the answer from cpu_x86_cpuid().
I assume you could call cpu_x86_cpuid() on every CPUID exit and
override the hypervisor default completely. Not a very efficient
solution, but seems simple to implement.
But I'm still not sure if you really want to override the
hypervisor defaults completely (see below).
>
> If we use [2] to inject the answers at creation time WHPX needs
> access to the CPUX86State at accel init which also doesn't seem
> to be possible in QEMU today. WHPX could basically just call
> cpu_x86_cpuid() for each CPUID QEMU cares about and plumb the
> answer before start. This has the best performance as we avoid
> the additional exits but has an issue in that the results must
> be known ahead of time.
You already have a hook into CPU initialization at
whpx_init_vcpu(), wouldn't it work for you?
>
> And, we could obviously use a hybrid of the two for cases we
> know. Do you have any ideas that I could try o
Re: [Qemu-devel] [PULL 0/2] M68k for 2.12 patches
On 04/02/2018 02:05 PM, Laurent Vivier wrote: > Le 02/04/2018 à 20:13, Rob Landley a écrit : >>> The branch to use is q800-dev ... >> It booted Linux to a shell prompt, I could wget a file from the internet, and >> /home had the 2 gigabyte ext3 mount from the virtual block device. >> >> I.E. it works for me. Why is it still out of tree? ... > I have to submit some enhancements in the FPU emulation... > I have to add some specific m68k hardware emulation... > but via support should be rewritten... > I have to update some existing hardware emulation... ... > So, this only needs some work and time. 10 years ago: https://lists.gnu.org/archive/html/qemu-devel/2007-10/msg00248.html 6 years ago: https://lists.gnu.org/archive/html/qemu-devel/2011-08/msg02123.html > I hope q800 will be available in QEMU 2.13. Good luck, Rob
[Qemu-devel] [PATCH] hw/arm: Allow manually specified /psci node
Change the code to avoid exiting QEMU if user provided DTB contains
manually specified /psci node and skip any /psci related fixups
instead.
Fixes: 4cbca7d9b4 ("hw/arm: Move virt's PSCI DT fixup code to
arm/boot.c")
Cc: Peter Maydell
Cc: Marc Zyngier
Cc: qemu-devel@nongnu.org
Cc: qemu-...@nongnu.org
Signed-off-by: Andrey Smirnov
---
Mark:
Sorry about the inconvenience, here's the fix (hopefully) to the
prolem you reported in [1]. Let me know if skipping all PSCI related
DTB fixup if /psic node is present is not the behaviour you had in
mind for your suggested fix.
Thanks,
Andrey Smirnov
[1] http://lists.gnu.org/archive/html/qemu-devel/2018-03/msg06914.html
hw/arm/boot.c | 10 ++
1 file changed, 10 insertions(+)
diff --git a/hw/arm/boot.c b/hw/arm/boot.c
index 6d0c92ab88..d9f9375cdb 100644
--- a/hw/arm/boot.c
+++ b/hw/arm/boot.c
@@ -422,6 +422,7 @@ static void fdt_add_psci_node(void *fdt)
ARMCPU *armcpu = ARM_CPU(qemu_get_cpu(0));
const char *psci_method;
int64_t psci_conduit;
+int rc;
psci_conduit = object_property_get_int(OBJECT(armcpu),
"psci-conduit",
@@ -439,6 +440,15 @@ static void fdt_add_psci_node(void *fdt)
g_assert_not_reached();
}
+/*
+ * If /psci node is present in provided DTB, assume that no fixup
+ * is necessary and all PSCI configuration should be taken as-is
+ */
+rc = fdt_path_offset(fdt, "/psci");
+if (rc >= 0) {
+return;
+}
+
qemu_fdt_add_subnode(fdt, "/psci");
if (armcpu->psci_version == 2) {
const char comp[] = "arm,psci-0.2\0arm,psci";
--
2.14.3
Re: [Qemu-devel] [PATCH v2 0/3] Add new CD-ROM related qtests
On 02.04.2018 21:34, John Snow wrote: > > > On 04/02/2018 02:39 PM, Thomas Huth wrote: >> On 29.03.2018 20:28, John Snow wrote: >>> >>> >>> On 03/16/2018 01:39 AM, Thomas Huth wrote: With one of my clean-up patches (see commit 1454509726719e0933c800), I recently accidentially broke the "-cdrom" parameter (more precisely "-drive if=scsi") on a couple of boards, since there was no error detected during the "make check" regression testing. This is clearly an indication that we are lacking tests in this area. So this small patch series now introduces some tests for CD-ROM drives: The first two patches introduce the possibility to check that booting from CD-ROM drives still works fine for x86 and s390x, and the third patch adds a test that certain machines can at least still be started with the "-cdrom" parameter (i.e. that test would have catched the mistake that I did with my SCSI cleanup patch). v2: - Use g_spawn_sync() instead of execlp() to run genisoimage - The "-cdrom" parameter test is now run on all architectures (with machine "none" for the machines that are not explicitly checked) - Some rewordings and improved comments here and there Thomas Huth (3): tests/boot-sector: Add magic bytes to s390x boot code header tests/cdrom-test: Test booting from CD-ROM ISO image file tests/cdrom-test: Test that -cdrom parameter is working tests/Makefile.include | 2 + tests/boot-sector.c| 9 +- tests/cdrom-test.c | 222 + 3 files changed, 230 insertions(+), 3 deletions(-) create mode 100644 tests/cdrom-test.c >>> >>> New file, but no edit to MAINTAINERS. >> >> Which section do you suggest? It tests IDE CD-ROMs, SCSI CD-ROMs, and >> even virtio-block (on s390x) ... so I have a hard time to decide where >> this should belong to... >> >> Thomas >> > > I was hoping you'd figure it out, but fine :D > > You can stick it under my section if you want, but I'll probably defer > to you if the s390x parts break. Ok, thanks. But in the long run, we might even need a generic "QTESTS" section in the MAINTAINERS file, since most of the qtests are currently not listed there. And while we're at it, we should maybe also move the qtests to a separate folder tests/qtests/ or so, so that it is clearer which of the tests is a qtest and which are something different. I'll try to come up with some patches once the hard freeze is over... Thomas
Re: [Qemu-devel] [PATCH v2 0/3] Add new CD-ROM related qtests
On 04/02/2018 02:39 PM, Thomas Huth wrote: > On 29.03.2018 20:28, John Snow wrote: >> >> >> On 03/16/2018 01:39 AM, Thomas Huth wrote: >>> With one of my clean-up patches (see commit 1454509726719e0933c800), I >>> recently accidentially broke the "-cdrom" parameter (more precisely >>> "-drive if=scsi") on a couple of boards, since there was no error >>> detected during the "make check" regression testing. This is clearly an >>> indication that we are lacking tests in this area. >>> So this small patch series now introduces some tests for CD-ROM drives: >>> The first two patches introduce the possibility to check that booting >>> from CD-ROM drives still works fine for x86 and s390x, and the third >>> patch adds a test that certain machines can at least still be started >>> with the "-cdrom" parameter (i.e. that test would have catched the >>> mistake that I did with my SCSI cleanup patch). >>> >>> v2: >>> - Use g_spawn_sync() instead of execlp() to run genisoimage >>> - The "-cdrom" parameter test is now run on all architectures (with >>>machine "none" for the machines that are not explicitly checked) >>> - Some rewordings and improved comments here and there >>> >>> Thomas Huth (3): >>> tests/boot-sector: Add magic bytes to s390x boot code header >>> tests/cdrom-test: Test booting from CD-ROM ISO image file >>> tests/cdrom-test: Test that -cdrom parameter is working >>> >>> tests/Makefile.include | 2 + >>> tests/boot-sector.c| 9 +- >>> tests/cdrom-test.c | 222 >>> + >>> 3 files changed, 230 insertions(+), 3 deletions(-) >>> create mode 100644 tests/cdrom-test.c >>> >> >> New file, but no edit to MAINTAINERS. > > Which section do you suggest? It tests IDE CD-ROMs, SCSI CD-ROMs, and > even virtio-block (on s390x) ... so I have a hard time to decide where > this should belong to... > > Thomas > I was hoping you'd figure it out, but fine :D You can stick it under my section if you want, but I'll probably defer to you if the s390x parts break. --js
Re: [Qemu-devel] [PULL 0/2] M68k for 2.12 patches
Le 02/04/2018 à 20:13, Rob Landley a écrit : > On 03/30/2018 12:00 PM, Laurent Vivier wrote: >> Le 30/03/2018 à 18:54, Rob Landley a écrit : >>> On 03/20/2018 04:08 AM, Laurent Vivier wrote:> This series of patches is >>> needed >>> to fix a problem in the m68k translator that can crash QEMU when translation cache has too many instructions: qemu-m68k: tcg/tcg.c:883: tcg_temp_alloc: Assertion `n < 512' failed. qemu: uncaught target signal 11 (Segmentation fault) - core dumped I have reproduced it in linux user mode, with "ghc", and in system mode with the debian-installer for unstable distro from debian-ports. >>> >>> If someone wanted to follow along with your "boot linux on qemu-system-m68k" >>> work on https://github.com/vivier/qemu-m68k, which of the 51 branches should >>> qemu-system-m68k with like -M q800 or whatever you had working be built >>> from? >> >> The branch to use is q800-dev > > There isn't any m68k support in musl-libc yet, so I grabbed my old > https://github.com/landley/aboriginal project, did a "./build.sh m68k", built > your q800-dev branch, added the m68k-softmmu from that to the start of the > $PATH, and ran "more/dev-environment-from-build.sh m68k". > > It booted Linux to a shell prompt, I could wget a file from the internet, and > /home had the 2 gigabyte ext3 mount from the virtual block device. > > I.E. it works for me. Why is it still out of tree? Remaining patches need some cleanup before being submitted. I have to submit some enhancements in the FPU emulation, but as they modify fpu/softfloat.c, I don't want to put them as is in an m68k pull-req: target/m68k: manage FPU exceptions softfloat: define floatx80_is_any_nan for m68k softfloat: disable floatx80_invalid_encoding() for m68k I have to add some specific m68k hardware emulation: m68k: add via support m68k: add video card q800: Apple Sound Chip (ASC) emulation q800: add Nubus support q800: add a dummy SWIM floppy controller m68k: define Macintosh Quadra 800 but via support should be rewritten as Mark has introduced a new generic mos6522 VIA device. I have to update some existing hardware emulation: ESP: add pseudo-DMA as used by Macintosh escc: introduce a selector for the register bit dp8393x: fix receiving buffer exhaustion dp8393x: put DMA temp buffer in the state, not in the stack dp8393x: manage big endian bus dp8393x: fix dp8393x_receive So, this only needs some work and time. I hope q800 will be available in QEMU 2.13. Thanks, Laurent
Re: [Qemu-devel] [PATCH v2 0/3] Add new CD-ROM related qtests
On 29.03.2018 20:28, John Snow wrote: > > > On 03/16/2018 01:39 AM, Thomas Huth wrote: >> With one of my clean-up patches (see commit 1454509726719e0933c800), I >> recently accidentially broke the "-cdrom" parameter (more precisely >> "-drive if=scsi") on a couple of boards, since there was no error >> detected during the "make check" regression testing. This is clearly an >> indication that we are lacking tests in this area. >> So this small patch series now introduces some tests for CD-ROM drives: >> The first two patches introduce the possibility to check that booting >> from CD-ROM drives still works fine for x86 and s390x, and the third >> patch adds a test that certain machines can at least still be started >> with the "-cdrom" parameter (i.e. that test would have catched the >> mistake that I did with my SCSI cleanup patch). >> >> v2: >> - Use g_spawn_sync() instead of execlp() to run genisoimage >> - The "-cdrom" parameter test is now run on all architectures (with >>machine "none" for the machines that are not explicitly checked) >> - Some rewordings and improved comments here and there >> >> Thomas Huth (3): >> tests/boot-sector: Add magic bytes to s390x boot code header >> tests/cdrom-test: Test booting from CD-ROM ISO image file >> tests/cdrom-test: Test that -cdrom parameter is working >> >> tests/Makefile.include | 2 + >> tests/boot-sector.c| 9 +- >> tests/cdrom-test.c | 222 >> + >> 3 files changed, 230 insertions(+), 3 deletions(-) >> create mode 100644 tests/cdrom-test.c >> > > New file, but no edit to MAINTAINERS. Which section do you suggest? It tests IDE CD-ROMs, SCSI CD-ROMs, and even virtio-block (on s390x) ... so I have a hard time to decide where this should belong to... Thomas
Re: [Qemu-devel] [PATCH v3 4/7] s390x/kvm: interface to interpret AP instructions
On 03/26/2018 04:38 AM, David Hildenbrand wrote:
On 16.03.2018 00:24, Tony Krowiak wrote:
The VFIO AP device exploits interpretive execution of AP
instructions (APIE). APIE is enabled by setting a device attribute
via the KVM_SET_DEVICE_ATTR ioctl.
Signed-off-by: Tony Krowiak
---
target/s390x/kvm.c | 16
target/s390x/kvm_s390x.h |2 ++
2 files changed, 18 insertions(+), 0 deletions(-)
diff --git a/target/s390x/kvm.c b/target/s390x/kvm.c
index 33e5ec3..2812e28 100644
--- a/target/s390x/kvm.c
+++ b/target/s390x/kvm.c
@@ -277,6 +277,22 @@ static void kvm_s390_init_dea_kw(void)
}
}
+int kvm_s390_set_interpret_ap(uint8_t enable)
+{
+struct kvm_device_attr attribute = {
+.group = KVM_S390_VM_CRYPTO,
+.attr = KVM_S390_VM_CRYPTO_INTERPRET_AP,
+.addr = 1,
+};
+
+if (!kvm_vm_check_attr(kvm_state, KVM_S390_VM_CRYPTO,
+ KVM_S390_VM_CRYPTO_INTERPRET_AP)) {
+return -EOPNOTSUPP;
+}
+
+return kvm_vm_ioctl(kvm_state, KVM_SET_DEVICE_ATTR, &attribute);
+}
+
void kvm_s390_crypto_reset(void)
{
if (s390_has_feat(S390_FEAT_MSA_EXT_3)) {
diff --git a/target/s390x/kvm_s390x.h b/target/s390x/kvm_s390x.h
index 34ee7e7..0d6c6e7 100644
--- a/target/s390x/kvm_s390x.h
+++ b/target/s390x/kvm_s390x.h
@@ -40,4 +40,6 @@ void kvm_s390_crypto_reset(void);
void kvm_s390_restart_interrupt(S390CPU *cpu);
void kvm_s390_stop_interrupt(S390CPU *cpu);
+int kvm_s390_set_interpret_ap(uint8_t enable);
+
#endif /* KVM_S390X_H */
Wonder if a capability - like we use e.g. for SIGP user space
interpretation - would be a better fit.
We can provide the AP feature to the guest in case:
- KVM_S390_VM_CPU_FEAT_AP ("interpretation support") is available
- KVM_S390_VM_CRYPTO_INTERPRET_AP ("interception support") is available
I don't think we need this. I have found a way to set ECA_APIE from the
vfio_ap device driver, so there is no need to do it from the guest. Stay
tuned to this station for v4 of the patch series.
I am missing the second check in your code. (for now you only rely on
KVM_S390_VM_CPU_FEAT_AP)
For what else are you suggesting we need to check?
I think you have to change the order of the patches so they work also
properly when bisectin.
I'll take a look at it.
Re: [Qemu-devel] [PULL 0/2] M68k for 2.12 patches
On 03/30/2018 12:00 PM, Laurent Vivier wrote: > Le 30/03/2018 à 18:54, Rob Landley a écrit : >> On 03/20/2018 04:08 AM, Laurent Vivier wrote:> This series of patches is >> needed >> to fix a problem >>> in the m68k translator that can crash QEMU when translation >>> cache has too many instructions: >>> >>> qemu-m68k: tcg/tcg.c:883: tcg_temp_alloc: Assertion `n < 512' failed. >>> qemu: uncaught target signal 11 (Segmentation fault) - core dumped >>> >>> I have reproduced it in linux user mode, with "ghc", and in >>> system mode with the debian-installer for unstable distro >>> from debian-ports. >> >> If someone wanted to follow along with your "boot linux on qemu-system-m68k" >> work on https://github.com/vivier/qemu-m68k, which of the 51 branches should >> qemu-system-m68k with like -M q800 or whatever you had working be built from? > > The branch to use is q800-dev There isn't any m68k support in musl-libc yet, so I grabbed my old https://github.com/landley/aboriginal project, did a "./build.sh m68k", built your q800-dev branch, added the m68k-softmmu from that to the start of the $PATH, and ran "more/dev-environment-from-build.sh m68k". It booted Linux to a shell prompt, I could wget a file from the internet, and /home had the 2 gigabyte ext3 mount from the virtual block device. I.E. it works for me. Why is it still out of tree? Rob
[Qemu-devel] [PULL 8/8] target/xtensa: linux-user: fix fadvise64 call
fadvise64_64 on xtensa passes advice as the second argument and so must be handled similar to PPC. This fixes glibc testsuite tests posix/tst-posix_fadvise and posix/tst-posix_fadvise64. Reviewed-by: Laurent Vivier Signed-off-by: Max Filippov --- linux-user/syscall.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/linux-user/syscall.c b/linux-user/syscall.c index 924fd68efcdd..5ef517613577 100644 --- a/linux-user/syscall.c +++ b/linux-user/syscall.c @@ -11509,7 +11509,7 @@ abi_long do_syscall(void *cpu_env, int num, abi_long arg1, #ifdef TARGET_NR_fadvise64_64 case TARGET_NR_fadvise64_64: -#if defined(TARGET_PPC) +#if defined(TARGET_PPC) || defined(TARGET_XTENSA) /* 6 args: fd, advice, offset (high, low), len (high, low) */ ret = arg2; arg2 = arg3; -- 2.11.0
[Qemu-devel] [PULL 4/8] linux-user: fix mq_getsetattr implementation
mq_getsetattr implementation does not set errno correctly in case of
error. Also in the presence of both 2nd and 3rd arguments it calls both
mq_getattr and mq_setattr, whereas only the latter call would suffice.
Don't call mq_getattr in the presence of the 2nd argument. Don't copy
output back to user in case of error. Use get_errno to set errno value.
This fixes test rt/tst-mqueue2 from the glibc testsuite.
Cc: Lionel Landwerlin
Cc: Kirill A. Shutemov
Cc: Riku Voipio
Cc: Aurelien Jarno
Cc: Laurent Vivier
Reviewed-by: Laurent Vivier
Signed-off-by: Max Filippov
---
linux-user/syscall.c | 13 +++--
1 file changed, 7 insertions(+), 6 deletions(-)
diff --git a/linux-user/syscall.c b/linux-user/syscall.c
index 18ea79140f16..d51e2a00ee31 100644
--- a/linux-user/syscall.c
+++ b/linux-user/syscall.c
@@ -12092,15 +12092,16 @@ abi_long do_syscall(void *cpu_env, int num, abi_long
arg1,
{
struct mq_attr posix_mq_attr_in, posix_mq_attr_out;
ret = 0;
-if (arg3 != 0) {
-ret = mq_getattr(arg1, &posix_mq_attr_out);
-copy_to_user_mq_attr(arg3, &posix_mq_attr_out);
-}
if (arg2 != 0) {
copy_from_user_mq_attr(&posix_mq_attr_in, arg2);
-ret |= mq_setattr(arg1, &posix_mq_attr_in, &posix_mq_attr_out);
+ret = get_errno(mq_setattr(arg1, &posix_mq_attr_in,
+ &posix_mq_attr_out));
+} else if (arg3 != 0) {
+ret = get_errno(mq_getattr(arg1, &posix_mq_attr_out));
+}
+if (ret == 0 && arg3 != 0) {
+copy_to_user_mq_attr(arg3, &posix_mq_attr_out);
}
-
}
break;
#endif
--
2.11.0
[Qemu-devel] [PULL 7/8] linux-user: implement clock_settime
This fixes glibc testsuite test rt/tst-clock2.
Signed-off-by: Max Filippov
---
linux-user/syscall.c | 12
1 file changed, 12 insertions(+)
diff --git a/linux-user/syscall.c b/linux-user/syscall.c
index 52e2f9c16479..924fd68efcdd 100644
--- a/linux-user/syscall.c
+++ b/linux-user/syscall.c
@@ -11878,6 +11878,18 @@ abi_long do_syscall(void *cpu_env, int num, abi_long
arg1,
goto unimplemented_nowarn;
#endif
+#ifdef TARGET_NR_clock_settime
+case TARGET_NR_clock_settime:
+{
+struct timespec ts;
+
+ret = target_to_host_timespec(&ts, arg2);
+if (!is_error(ret)) {
+ret = get_errno(clock_settime(arg1, &ts));
+}
+break;
+}
+#endif
#ifdef TARGET_NR_clock_gettime
case TARGET_NR_clock_gettime:
{
--
2.11.0
[Qemu-devel] [PULL 2/8] target/xtensa: linux-user: rewind pc for restarted syscall
In case of syscall restart request set pc back to the syscall instruction. Reviewed-by: Laurent Vivier Signed-off-by: Max Filippov --- linux-user/main.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/linux-user/main.c b/linux-user/main.c index ba09b7d0c873..8907a8411411 100644 --- a/linux-user/main.c +++ b/linux-user/main.c @@ -4006,6 +4006,9 @@ void cpu_loop(CPUXtensaState *env) break; case -TARGET_ERESTARTSYS: +env->pc -= 3; +break; + case -TARGET_QEMU_ESIGRETURN: break; } -- 2.11.0
[Qemu-devel] [PULL 5/8] target/xtensa: linux-user: fix sysv IPC structures
- make target_ipc_perm fields match kernel definitions for xtensa;
- add target_semid64_ds with proper order of times and reserved fields
for little/big endian specific for xtensa;
- add missing reserved fields after time fields to the target_shmid_ds;
- fix types of shm_cpid, shm_lpid and shm_nattch fields of
target_shmid_ds to match kernel definitions for xtensa.
These changes fix guest ipcs output and fix glibc testsuite tests
sysvipc/test-sysvsem and sysvipc/test-sysvshm.
Reviewed-by: Laurent Vivier
Signed-off-by: Max Filippov
---
linux-user/xtensa/target_structs.h | 37 ++---
1 file changed, 30 insertions(+), 7 deletions(-)
diff --git a/linux-user/xtensa/target_structs.h
b/linux-user/xtensa/target_structs.h
index 020e20e242fc..1b3d9ca314ff 100644
--- a/linux-user/xtensa/target_structs.h
+++ b/linux-user/xtensa/target_structs.h
@@ -8,21 +8,44 @@ struct target_ipc_perm {
abi_uint cuid; /* Creator's user ID. */
abi_uint cgid; /* Creator's group ID. */
abi_uint mode; /* Read/write permission. */
-abi_ushort __seq; /* Sequence number. */
+abi_ulong __seq;/* Sequence number. */
+abi_ulong __unused1;
+abi_ulong __unused2;
+};
+
+struct target_semid64_ds {
+ struct target_ipc_perm sem_perm;
+#ifdef TARGET_WORDS_BIGENDIAN
+ abi_ulong __unused1;
+ abi_ulong sem_otime;
+ abi_ulong __unused2;
+ abi_ulong sem_ctime;
+#else
+ abi_ulong sem_otime;
+ abi_ulong __unused1;
+ abi_ulong sem_ctime;
+ abi_ulong __unused2;
+#endif
+ abi_ulong sem_nsems;
+ abi_ulong __unused3;
+ abi_ulong __unused4;
};
+#define TARGET_SEMID64_DS
struct target_shmid_ds {
struct target_ipc_perm shm_perm;/* operation permission struct */
-abi_int shm_segsz; /* size of segment in bytes */
+abi_long shm_segsz; /* size of segment in bytes */
abi_long shm_atime; /* time of last shmat() */
+abi_ulong __unused1;
abi_long shm_dtime; /* time of last shmdt() */
-abi_long shm_ctime; /* time of last change by shmctl() */
-abi_ushort shm_cpid;/* pid of creator */
-abi_ushort shm_lpid;/* pid of last shmop */
-abi_ushort shm_nattch; /* number of current attaches */
-abi_ushort shm_unused; /* compatibility */
abi_ulong __unused2;
+abi_long shm_ctime; /* time of last change by shmctl() */
abi_ulong __unused3;
+abi_uint shm_cpid; /* pid of creator */
+abi_uint shm_lpid; /* pid of last shmop */
+abi_ulong shm_nattch; /* number of current attaches */
+abi_ulong __unused4;
+abi_ulong __unused5;
};
#endif
--
2.11.0
[Qemu-devel] [PULL 1/8] target/xtensa: fix flush_window_regs
flush_window_regs uses wrong stack frame to save overflow registers in
call8 and call12 frames, which results in wrong register values in
callers of a function that received a signal.
Reimplement flush_window_regs closely following window overflow
sequence.
Signed-off-by: Max Filippov
---
linux-user/signal.c | 55 +++--
1 file changed, 24 insertions(+), 31 deletions(-)
diff --git a/linux-user/signal.c b/linux-user/signal.c
index 2ea3e0321f4d..33d5ced30c98 100644
--- a/linux-user/signal.c
+++ b/linux-user/signal.c
@@ -7094,52 +7094,45 @@ static abi_ulong get_sigframe(struct target_sigaction
*sa,
static int flush_window_regs(CPUXtensaState *env)
{
-const uint32_t nareg_mask = env->config->nareg - 1;
uint32_t wb = env->sregs[WINDOW_BASE];
-uint32_t ws = (xtensa_replicate_windowstart(env) >> (wb + 1)) &
-((1 << env->config->nareg / 4) - 1);
-uint32_t d = ctz32(ws) + 1;
-uint32_t sp;
-abi_long ret = 0;
-
-wb += d;
-ws >>= d;
+uint32_t ws = xtensa_replicate_windowstart(env) >> (wb + 1);
+unsigned d = ctz32(ws) + 1;
+unsigned i;
+int ret = 0;
-xtensa_sync_phys_from_window(env);
-sp = env->phys_regs[(wb * 4 + 1) & nareg_mask];
+for (i = d; i < env->config->nareg / 4; i += d) {
+uint32_t ssp, osp;
+unsigned j;
-while (ws && ret == 0) {
-int d;
-int i;
-int idx;
+ws >>= d;
+xtensa_rotate_window(env, d);
if (ws & 0x1) {
-ws >>= 1;
+ssp = env->regs[5];
d = 1;
} else if (ws & 0x2) {
-ws >>= 2;
+ssp = env->regs[9];
+ret |= get_user_ual(osp, env->regs[1] - 12);
+osp -= 32;
d = 2;
-for (i = 0; i < 4; ++i) {
-idx = (wb * 4 + 4 + i) & nareg_mask;
-ret |= put_user_ual(env->phys_regs[idx], sp + (i - 12) * 4);
-}
} else if (ws & 0x4) {
-ws >>= 3;
+ssp = env->regs[13];
+ret |= get_user_ual(osp, env->regs[1] - 12);
+osp -= 48;
d = 3;
-for (i = 0; i < 8; ++i) {
-idx = (wb * 4 + 4 + i) & nareg_mask;
-ret |= put_user_ual(env->phys_regs[idx], sp + (i - 16) * 4);
-}
} else {
g_assert_not_reached();
}
-sp = env->phys_regs[((wb + d) * 4 + 1) & nareg_mask];
-for (i = 0; i < 4; ++i) {
-idx = (wb * 4 + i) & nareg_mask;
-ret |= put_user_ual(env->phys_regs[idx], sp + (i - 4) * 4);
+
+for (j = 0; j < 4; ++j) {
+ret |= put_user_ual(env->regs[j], ssp - 16 + j * 4);
+}
+for (j = 4; j < d * 4; ++j) {
+ret |= put_user_ual(env->regs[j], osp - 16 + j * 4);
}
-wb += d;
}
+xtensa_rotate_window(env, d);
+g_assert(env->sregs[WINDOW_BASE] == wb);
return ret == 0;
}
--
2.11.0
[Qemu-devel] [PULL 0/8] xtensa-specific and generic fixes for linux-user
Hi Peter, please pull the following batch of linux-user fixes for 2.12. The following changes since commit dfe732fb68ef9195517f4f380a477d58a054edc1: Merge remote-tracking branch 'remotes/jnsnow/tags/ide-pull-request' into staging (2018-03-27 16:25:12 +0100) are available in the git repository at: git://github.com/OSLL/qemu-xtensa.git tags/20180402-xtensa for you to fetch changes up to 64a563dd8dd6ca2661d96a2e4b69f0a5465cab94: target/xtensa: linux-user: fix fadvise64 call (2018-04-02 04:15:35 -0700) xtensa-specific fixes for linux-user: - fix flushing registers for signal processing in call8 and call12 frames; - fix PC value for restarted syscalls; - fix sysv IPC structures; - fix fadvise64 syscall; generic fixes for linux-user: - fix QEMU assertion in multithreaded application by calling cpu_copy under clone_lock; - fix mq_getsetattr implementation; - fix error propagation in clock_gettime; - implement clock_settime. Max Filippov (8): target/xtensa: fix flush_window_regs target/xtensa: linux-user: rewind pc for restarted syscall linux-user: call cpu_copy under clone_lock linux-user: fix mq_getsetattr implementation target/xtensa: linux-user: fix sysv IPC structures linux-user: fix error propagation in clock_gettime linux-user: implement clock_settime target/xtensa: linux-user: fix fadvise64 call linux-user/main.c | 3 +++ linux-user/signal.c| 55 +- linux-user/syscall.c | 36 + linux-user/xtensa/target_structs.h | 37 - 4 files changed, 82 insertions(+), 49 deletions(-) -- Thanks. -- Max
[Qemu-devel] [PULL 6/8] linux-user: fix error propagation in clock_gettime
host_to_target_timespec may return error if target address could not be
locked, but it is ignored.
Propagate return value of host_to_target_timespec to the caller of
clock_gettime.
Reviewed-by: Laurent Vivier
Signed-off-by: Max Filippov
---
linux-user/syscall.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/linux-user/syscall.c b/linux-user/syscall.c
index d51e2a00ee31..52e2f9c16479 100644
--- a/linux-user/syscall.c
+++ b/linux-user/syscall.c
@@ -11884,7 +11884,7 @@ abi_long do_syscall(void *cpu_env, int num, abi_long
arg1,
struct timespec ts;
ret = get_errno(clock_gettime(arg1, &ts));
if (!is_error(ret)) {
-host_to_target_timespec(arg2, &ts);
+ret = host_to_target_timespec(arg2, &ts);
}
break;
}
--
2.11.0
[Qemu-devel] [PULL 3/8] linux-user: call cpu_copy under clone_lock
cpu_copy adds newly created CPU object to container/machine/unattached, but does it w/o proper locking. As a result when multiple threads create threads rapidly QEMU may abort with the following message: GLib-CRITICAL **: g_hash_table_iter_next: assertion 'ri->version == ri->hash_table->version' failed ERROR:qemu/qom/object.c:1663:object_get_canonical_path_component: code should not be reached E.g. this issue is observed when running glibc test nptl/tst-eintr1. Move cpu_copy invocation under clone_lock to fix that. Reviewed-by: Laurent Vivier Signed-off-by: Max Filippov --- linux-user/syscall.c | 7 --- 1 file changed, 4 insertions(+), 3 deletions(-) diff --git a/linux-user/syscall.c b/linux-user/syscall.c index 889abbda1e65..18ea79140f16 100644 --- a/linux-user/syscall.c +++ b/linux-user/syscall.c @@ -6346,6 +6346,10 @@ static int do_fork(CPUArchState *env, unsigned int flags, abi_ulong newsp, ts = g_new0(TaskState, 1); init_task_state(ts); + +/* Grab a mutex so that thread setup appears atomic. */ +pthread_mutex_lock(&clone_lock); + /* we create a new CPU instance. */ new_env = cpu_copy(env); /* Init regs that differ from the parent. */ @@ -6364,9 +6368,6 @@ static int do_fork(CPUArchState *env, unsigned int flags, abi_ulong newsp, cpu_set_tls (new_env, newtls); } -/* Grab a mutex so that thread setup appears atomic. */ -pthread_mutex_lock(&clone_lock); - memset(&info, 0, sizeof(info)); pthread_mutex_init(&info.mutex, NULL); pthread_mutex_lock(&info.mutex); -- 2.11.0
Re: [Qemu-devel] [PATCH v3 5/7] s390x/vfio: ap: Introduce VFIO AP device
On 03/27/2018 08:02 AM, Cornelia Huck wrote:
On Fri, 16 Mar 2018 14:22:52 +0100
Halil Pasic wrote:
On 03/16/2018 11:42 AM, Pierre Morel wrote:
On 16/03/2018 00:24, Tony Krowiak wrote:
Introduces a VFIO based AP device. The device is defined via
the QEMU command line by specifying:
-device vfio-ap,sysfsdev=
The mediated matrix device is created by the VFIO AP device
driver by writing a UUID to a sysfs attribute file (see
docs/vfio-ap.txt). The mediated matrix device will be named
after the UUID. Symbolic links to the $uuid are created in
many places, so the path to the mediated matrix device $uuid
can be specified in any of the following ways:
/sys/devices/vfio_ap/matrix/$uuid
/sys/devices/vfio_ap/matrix/mdev_supported_types/vfio_ap-passthrough/devices/$uuid
/sys/bus/mdev/devices/$uuid
/sys/bus/mdev/drivers/vfio_mdev/$uuid
When the vfio-ap device is realized, it acquires and opens the
VFIO iommu group to which the mediated matrix device is
bound. This causes a VFIO group notification event to be
signaled. The vfio_ap device driver's group notification
handler will get called at which time the device driver
will configure the the AP devices to which the guest will
be granted access.
Signed-off-by: Tony Krowiak
---
[..]
+static void vfio_ap_realize(DeviceState *dev, Error **errp)
+{
+VFIODevice *vbasedev;
+VFIOGroup *vfio_group;
+APDevice *apdev = DO_UPCAST(APDevice, parent_obj, dev);
+VFIOAPDevice *vapdev = DO_UPCAST(VFIOAPDevice, apdev, apdev);
+char *mdevid;
+Error *local_err = NULL;
+int ret;
+
+if (!s390_has_feat(S390_FEAT_AP)) {
+error_setg(&local_err, "AP support not enabled");
+goto out_err;
+}
+
+ret = kvm_s390_set_interpret_ap(1);
If we have several devices, this is called once per device.
I don't think having several of these in a single vm makes
any sense. Or does it? IMHO we should make sure there is at
most one device taking care of the crypto pass-through.
Yes, I think we should fence off adding a second device in the realize
function (probably by checking a global variable?)
I agree, will do.
Re: [Qemu-devel] [PATCH v3 7/7] s390: doc: detailed specifications for AP virtualization
On 03/16/2018 06:03 AM, Pierre Morel wrote: On 16/03/2018 00:25, Tony Krowiak wrote: This patch provides documentation describing the AP architecture and design concepts behind the virtualization of AP devices. It also includes an example of how to configure AP devices for exclusive use of KVM guests. Signed-off-by: Tony Krowiak --- docs/vfio-ap.txt | 624 ++ 1 files changed, 624 insertions(+), 0 deletions(-) create mode 100644 docs/vfio-ap.txt diff --git a/docs/vfio-ap.txt b/docs/vfio-ap.txt new file mode 100644 index 000..54e7523 --- /dev/null +++ b/docs/vfio-ap.txt @@ -0,0 +1,624 @@ +Adjunct Processor (AP) Device += + +Contents: += +* Introduction +* AP Architectural Overview +* Start Interpretive Execution (SIE) Instruction +* AP Matrix Configuration on Linux Host +* AP Matrix Configuration for a Linux Guest +* Starting a Linux Guest Configured with an AP Matrix +* Example: Configure AP Matrices for Two Linux Guests + +Introduction: + +The IBM Adjunct Processor (AP) Cryptographic Facility is comprised +of three AP instructions and from 1 to 256 PCIe cryptographic adapter cards. +These AP devices provide cryptographic functions to all CPUs assigned to a +linux system running in an IBM Z system LPAR. + +On s390x, AP adapter cards are exposed via the AP bus. This document +describes how those cards may be made available to KVM guests using the +VFIO mediated device framework. + +AP Architectural Overview: += +In order understand the terminology used in the rest of this document, let's +start with some definitions: + +* AP adapter + + An AP adapter is an IBM Z adapter card that can perform cryptographic + functions. There can be from 0 to 256 adapters assigned to an LPAR. Adapters + assigned to the LPAR in which a linux host is running will be available to + the linux host. Each adapter is identified by a number from 0 to 255. When + installed, an AP adapter is accessed by AP instructions executed by any CPU. + +* AP domain + + An adapter is partitioned into domains. Each domain can be thought of as + a set of hardware registers for processing AP instructions. An adapter can + hold up to 256 domains. Each domain is identified by a number from 0 to 255. + Domains can be further classified into two types: + +* Usage domains are domains that can be accessed directly to process AP + commands + +* Control domains are domains that are accessed indirectly by AP + commands sent to a usage domain to control or change the domain, for + example; to set a secure private key for the domain. + +* AP Queue + + An AP queue is the means by which an AP command-request message is sent to an + AP usage domain inside a specific AP. An AP queue is identified by a tuple + comprised of an AP adapter ID (APID) and an AP queue index (APQI). The + APQI corresponds to a given usage domain number within the adapter. This tuple + forms an AP Queue Number (APQN) uniquely identifying an AP queue. AP + instructions include a field containing the APQN to identify the AP queue to + which the AP command-request message is to be sent for processing. + +* AP Instructions: + + There are three AP instructions: + + * NQAP: to enqueue an AP command-request message to a queue + * DQAP: to dequeue an AP command-reply message from a queue + * PQAP: to administer the queues + +Start Interpretive Execution (SIE) Instruction +== +A KVM guest is started by executing the Start Interpretive Execution (SIE) +instruction. The SIE state description is a control block that contains the +state information for a KVM guest and is supplied as input to the SIE +instruction. The SIE state description contains a field that references +a Crypto Control Block (CRYCB). The CRYCB contains three fields to identify the +adapters, usage domains and control domains assigned to the KVM guest: + +* The AP Mask (APM) field is a bit mask that identifies the AP adapters assigned + to the KVM guest. Each bit in the mask, from most significant to least + significant bit, corresponds to an APID from 0-255. If a bit is set, the + corresponding adapter is valid for use by the KVM guest. + +* The AP Queue Mask (AQM) field is a bit mask identifying the AP queues assigned + to the KVM guest. Each bit in the mask, from most significant to least + significant bit, corresponds to an AP queue index (APQI) from 0-255. If a bit + is set, the corresponding queue is valid for use by the KVM guest. + +* The AP Domain Mask field is a bit mask that identifies the AP control domains + assigned to the KVM guest. The ADM bit mask controls which domains can be + changed by an AP command-request message sent to a usage domain from the + guest. Each bit in the mask, from least significant to most significant bit, + corresponds t
Re: [Qemu-devel] [PATCH v3 6/7] s390x/kvm: handle AP instruction interception
On 03/26/2018 08:01 AM, Halil Pasic wrote:
On 03/26/2018 11:03 AM, Pierre Morel wrote:
+int ap_device_handle_pqap(S390CPU *cpu)
+{
+CPUS390XState *env = &cpu->env;
+int fc = 4 & (env->regs[0] >> 24);
+
+/*
+ * The Query Configuration Information (QCI) function (fc == 4) does not
+ * set a response code in reg 1, so check for that along with the
+ * AP feature.
+ */
+if ((fc != 4) && s390_has_feat(S390_FEAT_AP)) {
+env->regs[1] = 0x1;
+
+return 0;
+}
This would imply an operation exception in case fc==4, which sounds very
wrong.
Yes, operation exception is a wrong response under the condition
(fc == 4) && s390_has_feat(S390_FEAT_AP).
See my response to Pierre:
Message ID: <0b957a5c-1a87-7952-292d-f65052bb6...@linux.vnet.ibm.com>
@David:
FYI Tony is likely to respond after Wednesday as he is on vacation right
now.
It depends but I think that the S390_FEAT_AP_QUERY_CONFIG_INFO must be tested
to know what to answer.
If the feature is there, QCI must be answered correctly.
there are also some error situations to handle in all three functions.
I agree.
Regards,
Halil
Re: [Qemu-devel] [PATCH v3 6/7] s390x/kvm: handle AP instruction interception
On 03/26/2018 05:03 AM, Pierre Morel wrote:
On 26/03/2018 10:32, David Hildenbrand wrote:
On 16.03.2018 00:24, Tony Krowiak wrote:
If the CPU model indicates that AP facility is installed on
the guest (i.e., -cpu ,ap=on), then the expectation is that
the AP bus running in the guest will initialize; however, if the
AP instructions are not being interpreted by the firmware, then
they will be intercepted and routed back to QEMU for handling.
If a handler is not defined to process the intercepted instruciton,
t
...snip...
+int ap_device_handle_nqap(S390CPU *cpu)
+{
+CPUS390XState *env = &cpu->env;
+
+if (s390_has_feat(S390_FEAT_AP)) {
+env->regs[1] = 0x1;
+
+return 0;
+}
+
+return -EOPNOTSUPP;
+}
+
+int ap_device_handle_dqap(S390CPU *cpu)
+{
+CPUS390XState *env = &cpu->env;
+
+if (s390_has_feat(S390_FEAT_AP)) {
+env->regs[1] = 0x1;
+
+return 0;
+}
+
+return -EOPNOTSUPP;
+}
+
+int ap_device_handle_pqap(S390CPU *cpu)
+{
+CPUS390XState *env = &cpu->env;
+int fc = 4 & (env->regs[0] >> 24);
+
+/*
+ * The Query Configuration Information (QCI) function (fc == 4)
does not
+ * set a response code in reg 1, so check for that along with the
+ * AP feature.
+ */
+if ((fc != 4) && s390_has_feat(S390_FEAT_AP)) {
+env->regs[1] = 0x1;
+
+return 0;
+}
This would imply an operation exception in case fc==4, which sounds very
wrong.
It depends but I think that the S390_FEAT_AP_QUERY_CONFIG_INFO must be
tested
to know what to answer.
If the feature is there, QCI must be answered correctly.
This is an interesting proposition which raises several issues that will
need to
be addressed. The only time the PQAP(QCI) instruction is intercepted is
when:
* A vfio-ap device is NOT defined for the guest because the vfio_ap
device driver
will set ECA.28 and the PQAP(QCI) instruction will be interpreted
* STFLE.12 is set for the guest
You say that the QCI must be answered correctly, but what is the correct
response?
If we return the matrix - i.e., APM, ADM and AQM - configured via the
mediated
matrix device's sysfs attributes files, then if any APQNs are defined in
the matrix,
we will have to handle *ALL* AP instructions by executing them on behalf
of the
guest. I suppose we could return an empty matrix in which case the AP
bus will come
up without any devices on the guest, but what is the expectation of an
admin who
deliberately configures the mediated matrix device? Should we forego
handling interception
of AP instructions and consider a guest configuration that turns on
S390_FEAT_AP but
does not define a vfio-ap device to be erroneous and terminate starting
of the guest?
Anybody have any thoughts?
there are also some error situations to handle in all three functions.
To what error situations are you referring?
Hard to review without access to documentation. (hard to understand why
such stuff is to be kept confidential for decades)
+
+return -EOPNOTSUPP;
+}
+
static Property vfio_ap_properties[] = {
DEFINE_PROP_STRING("sysfsdev", VFIOAPDevice, vdev.sysfsdev),
DEFINE_PROP_END_OF_LIST(),
diff --git a/include/hw/s390x/ap-device.h
b/include/hw/s390x/ap-device.h
index 693df90..d45ae38 100644
--- a/include/hw/s390x/ap-device.h
+++ b/include/hw/s390x/ap-device.h
@@ -11,6 +11,8 @@
#ifndef HW_S390X_AP_DEVICE_H
#define HW_S390X_AP_DEVICE_H
Re: [Qemu-devel] [PULL 0/2] Ide patches
On 03/31/2018 03:08 AM, no-re...@patchew.org wrote: > Hi, > > This series failed docker-build@min-glib build test. Please find the testing > commands and > their output below. If you have Docker installed, you can probably reproduce > it > locally. > > Type: series > Message-id: 20180327045646.21112-1-js...@redhat.com > Subject: [Qemu-devel] [PULL 0/2] Ide patches > > === TEST SCRIPT BEGIN === > #!/bin/bash > set -e > git submodule update --init dtc > # Let docker tests dump environment info > export SHOW_ENV=1 > export J=8 > time make docker-test-build@min-glib > === TEST SCRIPT END === > > Updating 3c8cf5a9c21ff8782164d1def7f44bd888713384 > Switched to a new branch 'test' > 49a0f26939 Merge remote-tracking branch 'remotes/rth/tags/pull-tcg-20180328' > into staging > a60769352d tcg: Mark muluh_i64 and mulsh_i64 as 64-bit ops > > === OUTPUT BEGIN === > Submodule 'dtc' (git://git.qemu-project.org/dtc.git) registered for path 'dtc' > Cloning into '/var/tmp/patchew-tester-tmp-vi1_8690/src/dtc'... > Submodule path 'dtc': checked out 'e54388015af1fb4bf04d0bca99caba1074d9cc42' > BUILD min-glib > make[1]: Entering directory '/var/tmp/patchew-tester-tmp-vi1_8690/src' > GEN > /var/tmp/patchew-tester-tmp-vi1_8690/src/docker-src.2018-03-31-03.07.40.30023/qemu.tar > Cloning into > '/var/tmp/patchew-tester-tmp-vi1_8690/src/docker-src.2018-03-31-03.07.40.30023/qemu.tar.vroot'... > done. > Your branch is up-to-date with 'origin/test'. > Submodule 'dtc' (git://git.qemu-project.org/dtc.git) registered for path 'dtc' > Cloning into > '/var/tmp/patchew-tester-tmp-vi1_8690/src/docker-src.2018-03-31-03.07.40.30023/qemu.tar.vroot/dtc'... > Submodule path 'dtc': checked out 'e54388015af1fb4bf04d0bca99caba1074d9cc42' > Submodule 'ui/keycodemapdb' (git://git.qemu.org/keycodemapdb.git) registered > for path 'ui/keycodemapdb' > Cloning into > '/var/tmp/patchew-tester-tmp-vi1_8690/src/docker-src.2018-03-31-03.07.40.30023/qemu.tar.vroot/ui/keycodemapdb'... > Submodule path 'ui/keycodemapdb': checked out > '6b3d716e2b6472eb7189d3220552280ef3d832ce' > tar: > /var/tmp/patchew-tester-tmp-vi1_8690/src/docker-src.2018-03-31-03.07.40.30023/qemu.tar: > Wrote only 2048 of 10240 bytes > tar: Error is not recoverable: exiting now > failed to create tar file > COPYRUNNER > RUN test-build in qemu:min-glib > tar: Unexpected EOF in archive > tar: Unexpected EOF in archive > tar: Error is not recoverable: exiting now > /var/tmp/qemu/run: line 32: prep_fail: command not found > Environment variables: > HOSTNAME=d3de5b81f6a8 > MAKEFLAGS= -j8 > J=8 > CCACHE_DIR=/var/tmp/ccache > EXTRA_CONFIGURE_OPTS= > V= > SHOW_ENV=1 > PATH=/usr/lib/ccache:/usr/lib64/ccache:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin > PWD=/ > TARGET_LIST= > SHLVL=1 > HOME=/root > TEST_DIR=/tmp/qemu-test > FEATURES= dtc > DEBUG= > _=/usr/bin/env > > Configure options: > --enable-werror --target-list=x86_64-softmmu,aarch64-softmmu > --prefix=/tmp/qemu-test/install > > ERROR: DTC (libfdt) version >= 1.4.2 not present. >Please install the DTC (libfdt) devel package > Environment problems? > Traceback (most recent call last): > File "./tests/docker/docker.py", line 407, in > sys.exit(main()) > File "./tests/docker/docker.py", line 404, in main > return args.cmdobj.run(args, argv) > File "./tests/docker/docker.py", line 261, in run > return Docker().run(argv, args.keep, quiet=args.quiet) > File "./tests/docker/docker.py", line 229, in run > quiet=quiet) > File "./tests/docker/docker.py", line 147, in _do_check > return subprocess.check_call(self._command + cmd, **kwargs) > File "/usr/lib64/python2.7/subprocess.py", line 186, in check_call > raise CalledProcessError(retcode, cmd) > subprocess.CalledProcessError: Command '['docker', 'run', '--label', > 'com.qemu.instance.uuid=3f76e41234b211e8813a52540069c830', '-u', '0', > '--security-opt', 'seccomp=unconfined', '--rm', '--net=none', '-e', > 'TARGET_LIST=', '-e', 'EXTRA_CONFIGURE_OPTS=', '-e', 'V=', '-e', 'J=8', '-e', > 'DEBUG=', '-e', 'SHOW_ENV=1', '-e', 'CCACHE_DIR=/var/tmp/ccache', '-v', > '/root/.cache/qemu-docker-ccache:/var/tmp/ccache:z', '-v', > '/var/tmp/patchew-tester-tmp-vi1_8690/src/docker-src.2018-03-31-03.07.40.30023:/var/tmp/qemu:z,ro', > 'qemu:min-glib', '/var/tmp/qemu/run', 'test-build']' returned non-zero exit > status 1 > make[1]: *** [tests/docker/Makefile.include:129: docker-run] Error 1 > make[1]: Leaving directory '/var/tmp/patchew-tester-tmp-vi1_8690/src' > make: *** [tests/docker/Makefile.include:163: docker-run-test-build@min-glib] > Error 2 > > real 0m51.988s > user 0m9.352s > sys 0m6.949s > === OUTPUT END === > > Test command exited with code: 2 > > > --- > Email generated automatically by Patchew [http://patchew.org/]. > Please send your feedback to patchew-de...@redhat.com > Unrelated to the patch as far as I can tell. --js
Re: [Qemu-devel] [PATCH v3 6/7] s390x/kvm: handle AP instruction interception
On 03/26/2018 04:32 AM, David Hildenbrand wrote:
On 16.03.2018 00:24, Tony Krowiak wrote:
If the CPU model indicates that AP facility is installed on
the guest (i.e., -cpu ,ap=on), then the expectation is that
the AP bus running in the guest will initialize; however, if the
AP instructions are not being interpreted by the firmware, then
they will be intercepted and routed back to QEMU for handling.
If a handler is not defined to process the intercepted instruciton,
then an operation exception will be injected into the
guest, in which case the AP bus will not initialize.
There are two situations where AP instructions will not be
interpreted:
1. The guest is not configured with a vfio-ap device (i.e.,
-device vfio-ap,sysfsdev=$path-to-mdev). The realize function for
the vfio-ap device enables interpretive execution of AP
instructions.
2. The guest is a second level guest but the first level guest has
not enabled interpretive execution.
This patch introduces AP instruction handlers to ensure the AP bus
module initializes on the guest when the AP facility is installed
on the guest but AP instructions are not being interpreted. The logic
incorporated is:
* If the CPU model indicates AP instructions are
installed
* Set the status response code for the instruction to indicate that
the APQN contained in the instruction is not valid. This is
a valid response because there will be no devices configured for
the guest in any of the above scenarios.
* Else return an error from the handler. This will result in an
operation being injected into the guest and the AP bus will not
s/operation/operation exception/
thanks
initialize on the guest. That is commensurate with how things work
today.
Signed-off-by: Tony Krowiak
---
hw/vfio/ap.c | 45 ++
include/hw/s390x/ap-device.h |6 +
target/s390x/kvm.c | 14 +
3 files changed, 65 insertions(+), 0 deletions(-)
diff --git a/hw/vfio/ap.c b/hw/vfio/ap.c
index b397bb1..88e744d 100644
--- a/hw/vfio/ap.c
+++ b/hw/vfio/ap.c
@@ -148,6 +148,51 @@ static void vfio_ap_unrealize(DeviceState *dev, Error
**errp)
kvm_s390_set_interpret_ap(0);
}
I think you are missing cpu_synchronize_state(CPU(cpu)) in all of these
functions.
I see you negated this in your next response.
+int ap_device_handle_nqap(S390CPU *cpu)
+{
+CPUS390XState *env = &cpu->env;
+
+if (s390_has_feat(S390_FEAT_AP)) {
+env->regs[1] = 0x1;
+
+return 0;
+}
+
+return -EOPNOTSUPP;
+}
+
+int ap_device_handle_dqap(S390CPU *cpu)
+{
+CPUS390XState *env = &cpu->env;
+
+if (s390_has_feat(S390_FEAT_AP)) {
+env->regs[1] = 0x1;
+
+return 0;
+}
+
+return -EOPNOTSUPP;
+}
+
+int ap_device_handle_pqap(S390CPU *cpu)
+{
+CPUS390XState *env = &cpu->env;
+int fc = 4 & (env->regs[0] >> 24);
+
+/*
+ * The Query Configuration Information (QCI) function (fc == 4) does not
+ * set a response code in reg 1, so check for that along with the
+ * AP feature.
+ */
+if ((fc != 4) && s390_has_feat(S390_FEAT_AP)) {
+env->regs[1] = 0x1;
+
+return 0;
+}
This would imply an operation exception in case fc==4, which sounds very
wrong.
Take a look at my response to Pierre for an answer to this one.
Hard to review without access to documentation. (hard to understand why
such stuff is to be kept confidential for decades)
You'll have to talk to the powers that be at IBM about that one :)
+
+return -EOPNOTSUPP;
+}
+
static Property vfio_ap_properties[] = {
DEFINE_PROP_STRING("sysfsdev", VFIOAPDevice, vdev.sysfsdev),
DEFINE_PROP_END_OF_LIST(),
diff --git a/include/hw/s390x/ap-device.h b/include/hw/s390x/ap-device.h
index 693df90..d45ae38 100644
--- a/include/hw/s390x/ap-device.h
+++ b/include/hw/s390x/ap-device.h
@@ -11,6 +11,8 @@
#ifndef HW_S390X_AP_DEVICE_H
#define HW_S390X_AP_DEVICE_H
[Qemu-devel] [PATCH] roms/u-boot-sam460ex: Change to qemu git mirror and update
Now that we have a mirror of this repo on git.qemu.org change the submodule to use that and also update it to latest HEAD which has a commit to fix a dangling symlink. Signed-off-by: BALATON Zoltan --- .gitmodules | 2 +- roms/u-boot-sam460ex | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/.gitmodules b/.gitmodules index c613722..49e9c2e 100644 --- a/.gitmodules +++ b/.gitmodules @@ -45,4 +45,4 @@ url = git://github.com/hdeller/seabios-hppa.git [submodule "roms/u-boot-sam460ex"] path = roms/u-boot-sam460ex - url = git://github.com/zbalaton/u-boot-sam460ex + url = git://git.qemu.org/u-boot-sam460ex.git diff --git a/roms/u-boot-sam460ex b/roms/u-boot-sam460ex index 119aa27..930735b 16 --- a/roms/u-boot-sam460ex +++ b/roms/u-boot-sam460ex @@ -1 +1 @@ -Subproject commit 119aa277f74a4a2d3f7ab6c9471292308eba14e4 +Subproject commit 930735bdd6edbb0588d6a54882feb58ab3cb2d08 -- 2.7.6
Re: [Qemu-devel] some ROMs questions
On Mon, 2 Apr 2018, Michael Tokarev wrote: roms/u-boot-sam460ex/tools/updater/stubs.c - it is some strange symlink pointing to a strange place, probably should be removed? This does not seem to matter for building the rom image but this can be fixed by converting it to a relative path. I've done that and will send a patch to update the submodule as well to use the QEMU repo now that we have a mirror there. Thanks for finding this. When making u-boot-am460ex image, in roms/Makefile, we do a plain copy, while 5 lines above, u-boot image is being stripped on copy. Should we perform strip for u-boot-am460ex image too, if not only to be consistent? No, this is correct. These use different images. For e500 the u-boot ELF image is used after stripping it while for sam460ex the u-boot.bin is needed which is another build target and does not contain symbols to be stripped so a plain copy is enough. BTW, can't u-boot-am460ex image be made from regular u-boot sources, maybe with an additional board added? :) No. This was discussed before several times. Look up those threads for more info or if you don't beleive it just compare the two u-boot versions. I don't intend to take up the task of supporting this board in latest u-boot versions which even removed support for the CPU type it needs. Also we aim to be as compatible to real hardware as possible because of assumptions of closed source guests. Regards, BALATON Zoltan
[Qemu-devel] [PULL 1/3] nbd: Fix 32-bit compilation on BLOCK_STATUS
iotests 123 and 209 fail on 32-bit platforms. The culprit:
sizeof(extent) is wrong; we want sizeof(*extent). But since
the struct is 8 bytes, it happened to work on 64-bit platforms
where the pointer is also 8 bytes (nasty).
Fixes: 78a33ab58
Reported-by: Max Reitz
Signed-off-by: Eric Blake
Message-Id: <20180327210517.1804242-1-ebl...@redhat.com>
Reviewed-by: Paolo Bonzini
Reviewed-by: Vladimir Sementsov-Ogievskiy
---
block/nbd-client.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/block/nbd-client.c b/block/nbd-client.c
index e64e346d690..e7caf49fbb4 100644
--- a/block/nbd-client.c
+++ b/block/nbd-client.c
@@ -239,7 +239,7 @@ static int nbd_parse_blockstatus_payload(NBDClientSession
*client,
{
uint32_t context_id;
-if (chunk->length != sizeof(context_id) + sizeof(extent)) {
+if (chunk->length != sizeof(context_id) + sizeof(*extent)) {
error_setg(errp, "Protocol error: invalid payload for "
"NBD_REPLY_TYPE_BLOCK_STATUS");
return -EINVAL;
--
2.14.3
[Qemu-devel] [PULL 2/3] nbd/client: Correctly handle bad server REP_META_CONTEXT
It's never a good idea to blindly read for size bytes as
returned by the server without first validating that the size
is within bounds; a malicious or buggy server could cause us
to hang or get out of sync from reading further messages.
It may be smarter to try and teach the client to cope with
unexpected context ids by silently ignoring them instead of
hanging up on the server, but for now, if the server doesn't
reply with exactly the one context we expect, it's easier to
just give up - however, if we give up for any reason other
than an I/O failure, we might as well try to politely tell
the server we are quitting rather than continuing.
Fix some typos in the process.
Signed-off-by: Eric Blake
Message-Id: <20180329231837.1914680-1-ebl...@redhat.com>
Reviewed-by: Vladimir Sementsov-Ogievskiy
---
nbd/client.c | 28 +---
1 file changed, 21 insertions(+), 7 deletions(-)
diff --git a/nbd/client.c b/nbd/client.c
index 9b9b7f0ea29..dd0174b036e 100644
--- a/nbd/client.c
+++ b/nbd/client.c
@@ -599,8 +599,8 @@ static QIOChannel *nbd_receive_starttls(QIOChannel *ioc,
* Set one meta context. Simple means that reply must contain zero (not
* negotiated) or one (negotiated) contexts. More contexts would be considered
* as a protocol error. It's also implied that meta-data query equals queried
- * context name, so, if server replies with something different then @context,
- * it considered as error too.
+ * context name, so, if server replies with something different than @context,
+ * it is considered an error too.
* return 1 for successful negotiation, context_id is set
*0 if operation is unsupported,
*-1 with errp set for any other error
@@ -649,25 +649,33 @@ static int nbd_negotiate_simple_meta_context(QIOChannel
*ioc,
if (reply.type == NBD_REP_META_CONTEXT) {
char *name;
-size_t len;
+
+if (reply.length != sizeof(received_id) + context_len) {
+error_setg(errp, "Failed to negotiate meta context '%s', server "
+ "answered with unexpected length %" PRIu32, context,
+ reply.length);
+nbd_send_opt_abort(ioc);
+return -1;
+}
if (nbd_read(ioc, &received_id, sizeof(received_id), errp) < 0) {
return -1;
}
be32_to_cpus(&received_id);
-len = reply.length - sizeof(received_id);
-name = g_malloc(len + 1);
-if (nbd_read(ioc, name, len, errp) < 0) {
+reply.length -= sizeof(received_id);
+name = g_malloc(reply.length + 1);
+if (nbd_read(ioc, name, reply.length, errp) < 0) {
g_free(name);
return -1;
}
-name[len] = '\0';
+name[reply.length] = '\0';
if (strcmp(context, name)) {
error_setg(errp, "Failed to negotiate meta context '%s', server "
"answered with different context '%s'", context,
name);
g_free(name);
+nbd_send_opt_abort(ioc);
return -1;
}
g_free(name);
@@ -690,6 +698,12 @@ static int nbd_negotiate_simple_meta_context(QIOChannel
*ioc,
if (reply.type != NBD_REP_ACK) {
error_setg(errp, "Unexpected reply type %" PRIx32 " expected %x",
reply.type, NBD_REP_ACK);
+nbd_send_opt_abort(ioc);
+return -1;
+}
+if (reply.length) {
+error_setg(errp, "Unexpected length to ACK response");
+nbd_send_opt_abort(ioc);
return -1;
}
--
2.14.3
[Qemu-devel] [PULL 3/3] nbd: trace meta context negotiation
Having a more detailed log of the interaction between client and
server is invaluable in debugging how meta context negotiation
actually works.
Signed-off-by: Eric Blake
Message-Id: <20180330130950.1931229-1-ebl...@redhat.com>
Reviewed-by: Vladimir Sementsov-Ogievskiy
---
nbd/client.c | 2 ++
nbd/server.c | 8
nbd/trace-events | 6 ++
3 files changed, 16 insertions(+)
diff --git a/nbd/client.c b/nbd/client.c
index dd0174b036e..b9e175d1c27 100644
--- a/nbd/client.c
+++ b/nbd/client.c
@@ -623,6 +623,7 @@ static int nbd_negotiate_simple_meta_context(QIOChannel
*ioc,
char *data = g_malloc(data_len);
char *p = data;
+trace_nbd_opt_meta_request(context, export);
stl_be_p(p, export_len);
memcpy(p += sizeof(export_len), export, export_len);
stl_be_p(p += export_len, 1);
@@ -680,6 +681,7 @@ static int nbd_negotiate_simple_meta_context(QIOChannel
*ioc,
}
g_free(name);
+trace_nbd_opt_meta_reply(context, received_id);
received = true;
/* receive NBD_REP_ACK */
diff --git a/nbd/server.c b/nbd/server.c
index cea158913ba..9e1f2271784 100644
--- a/nbd/server.c
+++ b/nbd/server.c
@@ -726,6 +726,7 @@ static int nbd_negotiate_send_meta_context(NBDClient
*client,
context_id = 0;
}
+trace_nbd_negotiate_meta_query_reply(context, context_id);
set_be_option_rep(&opt.h, client->opt, NBD_REP_META_CONTEXT,
sizeof(opt) - sizeof(opt.h) + iov[1].iov_len);
stl_be_p(&opt.context_id, context_id);
@@ -752,10 +753,12 @@ static int nbd_meta_base_query(NBDClient *client,
NBDExportMetaContexts *meta,
if (client->opt == NBD_OPT_LIST_META_CONTEXT) {
meta->base_allocation = true;
}
+trace_nbd_negotiate_meta_query_parse("base:");
return 1;
}
if (len != alen) {
+trace_nbd_negotiate_meta_query_skip("not base:allocation");
return nbd_opt_skip(client, len, errp);
}
@@ -768,6 +771,7 @@ static int nbd_meta_base_query(NBDClient *client,
NBDExportMetaContexts *meta,
meta->base_allocation = true;
}
+trace_nbd_negotiate_meta_query_parse("base:allocation");
return 1;
}
@@ -800,6 +804,7 @@ static int nbd_negotiate_meta_query(NBDClient *client,
/* The only supported namespace for now is 'base'. So query should start
* with 'base:'. Otherwise, we can ignore it and skip the remainder. */
if (len < baselen) {
+trace_nbd_negotiate_meta_query_skip("length too short");
return nbd_opt_skip(client, len, errp);
}
@@ -809,6 +814,7 @@ static int nbd_negotiate_meta_query(NBDClient *client,
return ret;
}
if (strncmp(query, "base:", baselen) != 0) {
+trace_nbd_negotiate_meta_query_skip("not for base: namespace");
return nbd_opt_skip(client, len, errp);
}
@@ -858,6 +864,8 @@ static int nbd_negotiate_meta_queries(NBDClient *client,
return ret;
}
cpu_to_be32s(&nb_queries);
+trace_nbd_negotiate_meta_context(nbd_opt_lookup(client->opt),
+ meta->export_name, nb_queries);
if (client->opt == NBD_OPT_LIST_META_CONTEXT && !nb_queries) {
/* enable all known contexts */
diff --git a/nbd/trace-events b/nbd/trace-events
index 0d03edc967d..dee081e7758 100644
--- a/nbd/trace-events
+++ b/nbd/trace-events
@@ -10,6 +10,8 @@ nbd_receive_query_exports_start(const char *wantname)
"Querying export list for
nbd_receive_query_exports_success(const char *wantname) "Found desired export
name '%s'"
nbd_receive_starttls_new_client(void) "Setting up TLS"
nbd_receive_starttls_tls_handshake(void) "Starting TLS handshake"
+nbd_opt_meta_request(const char *context, const char *export) "Requesting to
set meta context %s for export %s"
+nbd_opt_meta_reply(const char *context, uint32_t id) "Received mapping of
context %s to id %" PRIu32
nbd_receive_negotiate(void *tlscreds, const char *hostname) "Receiving
negotiation tlscreds=%p hostname=%s"
nbd_receive_negotiate_magic(uint64_t magic) "Magic is 0x%" PRIx64
nbd_receive_negotiate_server_flags(uint32_t globalflags) "Global flags are
0x%" PRIx32
@@ -44,6 +46,10 @@ nbd_negotiate_handle_info_request(int request, const char
*name) "Client request
nbd_negotiate_handle_info_block_size(uint32_t minimum, uint32_t preferred,
uint32_t maximum) "advertising minimum 0x%" PRIx32 ", preferred 0x%" PRIx32 ",
maximum 0x%" PRIx32
nbd_negotiate_handle_starttls(void) "Setting up TLS"
nbd_negotiate_handle_starttls_handshake(void) "Starting TLS handshake"
+nbd_negotiate_meta_context(const char *optname, const char *export, uint32_t
queries) "Client requested %s for export %s, with %" PRIu32 " queries"
+nbd_negotiate_meta_query_skip(const char *reason) "Skipping meta query: %s"
+nbd_negotiate_meta_query_parse(const char *query) "Parsed meta query '%s'"
+nbd_negotiate_meta_query_reply(const char *context, uint32_t id) "Replying
with meta context '%s'
[Qemu-devel] [PULL 0/3] NBD patches for 2.12-rc2
The following changes since commit f184de7553272223d6af731d7d623a7cebf710b5: Merge remote-tracking branch 'remotes/riscv/tags/riscv-qemu-2.12-critical-fixes' into staging (2018-03-31 09:42:33 +0100) are available in the Git repository at: git://repo.or.cz/qemu/ericb.git tags/pull-nbd-2018-04-02 for you to fetch changes up to 2b53af2523f6a3387f71372f59d3717f1f7d5fd9: nbd: trace meta context negotiation (2018-04-02 09:10:49 -0500) nbd patches for 2018-04-02 - Eric Blake: nbd: Fix 32-bit compilation on BLOCK_STATUS - Eric Blake: nbd/client: Correctly handle bad server REP_META_CONTEXT - Eric Blake: nbd: trace meta context negotiation Eric Blake (3): nbd: Fix 32-bit compilation on BLOCK_STATUS nbd/client: Correctly handle bad server REP_META_CONTEXT nbd: trace meta context negotiation block/nbd-client.c | 2 +- nbd/client.c | 30 +++--- nbd/server.c | 8 nbd/trace-events | 6 ++ 4 files changed, 38 insertions(+), 8 deletions(-) -- 2.14.3
Re: [Qemu-devel] [qemu-web PATCH] download: Add instructions for MacPorts
> On Apr 2, 2018, at 10:07 AM, qemu-devel-requ...@nongnu.org wrote: > > Message: 2 > Date: Mon, 2 Apr 2018 04:22:52 +0200 > From: Paolo Bonzini > To: Rainer M?ller , qemu-devel@nongnu.org > Subject: Re: [Qemu-devel] [qemu-web PATCH] download: Add instructions > for MacPorts > Message-ID: <357029f4-71c0-a9f9-7bda-a5a44f609...@redhat.com> > Content-Type: text/plain; charset=utf-8 > > On 01/04/2018 18:22, Rainer M?ller wrote: >> Signed-off-by: Rainer M?ller >> --- >> _download/macos.md | 6 +- >> 1 file changed, 5 insertions(+), 1 deletion(-) >> >> diff --git a/_download/macos.md b/_download/macos.md >> index dbb312c..06aa811 100644 >> --- a/_download/macos.md >> +++ b/_download/macos.md >> @@ -1,6 +1,10 @@ >> -QEMU can be installed from Homebrew: >> +QEMU can be installed from Homebrew: >> >> brew install qemu >> >> +QEMU can be installed from MacPorts: >> + >> +sudo port install qemu >> + >> QEMU requires Mac OS X 10.5 or later, but it is recommended >> to use Mac OS X 10.7 or later. >> > > Thanks for the patch! I'm travelling but I will apply it as soon as I can. > > Paolo I was wondering if a link to the Mac OS X host wiki page could be added to this page. It does have prebuilt binaries ready for use. https://wiki.qemu.org/Hosts/Mac
Re: [Qemu-devel] [PATCH for-2.12] nbd: trace meta context negotiation
On 03/30/2018 11:32 AM, Vladimir Sementsov-Ogievskiy wrote:
> 30.03.2018 16:09, Eric Blake wrote:
>> Having a more detailed log of the interaction between client and
>> server is invaluable in debugging how meta context negotiation
>> actually works.
>>
>> Signed-off-by: Eric Blake
>> ---
>> nbd/client.c | 2 ++
>> nbd/server.c | 8
>> nbd/trace-events | 6 ++
>> 3 files changed, 16 insertions(+)
>>
>> @@ -800,6 +804,7 @@ static int nbd_negotiate_meta_query(NBDClient
>> *client,
>> /* The only supported namespace for now is 'base'. So query
>> should start
>> * with 'base:'. Otherwise, we can ignore it and skip the
>> remainder. */
>> if (len < baselen) {
>> + trace_nbd_negotiate_meta_query_skip("length too short");
>> return nbd_opt_skip(client, len, errp);
>> }
>>
>> @@ -809,6 +814,7 @@ static int nbd_negotiate_meta_query(NBDClient
>> *client,
>> return ret;
>> }
>> if (strncmp(query, "base:", baselen) != 0) {
>> + trace_nbd_negotiate_meta_query_skip("not for base: namespace");
>
> Hmm, reasonable example of using same trace-point in several places in
> the code. Is it a precedent?
Yes, trace points have been reused before; as long as the parameters are
the same and the message is reasonable, the only reason to NOT share a
trace is if you ever see yourself needing to select between the two
trace points individually. But for both of these points, it seems to me
that you'd either be tracing everything nbd_* or nothing, rather than
trying to catch just one of these points.
>> +++ b/nbd/trace-events
>> @@ -10,6 +10,8 @@ nbd_receive_query_exports_start(const char
>> *wantname) "Querying export list for
>> nbd_receive_query_exports_success(const char *wantname) "Found
>> desired export name '%s'"
>> nbd_receive_starttls_new_client(void) "Setting up TLS"
>> nbd_receive_starttls_tls_handshake(void) "Starting TLS handshake"
>> +nbd_opt_meta_request(const char *context, const char *export)
>> "Requesting to set meta context %s for export %s"
>> +nbd_opt_meta_reply(const char *context, int id) "Received mapping of
>> context %s to id %d"
>
> actual type is uint32_t, I'd prefer to reflect it here.
>
It doesn't make a difference on 'unsigned int' vs. 'uint32_t' in
trace-events. We guarantee that int is 32 bits on all platforms qemu
compiles on, and "%u" is a lot less typing than "%"PRIu32. But you are
right that id is unsigned, and printing a negative value for an id could
be confusing, so I'll at least tweak it for that.
>
> Must-have trace-points, anyway:
> Reviewed-by: Vladimir Sementsov-Ogievskiy
Thanks; I'll make those trace-events tweaks, and queue in my NBD tree
for a pull request today.
--
Eric Blake, Principal Software Engineer
Red Hat, Inc. +1-919-301-3266
Virtualization: qemu.org | libvirt.org
signature.asc
Description: OpenPGP digital signature
Re: [Qemu-devel] [PATCH for-2.12] nbd/client: Correctly handle bad server REP_META_CONTEXT
On 03/30/2018 11:59 AM, Vladimir Sementsov-Ogievskiy wrote:
> 30.03.2018 02:18, Eric Blake wrote:
>> It's never a good idea to blindly read for size bytes as
>> returned by the server without first validating that the size
>> is within bounds; a malicious or buggy server could cause us
>> to hang or get out of sync from reading further messages.
>>
>> It may be smarter to try and teach the client to cope with
>> unexpected context ids by silently ignoring them instead of
>> hanging up on the server, but for now, if the server doesn't
>> reply with exactly the one context we expect, it's easier to
>> just give up - however, if we give up for any reason other
>> than an I/O failure, we might as well try to politely tell
>> the server we are quitting rather than continuing.
>> @@ -651,6 +651,14 @@ static int
>> nbd_negotiate_simple_meta_context(QIOChannel *ioc,
>> char *name;
>> size_t len;
>>
>> + if (reply.length != sizeof(received_id) + context_len) {
>> + error_setg(errp, "Failed to negotiate meta context '%s',
>> server "
>> + "answered with unexpected length %u", context,
>
> uint32_t, is it worth PRIu32 ? Or %u is absolutely portable in this case?
For trace-events, casting uint32_t to unsigned int is always safe, at
which point using %u is less typing (because the trace goes through a
function prototype conversion). But when directly printing a uint32_t,
you are correct that some oddball 32-bit platforms might have uint32_t
be long, which would then trigger needless warnings if we don't use
PRIu32. So I'll fix that.
>
>> + reply.length);
>> + nbd_send_opt_abort(ioc);
>> + return -1;
>> + }
>
> hmm, after this check, len variable is not actually needed, we can use
> context_len
>
Okay, I'm squashing this in:
diff --git i/nbd/client.c w/nbd/client.c
index 4ee1d9a4a2c..dd0174b036e 100644
--- i/nbd/client.c
+++ w/nbd/client.c
@@ -649,11 +649,10 @@ static int
nbd_negotiate_simple_meta_context(QIOChannel *ioc,
if (reply.type == NBD_REP_META_CONTEXT) {
char *name;
-size_t len;
if (reply.length != sizeof(received_id) + context_len) {
error_setg(errp, "Failed to negotiate meta context '%s',
server "
- "answered with unexpected length %u", context,
+ "answered with unexpected length %" PRIu32, context,
reply.length);
nbd_send_opt_abort(ioc);
return -1;
@@ -664,13 +663,13 @@ static int
nbd_negotiate_simple_meta_context(QIOChannel *ioc,
}
be32_to_cpus(&received_id);
-len = reply.length - sizeof(received_id);
-name = g_malloc(len + 1);
-if (nbd_read(ioc, name, len, errp) < 0) {
+reply.length -= sizeof(received_id);
+name = g_malloc(reply.length + 1);
+if (nbd_read(ioc, name, reply.length, errp) < 0) {
g_free(name);
return -1;
}
-name[len] = '\0';
+name[reply.length] = '\0';
if (strcmp(context, name)) {
error_setg(errp, "Failed to negotiate meta context '%s',
server "
"answered with different context '%s'", context,
>> @@ -690,6 +699,12 @@ static int
>> nbd_negotiate_simple_meta_context(QIOChannel *ioc,
>> if (reply.type != NBD_REP_ACK) {
>> error_setg(errp, "Unexpected reply type %" PRIx32 " expected
>> %x",
>> reply.type, NBD_REP_ACK);
>> + nbd_send_opt_abort(ioc);
>> + return -1;
>> + }
>> + if (reply.length) {
>
> this check is very common for REP_ACK, it may be better to move it to
> nbd_handle_reply_err... (and rename this function? and combine it
> somehow with _option_request() and _option_reply()?)
>
>> + error_setg(errp, "Unexpected length to ACK response");
>> + nbd_send_opt_abort(ioc);
>
> hmm, looks like we want nbd_send_opt_abort() before most of return -1.
> Looks like it lacks some generalization, may be want to send it at some
> common point..
>
>> return -1;
>> }
>>
>
> mostly, just ideas for future refactoring, so:
Indeed, any refactoring we do in that area belongs in 2.13 patches.
> Reviewed-by: Vladimir Sementsov-Ogievskiy
Thanks; I'm including this in my NBD pull request today.
--
Eric Blake, Principal Software Engineer
Red Hat, Inc. +1-919-301-3266
Virtualization: qemu.org | libvirt.org
signature.asc
Description: OpenPGP digital signature
Re: [Qemu-devel] [PATCH v4 2/2] tpm: extend TPM TIS with state migration support
On 03/29/2018 01:07 PM, Marc-André Lureau wrote:
Hi
On Thu, Mar 29, 2018 at 1:56 AM, Stefan Berger
wrote:
On 03/28/2018 11:41 AM, Marc-André Lureau wrote:
Hi
On Thu, Mar 1, 2018 at 8:59 PM, Stefan Berger
wrote:
+
+static const VMStateDescription vmstate_locty = {
+.name = "loc",
+.version_id = 1,
+.minimum_version_id = 0,
+.minimum_version_id_old = 0,
I don't understand the problem there is leaving all the version fields
to 0, just like CRB.
+.fields = (VMStateField[]) {
+VMSTATE_UINT32(state, TPMLocality),
+VMSTATE_UINT32(inte, TPMLocality),
+VMSTATE_UINT32(ints, TPMLocality),
+VMSTATE_UINT8(access, TPMLocality),
+VMSTATE_UINT32(sts, TPMLocality),
+VMSTATE_UINT32(iface_id, TPMLocality),
+VMSTATE_END_OF_LIST(),
+}
+};
+
static const VMStateDescription vmstate_tpm_tis = {
.name = "tpm",
-.unmigratable = 1,
+.version_id = 1,
+.minimum_version_id = 0,
+.minimum_version_id_old = 0,
same
If you remove the version fields: Reviewed-by: Marc-André Lureau
This is the error I got when setting .version_id = 0 (on both) and doing a
localhost migration
qemu-system-x86_64: Missing section footer for tpm-tis
qemu-system-x86_64: load of migration failed: Invalid argument
It's clearly not the most friendly error message, but I debugged it,
you just have to specify the right version for VMSTATE_STRUCT_ARRAY:
0.
VMSTATE_STRUCT_ARRAY(loc, TPMState, TPM_TIS_NUM_LOCALITIES, 0,
vmstate_locty, TPMLocality),
Then it all works with version 0 (or default value)
thanks
Thanks.
[Qemu-devel] [Bug 1639983] Re: e1000 EEPROM have bad checksum
I'm also seeing this issue with version 2.11. Currently Intel's oldest available is 18.4 and this version reports an invalid checksum. The E1000.dos file when loaded doesn't recognize the emulated NIC. -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/1639983 Title: e1000 EEPROM have bad checksum Status in QEMU: New Bug description: I am using qemu-system-i386 to emulate FreeDOS with e1000 nic card. I am using Intel PRODOS v.19.0 (latest version with E1000ODI.COM file). E1000ODI.COM v.5.07 (140116) http://pclosmag.com/html/issues/201208/page11.html Suggest that v.4.75 (120212) was/is working. Oldest PRODOS available version seems now 18.5 (June 2013) which I have not tested yet. When running it, it detect: Slot 18, IRQ 11, Port C000. But complains: EEPROM checksum was incorrect. Contact your services network supplier for a replacement. paul@paul89473:~$ qemu-system-i386 --version QEMU emulator version 2.6.1 (Debian 1:2.6.1+dfsg-0ubuntu5), Copyright (c) 2003-2008 Fabrice Bellard paul@paul89473:~$ To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/1639983/+subscriptions
[Qemu-devel] [PATCH 1/2] linux-user: define TARGET_ARCH_HAS_KA_RESTORER
Sparc as an extended sigaction structure containing
the field ka_restorer used in place of sa_restorer.
Define TARGET_ARCH_HAS_KA_RESTORER and use it
with sparc.
Signed-off-by: Laurent Vivier
---
linux-user/signal.c | 4 ++--
linux-user/syscall.c | 7 +--
linux-user/syscall_defs.h | 4
3 files changed, 11 insertions(+), 4 deletions(-)
diff --git a/linux-user/signal.c b/linux-user/signal.c
index 2ea3e0321f..2b9752b40b 100644
--- a/linux-user/signal.c
+++ b/linux-user/signal.c
@@ -2920,8 +2920,8 @@ static void setup_frame(int sig, struct target_sigaction
*ka,
env->pc = ka->_sa_handler;
env->npc = (env->pc + 4);
/* 5. return to kernel instructions */
-if (ka->sa_restorer) {
-env->regwptr[UREG_I7] = ka->sa_restorer;
+if (ka->ka_restorer) {
+env->regwptr[UREG_I7] = ka->ka_restorer;
} else {
uint32_t val32;
diff --git a/linux-user/syscall.c b/linux-user/syscall.c
index 889abbda1e..b8353d8f13 100644
--- a/linux-user/syscall.c
+++ b/linux-user/syscall.c
@@ -8699,6 +8699,9 @@ abi_long do_syscall(void *cpu_env, int num, abi_long arg1,
target_siginitset(&act.sa_mask, old_act->sa_mask);
act.sa_flags = old_act->sa_flags;
act.sa_restorer = old_act->sa_restorer;
+#ifdef TARGET_ARCH_HAS_KA_RESTORER
+act.ka_restorer = 0;
+#endif
unlock_user_struct(old_act, arg2, 0);
pact = &act;
} else {
@@ -8773,8 +8776,8 @@ abi_long do_syscall(void *cpu_env, int num, abi_long arg1,
if (!lock_user_struct(VERIFY_READ, act, arg2, 1)) {
goto efault;
}
-#ifdef TARGET_SPARC
-act->sa_restorer = restorer;
+#ifdef TARGET_ARCH_HAS_KA_RESTORER
+act->ka_restorer = restorer;
#endif
} else {
act = NULL;
diff --git a/linux-user/syscall_defs.h b/linux-user/syscall_defs.h
index 13fe840239..7473be518b 100644
--- a/linux-user/syscall_defs.h
+++ b/linux-user/syscall_defs.h
@@ -435,6 +435,7 @@ int do_sigaction(int sig, const struct target_sigaction
*act,
#define TARGET_SA_NODEFER 0x20u
#define TARGET_SA_RESETHAND4u
#define TARGET_ARCH_HAS_SA_RESTORER 1
+#define TARGET_ARCH_HAS_KA_RESTORER 1
#elif defined(TARGET_MIPS)
#define TARGET_SA_NOCLDSTOP0x0001
#define TARGET_SA_NOCLDWAIT0x0001
@@ -742,6 +743,9 @@ struct target_sigaction {
abi_ulong sa_restorer;
#endif
target_sigset_t sa_mask;
+#ifdef TARGET_ARCH_HAS_KA_RESTORER
+abi_ulong ka_restorer;
+#endif
};
#endif
--
2.14.3
[Qemu-devel] [PATCH 2/2] linux-user: fix TARGET___O_TMPFILE for sparc
Signed-off-by: Laurent Vivier
---
linux-user/syscall_defs.h | 1 +
1 file changed, 1 insertion(+)
diff --git a/linux-user/syscall_defs.h b/linux-user/syscall_defs.h
index 7473be518b..23f5bccf0e 100644
--- a/linux-user/syscall_defs.h
+++ b/linux-user/syscall_defs.h
@@ -2565,6 +2565,7 @@ struct target_statfs64 {
#define TARGET_O_CLOEXEC 0x40
#define TARGET___O_SYNC 0x80
#define TARGET_O_PATH0x100
+#define TARGET___O_TMPFILE 0x200
#endif
/* values follow. */
--
2.14.3
[Qemu-devel] [PATCH 0/2] linux-user: fix sparc32plus emulation
The sparc signal emulation is broken: sparc has a special field called ka_restorer and to be used in place of sa_restorer. Without it, the signal handler exits and executes unexpected instructions. (sparc64 has the same kind of problem but this change doesn't fix it) Once this problem is fixed, we can chroot in a shell and execute "ls". And "ls" fails to read directory content because flags of open() are not translated correctly. To fix that, the second patch defines the good sparc value for TARGET___O_TMPFILE. Laurent Vivier (2): linux-user: define TARGET_ARCH_HAS_KA_RESTORER linux-user: fix TARGET___O_TMPFILE for sparc linux-user/signal.c | 4 ++-- linux-user/syscall.c | 7 +-- linux-user/syscall_defs.h | 5 + 3 files changed, 12 insertions(+), 4 deletions(-) -- 2.14.3
Re: [Qemu-devel] [PATCH] target/xtensa: linux-user: fix fadvise64 call
Le 02/04/2018 à 00:12, Max Filippov a écrit : > fadvise64_64 on xtensa passes advice as the second argument and so must > be handled similar to PPC. > > This fixes glibc testsuite tests posix/tst-posix_fadvise and > posix/tst-posix_fadvise64. > > Signed-off-by: Max Filippov > --- > linux-user/syscall.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/linux-user/syscall.c b/linux-user/syscall.c > index 924fd68efcdd..5ef517613577 100644 > --- a/linux-user/syscall.c > +++ b/linux-user/syscall.c > @@ -11509,7 +11509,7 @@ abi_long do_syscall(void *cpu_env, int num, abi_long > arg1, > > #ifdef TARGET_NR_fadvise64_64 > case TARGET_NR_fadvise64_64: > -#if defined(TARGET_PPC) > +#if defined(TARGET_PPC) || defined(TARGET_XTENSA) > /* 6 args: fd, advice, offset (high, low), len (high, low) */ > ret = arg2; > arg2 = arg3; > Reviewed-by: Laurent Vivier
Re: [Qemu-devel] [RFC 00/18] QEMU validator: A method to specify QEMU crash-test cases
On Mon, Apr 2, 2018 at 7:10 AM, Philippe Mathieu-Daudé wrote: > [/var]/tmp full due to some jobs not cleaning well their workspaces? Somehow our "make check" now keeps hanging in the container, preventing it from being cleaned up correctly... Will try to find time for it this week. Fam > > On 03/31/2018 06:04 AM, no-re...@patchew.org wrote: >> Hi, >> >> This series failed docker-build@min-glib build test. Please find the testing >> commands and >> their output below. If you have Docker installed, you can probably reproduce >> it >> locally. >> >> N/A. Internal error while reading log file >> >> >> >> --- >> Email generated automatically by Patchew [http://patchew.org/]. >> Please send your feedback to patchew-de...@redhat.com >>
Re: [Qemu-devel] qemu testing image link not work
On Mon, Apr 2, 2018 at 2:24 AM, Fam Zheng wrote: > On Mon, 04/02 01:52, Jidong Xiao wrote: >> Hi, >> >> A huge amount of documents has referenced this testing image: >> >> http://wiki.qemu.org/download/linux-0.2.img.bz2 >> >> However, the image is no longer there. Is the image still available >> somewhere? Thanks. > > According to the edit history of https://wiki.qemu.org/System_Images these > images are no longer provided by qemu.org. So we should fix the documents. > Where > are they? > > Fam When I was saying documents, I meant all kinds of online documents, whenever people talk about qemu test images, they refer to the above link. For example, that link was included in the native kvm tool readme file. Whatever, I just found one available mirror: http://lassauge.free.fr/qemu/release/ At least, we can download those testing images here. -Jidong
Re: [Qemu-devel] [RFC 00/18] QEMU validator: A method to specify QEMU crash-test cases
Hi, This series failed docker-quick@centos6 build test. Please find the testing commands and their output below. If you have Docker installed, you can probably reproduce it locally. Type: series Message-id: 20180329213857.15499-1-ehabk...@redhat.com Subject: [Qemu-devel] [RFC 00/18] QEMU validator: A method to specify QEMU crash-test cases === TEST SCRIPT BEGIN === #!/bin/bash set -e git submodule update --init dtc # Let docker tests dump environment info export SHOW_ENV=1 export J=8 time make docker-test-quick@centos6 === TEST SCRIPT END === Updating 3c8cf5a9c21ff8782164d1def7f44bd888713384 Switched to a new branch 'test' 0fdb1a2f05 Collection of validator.py test cases 962c7b9a45 validator.py script 11125125d8 qemu.py: is_launched() method e7b9360fc7 qemu.py: qmp_obj() method 04f1d03e56 qemu.py: Don't try to quit cleanly on exceptions b504207869 qemu.py: 'force' parameter on shutdown() 9cfedb7337 qemu.py: Only wait for process if it's still running 8c7e843d6e qemu.py: Log crashes inside _post_shutdown() 992c1b6bb2 qemu.py: Set _launched = False on _post_shutdown 9e4bcb4215 qemu.py: Make monitor optional 4d78dabfe2 qemu.py: Close _qmp inside _post_shutdown() 3937ce28e2 qemu.py: Use wait() logic inside shutdown() c2b5140e3d qemu.py: Move _load_io_log() call to _post_shutdown() a20254c9e0 qemu.py: Split _base_args() bb5e609a6b qemu.py: Make _vm_monitor a method a571feea0c qmp.py: Cleanly handle unexpectedly closed socket 9a92759c0c qmp.py: Fix error handling for Python 3 1f8f56095d qmp.py: Make it safe to call close() any time === OUTPUT BEGIN === Submodule 'dtc' (git://git.qemu-project.org/dtc.git) registered for path 'dtc' Cloning into '/var/tmp/patchew-tester-tmp-_gt5exqw/src/dtc'... Submodule path 'dtc': checked out 'e54388015af1fb4bf04d0bca99caba1074d9cc42' BUILD centos6 make[1]: Entering directory '/var/tmp/patchew-tester-tmp-_gt5exqw/src' GEN /var/tmp/patchew-tester-tmp-_gt5exqw/src/docker-src.2018-03-31-04.37.05.10200/qemu.tar Cloning into '/var/tmp/patchew-tester-tmp-_gt5exqw/src/docker-src.2018-03-31-04.37.05.10200/qemu.tar.vroot'... done. Checking out files: 44% (2693/6074) Checking out files: 45% (2734/6074) Checking out files: 46% (2795/6074) Checking out files: 47% (2855/6074) Checking out files: 47% (2882/6074) Checking out files: 48% (2916/6074) Checking out files: 49% (2977/6074) Checking out files: 50% (3037/6074) Checking out files: 51% (3098/6074) Checking out files: 52% (3159/6074) Checking out files: 53% (3220/6074) Checking out files: 54% (3280/6074) Checking out files: 55% (3341/6074) Checking out files: 56% (3402/6074) Checking out files: 57% (3463/6074) Checking out files: 58% (3523/6074) Checking out files: 59% (3584/6074) Checking out files: 60% (3645/6074) Checking out files: 61% (3706/6074) Checking out files: 62% (3766/6074) Checking out files: 63% (3827/6074) Checking out files: 64% (3888/6074) Checking out files: 65% (3949/6074) Checking out files: 66% (4009/6074) Checking out files: 67% (4070/6074) Checking out files: 68% (4131/6074) Checking out files: 69% (4192/6074) Checking out files: 70% (4252/6074) Checking out files: 71% (4313/6074) Checking out files: 72% (4374/6074) Checking out files: 73% (4435/6074) Checking out files: 74% (4495/6074) Checking out files: 75% (4556/6074) Checking out files: 76% (4617/6074) Checking out files: 77% (4677/6074) Checking out files: 78% (4738/6074) Checking out files: 79% (4799/6074) Checking out files: 80% (4860/6074) Checking out files: 81% (4920/6074) Checking out files: 82% (4981/6074) Checking out files: 83% (5042/6074) Checking out files: 84% (5103/6074) Checking out files: 85% (5163/6074) Checking out files: 86% (5224/6074) Checking out files: 86% (5278/6074) Checking out files: 87% (5285/6074) Checking out files: 88% (5346/6074) Checking out files: 89% (5406/6074) Checking out files: 90% (5467/6074) Checking out files: 91% (5528/6074) Checking out files: 92% (5589/6074) Checking out files: 93% (5649/6074) Checking out files: 94% (5710/6074) Checking out files: 95% (5771/6074) Checking out files: 96% (5832/6074) Checking out files: 97% (5892/6074) Checking out files: 98% (5953/6074) Checking out files: 99% (6014/6074) Checking out files: 100% (6074/6074) Checking out files: 100% (6074/6074), done. Your branch is up-to-date with 'origin/test'. Submodule 'dtc' (git://git.qemu-project.org/dtc.git) registered for path 'dtc' Cloning into '/var/tmp/patchew-tester-tmp-_gt5exqw/src/docker-src.2018-03-31-04.37.05.10200/qemu.tar.vroot/dtc'... Submodule path 'dtc': checked out 'e54388015af1fb4bf04d0bca99caba1074d9cc42' Submodule 'ui/keycodemapdb' (git://git.qemu.org/keycodemapdb.git) registered for path 'ui/keycodemapdb' Cloning into '/var/tmp/patchew-tester-tmp-_gt5exqw/src/docker-src.2
Re: [Qemu-devel] qemu testing image link not work
On Mon, 04/02 01:52, Jidong Xiao wrote: > Hi, > > A huge amount of documents has referenced this testing image: > > http://wiki.qemu.org/download/linux-0.2.img.bz2 > > However, the image is no longer there. Is the image still available > somewhere? Thanks. According to the edit history of https://wiki.qemu.org/System_Images these images are no longer provided by qemu.org. So we should fix the documents. Where are they? Fam
[Qemu-devel] qemu testing image link not work
Hi, A huge amount of documents has referenced this testing image: http://wiki.qemu.org/download/linux-0.2.img.bz2 However, the image is no longer there. Is the image still available somewhere? Thanks. -Jidong
