Re: [Qemu-devel] [PATCH for 2.13 1/2] Revert "spapr: Don't allow memory hotplug to memory less nodes"

Bharata B Rao wrote: > On Thu, Apr 05, 2018 at 10:35:22AM -0400, Serhii Popovych wrote: >> This reverts commit b556854bd8524c26b8be98ab1bfdf0826831e793. >> >> Leave change @node type from uint32_t to to int from reverted commit >> because node < 0 is always false. >> >> Signed-off-by: Serhii

[Qemu-devel] [PATCH] kvmclock: fix clock_is_reliable on migration from QEMU < 2.9

When migrating from a pre-2.9 QEMU, no clock_is_reliable flag is transferred. We should assume that the source host has an unreliable KVM_GET_CLOCK, rather than using whatever was determined locally, to ensure that any drift from the TSC-based value calculated by the guest is corrected.

Re: [Qemu-devel] [PATCH 17/19] uninorth: create new uninorth device

On 25/03/18 22:11, Mark Cave-Ayland wrote: Just to follow up on this, I spent a bit looking at what this register is trying to do and from the Darwin source I can see that in fact it is simply a hard-wired hardware register which should return the revision of the UniNorth hardware. So in

[Qemu-devel] [PATCH resend] kvmclock: fix clock_is_reliable on migration from QEMU < 2.9

When migrating from a pre-2.9 QEMU, no clock_is_reliable flag is transferred. We should assume that the source host has an unreliable KVM_GET_CLOCK, rather than using whatever was determined locally, to ensure that any drift from the TSC-based value calculated by the guest is corrected.

Re: [Qemu-devel] [RFC PATCH v2 4/4] memory: Add memory_region_set_priority()

On 5/4/18 6:44 pm, KONRAD Frederic wrote: > > > On 04/05/2018 03:22 AM, Philippe Mathieu-Daudé wrote: >> Signed-off-by: Philippe Mathieu-Daudé >> --- >> Sadly I'm missing something, this does not work. > > Hmmm is that supposed to work dynamically? > > If so I think you might

Re: [Qemu-devel] [PATCH for-2.13 09/13] target/ppc: Move 1T segment and AMR options to PPCHash64Options

On Thu, Apr 05, 2018 at 02:06:19PM +0200, Greg Kurz wrote: > On Thu, 5 Apr 2018 12:14:33 +1000 > David Gibson wrote: > > > Currently env->mmu_model is a bit of an unholy mess of an enum of distinct > > MMU types, with various flag bits as well. This makes which

Re: [Qemu-devel] [PATCH for 2.13 1/2] Revert "spapr: Don't allow memory hotplug to memory less nodes"

On Thu, Apr 05, 2018 at 10:35:22AM -0400, Serhii Popovych wrote: > This reverts commit b556854bd8524c26b8be98ab1bfdf0826831e793. > > Leave change @node type from uint32_t to to int from reverted commit > because node < 0 is always false. > > Signed-off-by: Serhii Popovych >

Re: [Qemu-devel] [PATCH v2 00/17] tcg: tb_lock_removal redux v2

Hi, This series seems to have some coding style problems. See output below for more information: Type: series Message-id: 1522980788-1252-1-git-send-email-c...@braap.org Subject: [Qemu-devel] [PATCH v2 00/17] tcg: tb_lock_removal redux v2 === TEST SCRIPT BEGIN === #!/bin/bash BASE=base n=1

Re: [Qemu-devel] [PATCH] tcg: Fix out-of-line generic vector compares

On Fri, Apr 06, 2018 at 11:00:15 +1000, Richard Henderson wrote: > A mistake in the type passed to sizeof, that happens to work > when the out-of-line fallback itself is using host vectors, > but fails when using only the base types. > > Reported-by: Emilio G. Cota >

[Qemu-devel] [PATCH v2 17/17] tcg: remove tb_lock

Use mmap_lock in user-mode to protect TCG state and the page descriptors. In !user-mode, each vCPU has its own TCG state, so no locks needed. Per-page locks are used to protect the page descriptors. Per-TB locks are used in both modes to protect TB jumps. Some notes: - tb_lock is removed from

[Qemu-devel] [PATCH v2 10/17] translate-all: use per-page locking in !user-mode

Groundwork for supporting parallel TCG generation. Instead of using a global lock (tb_lock) to protect changes to pages, use fine-grained, per-page locks in !user-mode. User-mode stays with mmap_lock. Sometimes changes need to happen atomically on more than one page (e.g. when a TB that spans

[Qemu-devel] [PATCH v2 13/17] translate-all: discard TB when tb_link_page returns an existing matching TB

Use the recently-gained QHT feature of returning the matching TB if it already exists. This allows us to get rid of the lookup we perform right after acquiring tb_lock. Suggested-by: Richard Henderson Signed-off-by: Emilio G. Cota ---

[Qemu-devel] [PATCH v2 01/17] qht: require a default comparison function

qht_lookup now uses the default cmp function. qht_lookup_custom is defined to retain the old behaviour, that is a cmp function is explicitly provided. qht_insert will gain use of the default cmp in the next patch. Note that we move qht_lookup_custom's @func to be the last argument, which makes

[Qemu-devel] [PATCH v2 11/17] translate-all: add page_locked assertions

This is only compiled under CONFIG_DEBUG_TCG to avoid bloating the binary. In user-mode, assert_page_locked is equivalent to assert_mmap_lock. Note: There are some tb_lock assertions left that will be removed by later patches. Suggested-by: Alex Bennée Signed-off-by:

[Qemu-devel] [PATCH v2 05/17] translate-all: iterate over TBs in a page with PAGE_FOR_EACH_TB

This commit does several things, but to avoid churn I merged them all into the same commit. To wit: - Use uintptr_t instead of TranslationBlock * for the list of TBs in a page. Just like we did in (c37e6d7e "tcg: Use uintptr_t type for jmp_list_{next|first} fields of TB"), the rationale is

[Qemu-devel] [PATCH v2 14/17] translate-all: protect TB jumps with a per-destination-TB lock

This applies to both user-mode and !user-mode emulation. Instead of relying on a global lock, protect the list of incoming jumps with tb->jmp_lock. This lock also protects tb->cflags, so update all tb->cflags readers outside tb->jmp_lock to use atomic reads via tb_cflags(). In order to find the

[Qemu-devel] [PATCH v2 15/17] cputlb: remove tb_lock from tlb_flush functions

The acquisition of tb_lock was added when the async tlb_flush was introduced in e3b9ca810 ("cputlb: introduce tlb_flush_* async work.") tb_lock was there to allow us to do memset() on the tb_jmp_cache's. However, since f3ced3c5928 ("tcg: consistently access cpu->tb_jmp_cache atomically") all

[Qemu-devel] [PATCH v2 03/17] tcg: track TBs with per-region BST's

This paves the way for enabling scalable parallel generation of TCG code. Instead of tracking TBs with a single binary search tree (BST), use a BST for each TCG region, protecting it with a lock. This is as scalable as it gets, since each TCG thread operates on a separate region. The core of

[Qemu-devel] [PATCH v2 12/17] translate-all: add page_collection assertions

The appended adds assertions to make sure we do not longjmp with page locks held. Some notes: - user-mode has nothing to check, since page_locks are !user-mode only. - The checks only apply to page collections, since these have relatively complex callers. - Some simple page_lock/unlock

[Qemu-devel] [PATCH v2 08/17] translate-all: work page-by-page in tb_invalidate_phys_range_1

So that we pass a same-page range to tb_invalidate_phys_page_range, instead of always passing an end address that could be on a different page. As discussed with Peter Maydell on the list [1], tb_invalidate_phys_page_range doesn't actually do much with 'end', which explains why we have never hit

[Qemu-devel] [PATCH v2 04/17] tcg: move tb_ctx.tb_phys_invalidate_count to tcg_ctx

Thereby making it per-TCGContext. Once we remove tb_lock, this will avoid an atomic increment every time a TB is invalidated. Reviewed-by: Richard Henderson Reviewed-by: Alex Bennée Signed-off-by: Emilio G. Cota ---

[Qemu-devel] [PATCH v2 02/17] qht: return existing entry when qht_insert fails

The meaning of "existing" is now changed to "matches in hash and ht->cmp result". This is saner than just checking the pointer value. Suggested-by: Richard Henderson Reviewed-by: Richard Henderson Signed-off-by: Emilio G. Cota

[Qemu-devel] [PATCH v2 16/17] translate-all: remove tb_lock mention from cpu_restore_state_from_tb

tb_lock was needed when the function did retranslation. However, since fca8a500d519 ("tcg: Save insn data and use it in cpu_restore_state_from_tb") we don't do retranslation. Get rid of the comment. Signed-off-by: Emilio G. Cota --- accel/tcg/translate-all.c | 4 +--- 1 file

[Qemu-devel] [PATCH v2 00/17] tcg: tb_lock_removal redux v2

v1: http://lists.gnu.org/archive/html/qemu-devel/2018-02/msg06499.html Changes since v1: - Add R-b's - Rebase onto master - qht_lookup_custom: move @func to be the last argument, which simplifies the new qht_lookup function. (I've kept R-b's tags here because this is a very simple change.)

[Qemu-devel] [PATCH v2 09/17] translate-all: move tb_invalidate_phys_page_range up in the file

This greatly simplifies next commit's diff. Reviewed-by: Richard Henderson Reviewed-by: Alex Bennée Signed-off-by: Emilio G. Cota --- accel/tcg/translate-all.c | 77 --- 1 file

[Qemu-devel] [PATCH v2 06/17] translate-all: make l1_map lockless

Groundwork for supporting parallel TCG generation. We never remove entries from the radix tree, so we can use cmpxchg to implement lockless insertions. Reviewed-by: Richard Henderson Reviewed-by: Alex Bennée Signed-off-by: Emilio G. Cota

[Qemu-devel] [PATCH v2 07/17] translate-all: remove hole in PageDesc

Groundwork for supporting parallel TCG generation. Move the hole to the end of the struct, so that a u32 field can be added there without bloating the struct. Reviewed-by: Richard Henderson Reviewed-by: Alex Bennée Signed-off-by: Emilio G.

Re: [Qemu-devel] [PATCH 15/16] translate-all: remove tb_lock mention from cpu_restore_state_from_tb

On Thu, Mar 29, 2018 at 17:06:56 +0100, Alex Bennée wrote: > > Emilio G. Cota writes: > > > tb_lock was needed when the function did retranslation. However, > > since fca8a500d519 ("tcg: Save insn data and use it in > > cpu_restore_state_from_tb") we don't do retranslation. > >

[Qemu-devel] [PATCH v4] linux-user: fix preadv/pwritev offsets

preadv/pwritev accept low and high parts of file offset in two separate parameters. When host bitness doesn't match guest bitness these parts must be appropriately recombined. Introduce target_to_host_low_high that does this recombination and use it in preadv/pwritev syscalls. This fixes glibc

Re: [Qemu-devel] [PATCH for-2.13 13/13] target/ppc: Fold slb_nr into PPCHash64Options

On Thu, Apr 05, 2018 at 03:27:34PM +0200, Cornelia Huck wrote: > On Thu, 5 Apr 2018 15:12:55 +0200 > Greg Kurz wrote: > > > On Thu, 5 Apr 2018 12:14:37 +1000 > > David Gibson wrote: > > > > @@ -4000,7 +4000,12 @@ DEFINE_SPAPR_MACHINE(2_13, "2.13",

Re: [Qemu-devel] [Qemu-arm] [PATCH v2 06/67] target/arm: Implement SVE predicate test

On 04/03/2018 07:16 PM, Alex Bennée wrote: >> +/* Set the cpu flags as per a return from an SVE helper. */ >> +static void do_pred_flags(TCGv_i32 t) >> +{ >> +tcg_gen_mov_i32(cpu_NF, t); >> +tcg_gen_andi_i32(cpu_ZF, t, 2); >> +tcg_gen_andi_i32(cpu_CF, t, 1); >> +

Re: [Qemu-devel] [PATCH 12/16] translate-all: discard TB when tb_link_page returns an existing matching TB

On Thu, Mar 29, 2018 at 16:19:39 +0100, Alex Bennée wrote: > > Emilio G. Cota writes: > > > Use the recently-gained QHT feature of returning the matching TB if it > > already exists. This allows us to get rid of the lookup we perform > > right after acquiring tb_lock. > > > >

Re: [Qemu-devel] [PATCH v2 05/67] target/arm: Implement SVE load vector/predicate

On 04/03/2018 07:26 PM, Alex Bennée wrote: > You don't use it yet but probably worth a: > > static inline int ffr_full_reg_offset(DisasContext *s) > { > return pred_full_reg_offset(s, 16); > } > > here when you get to it to avoid the magic 16 appearing in the main code. Hum. Most of the

Re: [Qemu-devel] [RfC PATCH] Add udmabuf misc device

On Thu, Apr 05, 2018 at 10:32:04PM +0200, Daniel Vetter wrote: > Pulling this out of the shadows again. > > We now also have xen-zcopy from Oleksandr and the hyper dmabuf stuff > from Matt and Dongwong. > > At least from the intel side there seems to be the idea to just have 1 > special device

Re: [Qemu-devel] [PATCH for-2.13 13/13] target/ppc: Fold slb_nr into PPCHash64Options

On Thu, Apr 05, 2018 at 03:12:55PM +0200, Greg Kurz wrote: > On Thu, 5 Apr 2018 12:14:37 +1000 > David Gibson wrote: > > > The env->slb_nr field gives the size of the SLB (Segment Lookaside Buffer). > > This is another static-after-initialization parameter of the

[Qemu-devel] [PATCH] tcg: Fix out-of-line generic vector compares

A mistake in the type passed to sizeof, that happens to work when the out-of-line fallback itself is using host vectors, but fails when using only the base types. Reported-by: Emilio G. Cota Signed-off-by: Richard Henderson ---

Re: [Qemu-devel] [PULL 16/20] target/arm: Use vector infrastructure for aa64 compares

On 04/05/2018 03:06 PM, Thomas Huth wrote: > On 05.04.2018 02:54, Richard Henderson wrote: >> On 04/05/2018 10:07 AM, Richard Henderson wrote: >>> On 04/05/2018 02:49 AM, Emilio G. Cota wrote: 1. grab this binary: http://cs.columbia.edu/~cota/qemu/nbench-aarch64 2. run it on a

Re: [Qemu-devel] [PATCH 10/16] translate-all: use per-page locking in !user-mode

On Thu, Mar 29, 2018 at 15:55:13 +0100, Alex Bennée wrote: > > Emilio G. Cota writes: (snip) > > +/* lock the page(s) of a TB in the correct acquisition order */ > > +static inline void page_lock_tb(const TranslationBlock *tb) > > +{ > > +if (likely(tb->page_addr[1] == -1)) {

Re: [Qemu-devel] [PATCH v4 0/2] hw/scsi: support SCSI-2 passthrough without PI

Hi, On 04/05/2018 01:23 PM, Paolo Bonzini wrote: This is my version of Daniel's patch. In order to keep the RD/WRPROTECT check for emulated SCSI disks, I've added a new property to scsi-disk/hd/cd devices as well. The property, similar to the earlier versions posted by Daniel, is available

[Qemu-devel] [PATCH for-2.12] sam460ex: Fix timer frequency and clock multipliers

We only emulate timer running at CPU frequency which is what most guests expect so set the frequency to match real hardware. This also allows setting clock multipliers which caused slowdown previously due to wrong timer frequency. Signed-off-by: BALATON Zoltan ---

Re: [Qemu-devel] [PATCH 1/2] scsi-disk: allow customizing the SCSI version

On 04/05/2018 01:23 PM, Paolo Bonzini wrote: We would like to have different behavior for passthrough devices depending on the SCSI version they expose. To prepare for that, allow the user of emulated devices to specify the desired SCSI level, and adjust the emulation according to the

[Qemu-devel] [Bug 1740219] Re: static linux-user ARM emulation has several-second startup time

I'm not on a Debian/Ubuntu-ish system, but extracting qemu-user-static_2.11+dfsg-1ubuntu6~ppa3_amd64.deb : data.tar.xz : usr/bin/qemu-arm-static and testing with that binary: $ time usr/bin/qemu-arm-static /var/lib/archbuild/dbscripts@armv7h/luke/usr/bin/ldconfig --help Usage:

Re: [Qemu-devel] [PULL 11/26] pci-bridge/i82801b11: clear bridge registers on platform reset

Quoting Laszlo Ersek (2018-03-23 13:42:07) > Michael, Peter, > > On 02/08/18 20:09, Michael S. Tsirkin wrote: > > From: Laszlo Ersek > > > > The "i82801b11-bridge" device model is a descendant of "base-pci-bridge" > > (TYPE_PCI_BRIDGE). However, unlike other similar devices,

Re: [Qemu-devel] -icount changes physical address assignments in QEMU 2.10/2.11

"Peter Maydell" wrote on 04/05/2018 12:28:01 PM: > From: "Peter Maydell" > To: alar...@ddci.com > Cc: "QEMU Developers" > Date: 04/05/2018 12:28 PM > Subject: Re: [Qemu-devel] -icount changes physical address

[Qemu-devel] [Bug 1441443] Re: Is there a way to create a 10G network interface for VMs in KVM2.0?

Unless you are using SRIOV or DPDK which both need hardware support. If could support SRIOV, then using IOMMU+VFIO, and pass-through to VM, this will get a close number. Or DPDK, using a user-space driver + vhost-net, will also get a pretty good value. -- You received this bug notification

Re: [Qemu-devel] [RfC PATCH] Add udmabuf misc device

Pulling this out of the shadows again. We now also have xen-zcopy from Oleksandr and the hyper dmabuf stuff from Matt and Dongwong. At least from the intel side there seems to be the idea to just have 1 special device that can handle cross-gues/host sharing for all kinds of hypervisors, so I

Re: [Qemu-devel] [PATCH] tcg: fix 16-byte vector operations detection

On 28/03/2018 15:31, Laurent Vivier wrote: > configure tries to detect if the compiler > supports 16-byte vector operations. > > As stated in the comment of the detection > program, there is a problem with the system > compiler on GCC on Centos 7. > > This program doesn't actually detect the

Re: [Qemu-devel] TCG icount interaction with timer deadlines

- Original Message - > From: "Peter Maydell" > To: "Paolo Bonzini" > Cc: "QEMU Developers" , "Alex Bennée" > , "Richard Henderson" > , "Emilio G. Cota" ,

Re: [Qemu-devel] [PATCH v2] vhost: Allow adjoining regions

On Thu, 5 Apr 2018 20:46:55 +0100 "Dr. David Alan Gilbert" wrote: > * Alex Williamson (alex.william...@redhat.com) wrote: > > On Fri, 23 Mar 2018 15:39:39 + > > "Dr. David Alan Gilbert (git)" wrote: > > > > > From: "Dr. David Alan Gilbert"

Re: [Qemu-devel] [PATCH v2] vhost: Allow adjoining regions

* Alex Williamson (alex.william...@redhat.com) wrote: > On Fri, 23 Mar 2018 15:39:39 + > "Dr. David Alan Gilbert (git)" wrote: > > > From: "Dr. David Alan Gilbert" > > > > My rework of section adding combines overlapping or adjoining regions, > >

[Qemu-devel] [PULL for-2.12 1/1] vfio: Use a trace point when a RAM section cannot be DMA mapped

From: Eric Auger Commit 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 page size and thus cannot be DMA mapped. This patch fixes the trace by printing the region name

[Qemu-devel] [PULL for-2.12 0/1] vfio fix

The following changes since commit 0e87fdc966d05f4e5ad868034fcd8ee2a08ca62d: Update version for v2.12.0-rc2 release (2018-04-04 20:37:20 +0100) are available in the Git repository at: git://github.com/awilliam/qemu-vfio.git tags/vfio-fixes-20180405.0 for you to fetch changes up to

Re: [Qemu-devel] [PATCH v2] vhost: Allow adjoining regions

On Fri, 23 Mar 2018 15:39:39 + "Dr. David Alan Gilbert (git)" wrote: > From: "Dr. David Alan Gilbert" > > My rework of section adding combines overlapping or adjoining regions, > but checks they're actually the same underlying RAM block. > Fix the

[Qemu-devel] [PATCH v2] e1000e: Prevent MSI/MSI-X storms

From: Jan Kiszka Only signal MSI/MSI-X events on rising edges. So far we re-triggered the interrupt sources even if the guest did no consumed the pending one, easily causing interrupt storms. Issue was observable with Linux 4.16 e1000e driver when MSI-X was used. Vector

Re: [Qemu-devel] TCG icount interaction with timer deadlines

On 5 April 2018 at 18:07, Paolo Bonzini wrote: > On 05/04/2018 18:01, Peter Maydell wrote: >> * however, if the guest reprograms the clock during the tcg_cpu_exec() >>run, we don't do anything to cause us to stop earlier > > Anything that does this from the vCPU thread

Re: [Qemu-devel] [Qemu-arm] [PATCH for-2.12] target/arm: Report unsupported MPU region sizes more clearly

On 04/05/2018 02:25 PM, Peter Maydell wrote: > Currently our PMSAv7 and ARMv7M MPU implementation cannot handle > MPU region sizes smaller than our TARGET_PAGE_SIZE. However we > report that in a slightly confusing way: > > DRSR[3]: No support for MPU (sub)region alignment of 9 bits. Minimum is

Re: [Qemu-devel] [PATCHv5] dma/i82374: avoid double creation of i82374 device

Hi Paolo, On 04/05/2018 02:02 PM, Paolo Bonzini wrote: > On 26/03/2018 17:05, Eduardo Otubo wrote: >> QEMU fails when used with the following command line: >> >> ./ppc64-softmmu/qemu-system-ppc64 -S -machine 40p,accel=tcg -device >> i82374 >> qemu-system-ppc64: hw/isa/isa-bus.c:110:

Re: [Qemu-devel] -icount changes physical address assignments in QEMU 2.10/2.11

On 5 April 2018 at 17:44, wrote: > "Peter Maydell" wrote on 04/05/2018 09:05:53 > AM: >> I've just tried your attached test image ... > > Curious. I just downloaded qemu-2.12.0-rc2.tar.xz and built it using > Cygwin (a version from about a month ago)

[Qemu-devel] [PATCH for-2.12] target/arm: Report unsupported MPU region sizes more clearly

Currently our PMSAv7 and ARMv7M MPU implementation cannot handle MPU region sizes smaller than our TARGET_PAGE_SIZE. However we report that in a slightly confusing way: DRSR[3]: No support for MPU (sub)region alignment of 9 bits. Minimum is 10 The problem is not the alignment of the region, but

Re: [Qemu-devel] [PATCH 04/16] tcg: move tb_ctx.tb_phys_invalidate_count to tcg_ctx

On Thu, Mar 29, 2018 at 11:06:07 +0100, Alex Bennée wrote: > Emilio G. Cota writes: (snip) > > diff --git a/accel/tcg/translate-all.c b/accel/tcg/translate-all.c > > index 3a51d49..20ad3fc 100644 > > --- a/accel/tcg/translate-all.c > > +++ b/accel/tcg/translate-all.c > > @@

Re: [Qemu-devel] [PATCH v3 6/7] s390x/kvm: handle AP instruction interception

On 04/05/2018 06:38 PM, Tony Krowiak wrote: >> Hard to really give good advice without access to the documentation, but: >> - If we tell the guest that the feature is available, but it does not >>    get any cards to use, returning an empty matrix makes the most sense >>    to me. >> - I would 

Re: [Qemu-devel] [PATCH 02/16] qht: return existing entry when qht_insert fails

On Wed, Mar 28, 2018 at 17:33:09 +0100, Alex Bennée wrote: > Emilio G. Cota writes: > > -bool qht_insert(struct qht *ht, void *p, uint32_t hash); > > +void *qht_insert(struct qht *ht, void *p, uint32_t hash); > > Hmm this seems needlessly counter intuitive. I realise the

Re: [Qemu-devel] TCG icount interaction with timer deadlines

On 05/04/2018 18:01, Peter Maydell wrote: > * however, if the guest reprograms the clock during the tcg_cpu_exec() >run, we don't do anything to cause us to stop earlier Anything that does this from the vCPU thread should be between gen_icount_start and gen_icount_end. (In fact, it's the

[Qemu-devel] [RFC][BROKEN] rbd: Allow configuration of authentication scheme

The legacy command line syntax supports a "password-secret" option that allows to pass an authentication key to Ceph. This was not supported in QMP so far. This patch introduces authentication options in the QAPI schema, makes them do the corresponding rados_conf_set() calls and adds

Re: [Qemu-devel] [PATCH v3 1/1] hw/scsi: support SCSI-2 passthrough without PI

On 05/04/2018 18:09, Daniel Henrique Barboza wrote: >>> >> This also has to check for "s->qdev.scsi_version != -1" so that the >> behavior of emulated SCSI isn't changed (they claim SPC-3).  I made this >> change and queued the patch. > > Good catch. Since there were some more changes for

Re: [Qemu-devel] [PATCHv5] dma/i82374: avoid double creation of i82374 device

On 26/03/2018 17:05, Eduardo Otubo wrote: > QEMU fails when used with the following command line: > > ./ppc64-softmmu/qemu-system-ppc64 -S -machine 40p,accel=tcg -device i82374 > qemu-system-ppc64: hw/isa/isa-bus.c:110: isa_bus_dma: Assertion > `!bus->dma[0] && !bus->dma[1]' failed. >

Re: [Qemu-devel] [PATCH 2/3] s390: Ensure IPL from SCSI works as expected

On 04/05/2018 11:07 AM, Viktor Mihajlovski wrote: Operating systems may request an IPL from a virtio-scsi device by specifying an IPL parameter type of CCW. In this case QEMU won't set up the IPLB correctly. The BIOS will still detect it's a SCSI device to boot from, but it will now have to

Re: [Qemu-devel] -icount changes physical address assignments in QEMU 2.10/2.11

"Peter Maydell" wrote on 04/05/2018 09:05:53 AM: > From: "Peter Maydell" > To: alar...@ddci.com > Cc: "QEMU Developers" > Date: 04/05/2018 09:06 AM > Subject: Re: [Qemu-devel] -icount changes physical address

Re: [Qemu-devel] [PATCH v3 6/7] s390x/kvm: handle AP instruction interception

On 04/03/2018 05:36 AM, Cornelia Huck wrote: On Mon, 2 Apr 2018 12:36:27 -0400 Tony Krowiak wrote: 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: +/* + * The Query

Re: [Qemu-devel] [PATCH v3] linux-user: fix preadv/pwritev offsets

Le 05/04/2018 à 18:27, Max Filippov a écrit : > On Thu, Apr 5, 2018 at 8:52 AM, Laurent Vivier wrote: >> Why don't you try to de-construct then re-construct the offset? > > It would require 128-bit arithmetic on 64-bit host. > >> Kernel commit >> 601cc11d054a "Make

Re: [Qemu-devel] [PATCH 1/3] s390: Refactor IPL parameter block generation

On 04/05/2018 11:07 AM, Viktor Mihajlovski wrote: Splitting out the the CCW device extraction allows reuse. Signed-off-by: Viktor Mihajlovski --- hw/s390x/ipl.c | 81 -- 1 file changed, 51 insertions(+),

[Qemu-devel] [Bug 1761535] [NEW] qemu-aarch64-static docker arm64v8/openjdk coredump

Public bug reported: I am using qemu-aarch64-static to run the arm64v8/openjdk official image on my x86 machine. Using QEMU master, I immediately hit a bug which hangs the container. With Ubuntu default version qemu-aarch64 version 2.5.0 (Debian 1:2.5+dfsg-5ubuntu10.24) and qemu-aarch64 version

Re: [Qemu-devel] [PATCH v3] linux-user: fix preadv/pwritev offsets

On Thu, Apr 5, 2018 at 8:52 AM, Laurent Vivier wrote: > Why don't you try to de-construct then re-construct the offset? It would require 128-bit arithmetic on 64-bit host. > Kernel commit > 601cc11d054a "Make non-compat preadv/pwritev use native register size" > is

Re: [Qemu-devel] [PATCH] hw/sparc64/sun4u: Fix introspection by converting prom instance_init to realize

On 04/05/2018 01:22 PM, Philippe Mathieu-Daudé wrote: > On 04/05/2018 06:32 AM, Thomas Huth wrote: >> The instance_init function of devices should always succeed to be able >> to introspect the device. However, the instance_init function of the >> "openprom" device can currently fail, for example

[Qemu-devel] [PATCH 2/2] hw/scsi: support SCSI-2 passthrough without PI

From: Daniel Henrique Barboza QEMU SCSI code makes assumptions about how the PROTECT and BYTCHK works in the protocol, denying support for PI (Protection Information) in case the guest OS requests it. However, in SCSI versions 2 and older, there is no PI concept in

[Qemu-devel] [PATCH 1/2] scsi-disk: allow customizing the SCSI version

We would like to have different behavior for passthrough devices depending on the SCSI version they expose. To prepare for that, allow the user of emulated devices to specify the desired SCSI level, and adjust the emulation according to the property value. The next patch will set the level for

[Qemu-devel] [PATCH v4 0/2] hw/scsi: support SCSI-2 passthrough without PI

This is my version of Daniel's patch. In order to keep the RD/WRPROTECT check for emulated SCSI disks, I've added a new property to scsi-disk/hd/cd devices as well. The property, similar to the earlier versions posted by Daniel, is available to the user, but for scsi-disk/hd/cd it affects the

Re: [Qemu-devel] [PATCH] hw/sparc64/sun4u: Fix introspection by converting prom instance_init to realize

On 04/05/2018 06:32 AM, Thomas Huth wrote: > The instance_init function of devices should always succeed to be able > to introspect the device. However, the instance_init function of the > "openprom" device can currently fail, for example like this: > > $ echo "{'execute':'qmp_capabilities'}"\ >

Re: [Qemu-devel] [PATCH v3 1/1] hw/scsi: support SCSI-2 passthrough without PI

On 04/05/2018 12:56 PM, Paolo Bonzini wrote: On 27/03/2018 23:14, Daniel Henrique Barboza wrote: /* We get here only for BYTCHK == 0x01 and only for scsi-block. * As far as DMA is concerned, we can treat it the same as a write; * scsi_block_do_sgio will send

[Qemu-devel] TCG icount interaction with timer deadlines

Does anybody understand how icount TCG is supposed to arrange to respect timer deadlines? https://bugs.launchpad.net/qemu/+bug/1754038 has a test case which shows that we don't get this right. At the moment what happens is: * when we're about to call tcg_cpu_exec(), we call

Re: [Qemu-devel] [PATCH v3 1/1] hw/scsi: support SCSI-2 passthrough without PI

On 27/03/2018 23:14, Daniel Henrique Barboza wrote: > /* We get here only for BYTCHK == 0x01 and only for scsi-block. > * As far as DMA is concerned, we can treat it the same as a write; > * scsi_block_do_sgio will send VERIFY commands. > + * > + * For

Re: [Qemu-devel] [PATCH v3] linux-user: fix preadv/pwritev offsets

Le 05/04/2018 à 15:47, Max Filippov a écrit : > preadv/pwritev accept low and high parts of file offset in two separate > parameters. When host bitness doesn't match guest bitness these parts > must be appropriately recombined. > Introduce target_to_host_low_high that does this recombination and

Re: [Qemu-devel] [PATCH v2] scsi-disk: Don't enlarge min_io_size to max_io_size

On 27/03/2018 18:41, Fam Zheng wrote: > Some backends report big max_io_sectors. Making min_io_size the same > value in this case will make it impossible for guest to align memory, > therefore the disk may not be usable at all. > > Do not enlarge them when they are zero. > > Reported-by: David

Re: [Qemu-devel] [PATCH] configure: Add missing configure options to help text

On 27/03/2018 17:09, Thomas Huth wrote: > We forgot to mention --with-git, --libexecdir and --with-pkgversion > so far. > > Signed-off-by: Thomas Huth > --- > configure | 3 +++ > 1 file changed, 3 insertions(+) > > diff --git a/configure b/configure > index 4d0e92c..a473609

Re: [Qemu-devel] [PATCH for-2.12 v3 0/2] i386/hyperv: fully control Hyper-V features in CPUID

On 30/03/2018 19:02, Roman Kagan wrote: > In order to guarantee compatibility on migration, QEMU should have > complete control over the features it announces to the guest via CPUID. > > However, a number of Hyper-V-related features happen to depend on the > support in the underlying KVM, with no

Re: [Qemu-devel] [PATCH] WHPX fixes an issue with CPUID 1 not returning CPUID_EXT_HYPERVISOR

On 28/03/2018 22:48, Justin Terry (VM) wrote: > 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

Re: [Qemu-devel] [PATCH for-2.12] memfd: fix vhost-user-test on non-memfd capable host

On 28/03/2018 14:18, Marc-André Lureau wrote: > On RHEL7, memfd is not supported, and vhost-user-test fails: > TEST: tests/vhost-user-test... (pid=10248) > /x86_64/vhost-user/migrate: > qemu-system-x86_64: -object memory-backend-memfd,id=mem,size=2M,: failed to > create memfd > FAIL > >

Re: [Qemu-devel] [PATCH 3/3] s390: Do not pass inofficial IPL type to the guest

On 05.04.2018 17:11, David Hildenbrand wrote: > On 05.04.2018 17:07, Viktor Mihajlovski wrote: >> IPL over a virtio-scsi device requires special handling not >> available in the real architecture. For this purpose the IPL >> type 0xFF has been chosen as means of communication between >> QEMU and

Re: [Qemu-devel] [PATCH 3/3] s390: Do not pass inofficial IPL type to the guest

On 05.04.2018 17:07, Viktor Mihajlovski wrote: > IPL over a virtio-scsi device requires special handling not > available in the real architecture. For this purpose the IPL > type 0xFF has been chosen as means of communication between > QEMU and the pc-bios. However, a guest OS could be confused >

[Qemu-devel] [PATCH 1/3] s390: Refactor IPL parameter block generation

Splitting out the the CCW device extraction allows reuse. Signed-off-by: Viktor Mihajlovski --- hw/s390x/ipl.c | 81 -- 1 file changed, 51 insertions(+), 30 deletions(-) diff --git a/hw/s390x/ipl.c

[Qemu-devel] [PATCH 3/3] s390: Do not pass inofficial IPL type to the guest

IPL over a virtio-scsi device requires special handling not available in the real architecture. For this purpose the IPL type 0xFF has been chosen as means of communication between QEMU and the pc-bios. However, a guest OS could be confused by seeing an unknown IPL type. This change sets the IPL

[Qemu-devel] [PATCH 2/3] s390: Ensure IPL from SCSI works as expected

Operating systems may request an IPL from a virtio-scsi device by specifying an IPL parameter type of CCW. In this case QEMU won't set up the IPLB correctly. The BIOS will still detect it's a SCSI device to boot from, but it will now have to search for the first LUN and attempt to boot from there.

[Qemu-devel] [PATCH 0/3] s390: Fix virtio-scsi IPL quirks

IPL from virtio-scsi currently uses a non-standard parameter type definition to pass boot parameters from QEMU to the BIOS. There are two potential issues with this approach: o If the guest operating systems requests a re-ipl of type CCW where the boot device is a virtio-scsi HBA, this goes

[Qemu-devel] [PATCH for 2.13 0/2] target/ppc: Support adding memory to initially memory-less NUMA nodes

Now PowerPC Linux kernel supports hot-add to NUMA nodes not populated initially with memory we can enable such support in qemu. This requires two changes: o Add device tree property "ibm,max-associativity-domains" to let guest kernel chance to find max possible NUMA node o Revert commit

[Qemu-devel] [PATCH for 2.13 2/2] spapr: Add ibm, max-associativity-domains property

Now recent kernels (i.e. since linux-stable commit a346137e9142 ("powerpc/numa: Use ibm,max-associativity-domains to discover possible nodes") support this property to mark initially memory-less NUMA nodes as "possible" to allow further memory hot-add to them. Advertise this property for pSeries

[Qemu-devel] [PATCH for 2.13 1/2] Revert "spapr: Don't allow memory hotplug to memory less nodes"

This reverts commit b556854bd8524c26b8be98ab1bfdf0826831e793. Leave change @node type from uint32_t to to int from reverted commit because node < 0 is always false. Signed-off-by: Serhii Popovych --- hw/ppc/spapr.c | 22 -- 1 file changed, 22

Re: [Qemu-devel] [PATCH for-2.13 0/2] net: Get rid of 'vlan' terminology and use 'hub' instead

On Wed, Apr 04, 2018 at 05:55:57PM +0200, Thomas Huth wrote: > On 04.04.2018 17:49, Paolo Bonzini wrote: > > On 04/04/2018 17:33, Thomas Huth wrote: > >> The 'vlan' term caused a lot of confusion in the past, so let's try > >> to switch to the better word "hub" everywhere where it is appropriate.

Re: [Qemu-devel] [Qemu-arm] [PATCH v2 2/2] arm_gicv3_kvm: kvm_dist_get/put: skip the registers banked by GICR

On 29 March 2018 at 11:54, Peter Maydell wrote: > On 23 March 2018 at 12:08, Peter Maydell wrote: >> On 21 March 2018 at 08:00, Shannon Zhao wrote: >>> On 2018/3/20 19:54, Peter Maydell wrote: Can you still

Re: [Qemu-devel] -icount changes physical address assignments in QEMU 2.10/2.11

On 22 March 2018 at 05:31, wrote: > Your patch (applied to 2.11 source release) changed the behavior > somewhat, but did not fix the problem. Attached is a binary that when > run should show a CGA fontset and color bars. > > This command should "work": > > qemu-system-aarch64

Re: [Qemu-devel] [Qemu-ppc] [PATCHv2 for-2.13 2/2] Add host_memory_backend_pagesize() helper

On Thu, 5 Apr 2018 12:20:02 +1000 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

  1   2   >