On 27.02.19 12:14, David Hildenbrand wrote:
> We want to make use of vectors, so use -march=z13. To make it compile,
> use a reasonable optimization level (-O2), which seems to work just fine
> with all tests.
>
> Add some infrastructure for checking if SIGILL will be properly
> triggered.
>
> Si
Patchew URL:
https://patchew.org/QEMU/20190222141024.22217-1-kbast...@mail.uni-paderborn.de/
Hi,
This series seems to have some coding style problems. See output below for
more information:
Message-id: 20190222141024.22217-1-kbast...@mail.uni-paderborn.de
Subject: [Qemu-devel] [PATCH v8 00/34
Patchew URL:
https://patchew.org/QEMU/20190222141024.22217-1-kbast...@mail.uni-paderborn.de/
Hi,
This series seems to have some coding style problems. See output below for
more information:
Message-id: 20190222141024.22217-1-kbast...@mail.uni-paderborn.de
Subject: [Qemu-devel] [PATCH v8 00/34
Patchew URL:
https://patchew.org/QEMU/20190222141024.22217-1-kbast...@mail.uni-paderborn.de/
Hi,
This series seems to have some coding style problems. See output below for
more information:
Message-id: 20190222141024.22217-1-kbast...@mail.uni-paderborn.de
Subject: [Qemu-devel] [PATCH v8 00/34
On 02/27/19 13:55, Shameerali Kolothum Thodi wrote:
> Hi Laszlo,
>
>> -Original Message-
>> From: Shameerali Kolothum Thodi
>> Sent: 25 February 2019 09:54
>> To: 'Laszlo Ersek' ; Auger Eric ;
>> shannon.zha...@gmail.com; peter.mayd...@linaro.org;
>> imamm...@redhat.com; qemu-devel@nongnu.
Patchew URL:
https://patchew.org/QEMU/20190222141024.22217-1-kbast...@mail.uni-paderborn.de/
Hi,
This series seems to have some coding style problems. See output below for
more information:
Message-id: 20190222141024.22217-1-kbast...@mail.uni-paderborn.de
Subject: [Qemu-devel] [PATCH v8 00/34
David Hildenbrand writes:
> On 27.02.19 12:14, David Hildenbrand wrote:
>> We want to make use of vectors, so use -march=z13. To make it compile,
>> use a reasonable optimization level (-O2), which seems to work just fine
>> with all tests.
>>
>> Add some infrastructure for checking if SIGILL w
On 27.02.19 21:19, Alex Bennée wrote:
>
> David Hildenbrand writes:
>
>> On 27.02.19 12:14, David Hildenbrand wrote:
>>> We want to make use of vectors, so use -march=z13. To make it compile,
>>> use a reasonable optimization level (-O2), which seems to work just fine
>>> with all tests.
>>>
>>>
Patchew URL:
https://patchew.org/QEMU/20190222141024.22217-1-kbast...@mail.uni-paderborn.de/
Hi,
This series seems to have some coding style problems. See output below for
more information:
Message-id: 20190222141024.22217-1-kbast...@mail.uni-paderborn.de
Subject: [Qemu-devel] [PATCH v8 00/34
"Dr. David Alan Gilbert" wrote:
> Hi Alex,
> Can you see if the attached patch fixes the ahci/migrate failure you
> see; it won't fail for me however mean I am to it.
Reviewed-by: Juan Quintela
It fixes the issue at point, and even if it is not a full solution (not
sure if it is or not), it
Patchew URL:
https://patchew.org/QEMU/20190222141024.22217-1-kbast...@mail.uni-paderborn.de/
Hi,
This series seems to have some coding style problems. See output below for
more information:
Message-id: 20190222141024.22217-1-kbast...@mail.uni-paderborn.de
Subject: [Qemu-devel] [PATCH v8 00/34
"Dr. David Alan Gilbert (git)" wrote:
> From: "Dr. David Alan Gilbert"
>
> Currently we cleanup the migration object as we exit main after the
> main_loop finishes; however if there's a migration running things
> get messy and we can end up with the migration thread still trying
> to access freed
Patchew URL:
https://patchew.org/QEMU/20190222141024.22217-1-kbast...@mail.uni-paderborn.de/
Hi,
This series seems to have some coding style problems. See output below for
more information:
Message-id: 20190222141024.22217-1-kbast...@mail.uni-paderborn.de
Subject: [Qemu-devel] [PATCH v8 00/34
Patchew URL:
https://patchew.org/QEMU/20190222141024.22217-1-kbast...@mail.uni-paderborn.de/
Hi,
This series seems to have some coding style problems. See output below for
more information:
Message-id: 20190222141024.22217-1-kbast...@mail.uni-paderborn.de
Subject: [Qemu-devel] [PATCH v8 00/34
Patchew URL:
https://patchew.org/QEMU/20190222141024.22217-1-kbast...@mail.uni-paderborn.de/
Hi,
This series seems to have some coding style problems. See output below for
more information:
Message-id: 20190222141024.22217-1-kbast...@mail.uni-paderborn.de
Subject: [Qemu-devel] [PATCH v8 00/34
Patchew URL:
https://patchew.org/QEMU/20190222141024.22217-1-kbast...@mail.uni-paderborn.de/
Hi,
This series seems to have some coding style problems. See output below for
more information:
Message-id: 20190222141024.22217-1-kbast...@mail.uni-paderborn.de
Subject: [Qemu-devel] [PATCH v8 00/34
Patchew URL:
https://patchew.org/QEMU/20190222141024.22217-1-kbast...@mail.uni-paderborn.de/
Hi,
This series seems to have some coding style problems. See output below for
more information:
Message-id: 20190222141024.22217-1-kbast...@mail.uni-paderborn.de
Subject: [Qemu-devel] [PATCH v8 00/34
Patchew URL:
https://patchew.org/QEMU/20190222141024.22217-1-kbast...@mail.uni-paderborn.de/
Hi,
This series seems to have some coding style problems. See output below for
more information:
Message-id: 20190222141024.22217-1-kbast...@mail.uni-paderborn.de
Subject: [Qemu-devel] [PATCH v8 00/34
Patchew URL:
https://patchew.org/QEMU/20190222141024.22217-1-kbast...@mail.uni-paderborn.de/
Hi,
This series seems to have some coding style problems. See output below for
more information:
Message-id: 20190222141024.22217-1-kbast...@mail.uni-paderborn.de
Subject: [Qemu-devel] [PATCH v8 00/34
Patchew URL:
https://patchew.org/QEMU/20190222141024.22217-1-kbast...@mail.uni-paderborn.de/
Hi,
This series seems to have some coding style problems. See output below for
more information:
Message-id: 20190222141024.22217-1-kbast...@mail.uni-paderborn.de
Subject: [Qemu-devel] [PATCH v8 00/34
Reuse the existing helpers.
Signed-off-by: David Hildenbrand
---
tests/tcg/s390x/Makefile.target | 1 +
tests/tcg/s390x/helper.h| 6 ++
tests/tcg/s390x/vlgv.c | 37 +
3 files changed, 44 insertions(+)
create mode 100644 tests/tcg/s390x/vlgv
As I currently work on vector instruction support for s390x/tcg, for now
I wrote my tests for kvm-unit-tests, but tests/tcg seems to be a better fit.
The only tricky part is testing interrupt handling, but that also seems to
be possible using some signal hackery.
This is only one test to discuss i
Patchew URL:
https://patchew.org/QEMU/20190222141024.22217-1-kbast...@mail.uni-paderborn.de/
Hi,
This series seems to have some coding style problems. See output below for
more information:
Message-id: 20190222141024.22217-1-kbast...@mail.uni-paderborn.de
Subject: [Qemu-devel] [PATCH v8 00/34
As want to make use of vectors in constraints of inline asm statements,
use -march=z13. To make it compile, use a reasonable optimization level
(-O2).
Add some infrastructure for checking if SIGILL will be properly triggered.
Take care of manually unblocking the signal before doing the longjmp,
ot
> On Feb 27, 2019, at 12:27 AM, Gerd Hoffmann wrote:
>
> On Tue, Feb 26, 2019 at 04:11:06PM -0500, G 3 wrote:
>> When I use edid=on, I do see a lot of extra resolutions available in Mac OS
>> 9 and Mac OS X, just not the resolution I want to use. Is there some kind
>> of rule like the resolutio
Patchew URL:
https://patchew.org/QEMU/20190222141024.22217-1-kbast...@mail.uni-paderborn.de/
Hi,
This series seems to have some coding style problems. See output below for
more information:
Message-id: 20190222141024.22217-1-kbast...@mail.uni-paderborn.de
Subject: [Qemu-devel] [PATCH v8 00/34
Patchew URL: https://patchew.org/QEMU/20190227211525.2470-1-da...@redhat.com/
Hi,
This series seems to have some coding style problems. See output below for
more information:
Message-id: 20190227211525.2470-1-da...@redhat.com
Subject: [Qemu-devel] [PATCH RFCv2 0/2] tests/tcg: Vector instructio
On Wed, Feb 27, 2019 at 06:27:49PM +0100, Igor Mammedov wrote:
>On Wed, 27 Feb 2019 13:59:20 +
>Wei Yang wrote:
>
>> On Wed, Feb 27, 2019 at 02:12:42PM +0100, Igor Mammedov wrote:
>> >On Mon, 25 Feb 2019 12:47:14 +
>> >Wei Yang wrote:
>> >
>> >> On Mon, Feb 25, 2019 at 09:05:37AM +0100,
Patchew URL:
https://patchew.org/QEMU/20190222141024.22217-1-kbast...@mail.uni-paderborn.de/
Hi,
This series seems to have some coding style problems. See output below for
more information:
Message-id: 20190222141024.22217-1-kbast...@mail.uni-paderborn.de
Subject: [Qemu-devel] [PATCH v8 00/34
Patchew URL:
https://patchew.org/QEMU/20190222141024.22217-1-kbast...@mail.uni-paderborn.de/
Hi,
This series seems to have some coding style problems. See output below for
more information:
Message-id: 20190222141024.22217-1-kbast...@mail.uni-paderborn.de
Subject: [Qemu-devel] [PATCH v8 00/34
Patchew URL:
https://patchew.org/QEMU/20190222141024.22217-1-kbast...@mail.uni-paderborn.de/
Hi,
This series seems to have some coding style problems. See output below for
more information:
Message-id: 20190222141024.22217-1-kbast...@mail.uni-paderborn.de
Subject: [Qemu-devel] [PATCH v8 00/34
David Hildenbrand writes:
> On 27.02.19 21:19, Alex Bennée wrote:
>>
>> David Hildenbrand writes:
>>
>>> On 27.02.19 12:14, David Hildenbrand wrote:
We want to make use of vectors, so use -march=z13. To make it compile,
use a reasonable optimization level (-O2), which seems to work j
Patchew URL:
https://patchew.org/QEMU/20190222141024.22217-1-kbast...@mail.uni-paderborn.de/
Hi,
This series seems to have some coding style problems. See output below for
more information:
Message-id: 20190222141024.22217-1-kbast...@mail.uni-paderborn.de
Subject: [Qemu-devel] [PATCH v8 00/34
Patchew URL:
https://patchew.org/QEMU/20190222141024.22217-1-kbast...@mail.uni-paderborn.de/
Hi,
This series seems to have some coding style problems. See output below for
more information:
Message-id: 20190222141024.22217-1-kbast...@mail.uni-paderborn.de
Subject: [Qemu-devel] [PATCH v8 00/34
Hi all,
I noticed nested SVM is enabled only in pc-i440fx-2.1 (default is
disabled); this was added when 2.1 was the latest:
75d373ef97 ("target-i386: Disable SVM by default in KVM mode")
However, this change was not carried forward to newer machine types. Is
this an oversight? Is th
On 2/26/19 1:16 PM, David Hildenbrand wrote:
>> +tmp = tcg_temp_new_i64();
>> +tcg_gen_movi_i64(tmp, mask);
>> +gen_gvec_dup_i64(es, get_field(s->fields, v1), tmp);
> Richard, shall I better convert this into
>
> switch (es) {
> case MO_8:
> tcg_gen_gvec_dup8i(..., 16, 16, mask)
On 2/26/19 3:38 AM, David Hildenbrand wrote:
> +static DisasJumpType op_vl(DisasContext *s, DisasOps *o)
> +{
> +load_vec_element(s, TMP_VREG_0, 0, o->addr1, MO_64);
> +gen_addi_and_wrap_i64(s, o->addr1, o->addr1, 8);
> +load_vec_element(s, TMP_VREG_0, 1, o->addr1, MO_64);
> +gen_gv
On 2/26/19 3:38 AM, David Hildenbrand wrote:
> Fairly easy, load with desired size and store it into the right element.
>
> Signed-off-by: David Hildenbrand
> ---
> target/s390x/insn-data.def | 5 +
> target/s390x/translate_vx.inc.c | 18 ++
> 2 files changed, 23 insert
On 2/26/19 3:38 AM, David Hildenbrand wrote:
> We can use tcg_gen_gvec_dup_i64() to carry out the duplication.
>
> Signed-off-by: David Hildenbrand
> ---
> target/s390x/insn-data.def | 2 ++
> target/s390x/translate_vx.inc.c | 17 +
> 2 files changed, 19 insertions(+)
Revi
On 2/26/19 3:38 AM, David Hildenbrand wrote:
> Also fairly easy to implement. One issue we have is that exceptions will
> result in some vectors already being modified. At least handle it
> consistently per vector by using a temporary vector. Good enough for
> now, add a FIXME.
>
> Signed-off-by:
On 2/26/19 3:38 AM, David Hildenbrand wrote:
> To avoid an helper, we have to do the actual calculation of the element
> address (offset in cpu_env + cpu_env) manually. Factor that out into
> get_vec_element_ptr_i64(). The same logic will be reused for "VECTOR
> LOAD VR ELEMENT FROM GR".
>
> Signe
On 2/26/19 3:38 AM, David Hildenbrand wrote:
> Take care of properly sign-extending the immediate.
>
> Signed-off-by: David Hildenbrand
> ---
> target/s390x/insn-data.def | 5 +
> target/s390x/translate_vx.inc.c | 17 +
> 2 files changed, 22 insertions(+)
Reviewed-by:
On 2/26/19 3:38 AM, David Hildenbrand wrote:
> +void HELPER(vll)(CPUS390XState *env, void *v1, uint64_t addr, uint64_t bytes)
> +{
> +S390Vector tmp = {};
> +int i;
> +
> +bytes = MIN(bytes, 16);
> +for (i = 0; i < bytes; i++) {
> +uint8_t byte = cpu_ldub_data_ra(env, addr,
On 2/26/19 3:39 AM, David Hildenbrand wrote:
> We cannot use gvec expansion as source and destination elements are
> have different element numbers. So we'll expand using a fancy loop.
> Also, we have to take care of overlapping source and target registers and
> use a temporary register in case the
On 2/26/19 3:38 AM, David Hildenbrand wrote:
> +zero_vec(TMP_VREG_0);
> +load_vec_element(s, TMP_VREG_0, enr, o->addr1, es);
> +gen_gvec_mov(get_field(s->fields, v1), TMP_VREG_0);
load into TCGv_i64, zero real dest, store into real dest.
r~
On 2/26/19 3:39 AM, David Hildenbrand wrote:
> +for (dst_idx = 0; dst_idx < NUM_VEC_ELEMENTS(es); dst_idx++) {
> +src_idx = dst_idx / 2;
> +if (!high) {
> +src_idx += NUM_VEC_ELEMENTS(es) / 2;
> +}
> +if (dst_idx % 2 == 0) {
> +read_vec_el
On 2/26/19 3:38 AM, David Hildenbrand wrote:
> Very similar to VECTOR LOAD GR FROM VR ELEMENT, just the opposite
> direction.
>
> Signed-off-by: David Hildenbrand
> ---
> target/s390x/insn-data.def | 2 ++
> target/s390x/translate_vx.inc.c | 33 +
> 2 files
On 2/26/19 3:38 AM, David Hildenbrand wrote:
> Fairly easy, just load from to gprs into a single vector.
>
> Signed-off-by: David Hildenbrand
> ---
> target/s390x/insn-data.def | 2 ++
> target/s390x/translate_vx.inc.c | 7 +++
> 2 files changed, 9 insertions(+)
Reviewed-by: Richard He
On 2/26/19 3:39 AM, David Hildenbrand wrote:
> We cannot use gvex expansion as the element size of source and
> destination differs. So expand manually. Luckily, VECTOR PACK does not
> care about saturation or setting the CC, so it can be implemented
> without a helper. We have to watch out for ove
On 2/26/19 3:39 AM, David Hildenbrand wrote:
> We can reuse the helper introduced along with VECTOR LOAD TO BLOCK
> BOUNDARY. We just have to take care of converting the highest index into
> a length.
>
> Signed-off-by: David Hildenbrand
> ---
> target/s390x/insn-data.def | 2 ++
> target/
On 2/27/19 4:02 AM, Bastian Koppelmann wrote:
> this adds one test that supposed to succeed to test deep nesting
> of pattern groups which is rarely exercised by targets using decode
> tree. The remaining tests exercise various fail conditions.
>
> Signed-off-by: Bastian Koppelmann
> ---
> These
On Wed, 2019-02-27 at 17:16 +1100, David Gibson wrote:
> On Wed, Feb 27, 2019 at 03:30:05PM +1100, Suraj Jitindar Singh wrote:
> > Add spapr_cap SPAPR_CAP_LARGE_DECREMENTER to be used to control the
> > availability of the large decrementer for a guest.
> >
> > Signed-off-by: Suraj Jitindar Singh
On 2/26/19 3:39 AM, David Hildenbrand wrote:
> We'll implement both via gvec ool helpers. As these can't return
> values, we'll return the CC via env->cc_op. Generate different C
> functions for the different cases using makros.
>
> In the future we might want to do a translation like VECTOR PACK
On 2/26/19 3:39 AM, David Hildenbrand wrote:
> Take care of overlying inputs and outputs by using a temporary vector.
>
> Signed-off-by: David Hildenbrand
> ---
> target/s390x/helper.h | 1 +
> target/s390x/insn-data.def | 2 ++
> target/s390x/translate_vx.inc.c | 12 +++
On 2/26/19 3:39 AM, David Hildenbrand wrote:
> We'll implement both via gvec ool helpers. As these can't return
> values, we'll return the CC via env->cc_op. Generate different C
> functions for the different cases using makros.
>
> In the future we might want to do a translation like VECTOR PACK
On 2/26/19 3:39 AM, David Hildenbrand wrote:
> Read the whole input before modifying the destination vector.
>
> Signed-off-by: David Hildenbrand
> ---
> target/s390x/insn-data.def | 2 ++
> target/s390x/translate_vx.inc.c | 16
> 2 files changed, 18 insertions(+)
Reviewe
On 2/26/19 3:39 AM, David Hildenbrand wrote:
> Load the element and replicate it using gvec_dup.
>
> Signed-off-by: David Hildenbrand
> ---
> target/s390x/insn-data.def | 2 ++
> target/s390x/translate_vx.inc.c | 18 ++
> 2 files changed, 20 insertions(+)
Reviewed-by: Rich
On 2/26/19 3:39 AM, David Hildenbrand wrote:
> Load the element and replicate it using gvec_dup.
>
> Signed-off-by: David Hildenbrand
> ---
> target/s390x/insn-data.def | 2 ++
> target/s390x/translate_vx.inc.c | 18 ++
> 2 files changed, 20 insertions(+)
Reviewed-by: Rich
On 2/26/19 3:39 AM, David Hildenbrand wrote:
> +tmp = tcg_temp_new_i64();
> +tcg_gen_movi_i64(tmp, data);
> +gen_gvec_dup_i64(es, get_field(s->fields, v1), tmp);
> +tcg_temp_free_i64(tmp);
> +return DISAS_NEXT;
Reuse the dupi8, dupi16, ... switch from one of the other patches u
On 2/26/19 3:39 AM, David Hildenbrand wrote:
> Similar to VECTOR GATHER ELEMENT, but the other direction.
>
> Signed-off-by: David Hildenbrand
> ---
> target/s390x/insn-data.def | 3 +++
> target/s390x/translate_vx.inc.c | 22 ++
> 2 files changed, 25 insertions(+)
Rev
On 2/26/19 3:39 AM, David Hildenbrand wrote:
> +tcg_gen_not_vec(vece, t, c);
> +tcg_gen_and_vec(vece, t, t, b);
tcg_gen_andc_vec(t, b, c);
> +tcg_gen_not_i64(t, c);
> +tcg_gen_and_i64(t, b, t);
Likewise.
r~
On 2/26/19 3:39 AM, David Hildenbrand wrote:
> Load both elements signed and store them into the two 64 bit elements.
>
> Signed-off-by: David Hildenbrand
> ---
> target/s390x/insn-data.def | 2 ++
> target/s390x/translate_vx.inc.c | 33 +
> 2 files changed,
On 2/26/19 3:39 AM, David Hildenbrand wrote:
> +static DisasJumpType op_vst(DisasContext *s, DisasOps *o)
> +{
> +/*
> + * FIXME: On exceptions we must not modify any memory.
> + */
> +store_vec_element(s, get_field(s->fields, v1), 0, o->addr1, MO_64);
> +gen_addi_and_wrap_i64(s
On 2/26/19 3:39 AM, David Hildenbrand wrote:
> As we only store one element, there is nothing to consider regarding
> exceptions.
>
> Signed-off-by: David Hildenbrand
> ---
> target/s390x/insn-data.def | 5 +
> target/s390x/translate_vx.inc.c | 18 ++
> 2 files changed,
On 2/26/19 3:39 AM, David Hildenbrand wrote:
> Similar to VECTOR LOAD MULTIPLE, just the opposite direction.
>
> Signed-off-by: David Hildenbrand
> ---
> target/s390x/insn-data.def | 2 ++
> target/s390x/translate_vx.inc.c | 25 +
> 2 files changed, 27 insertions(+)
On 2/25/19 11:21 AM, Vladimir Sementsov-Ogievskiy wrote:
> 23.02.2019 3:22, John Snow wrote:
>> Set the inconsistent bit on load instead of rejecting such bitmaps.
>> There is no way to un-set it; the only option is to delete it.
>>
>> Obvervations:
>> - bitmap loading does not need to update th
On 2/26/19 3:39 AM, David Hildenbrand wrote:
> Very similar to VECTOR LOAD WITH LENGTH, just the opposite direction.
>
> Signed-off-by: David Hildenbrand
> ---
> target/s390x/helper.h | 1 +
> target/s390x/insn-data.def | 2 ++
> target/s390x/translate_vx.inc.c | 13
On 28/02/2019 01:33, Greg Kurz wrote:
> On Wed, 27 Feb 2019 19:51:47 +1100
> Alexey Kardashevskiy wrote:
>
>> On sPAPR vfio_listener_region_add() is called in 2 situations:
>> 1. a new listener is registered from vfio_connect_container();
>> 2. a new IOMMU Memory Region is added from rtas_ibm_
> -Original Message-
> From: Kang, Luwei
> Sent: Wednesday, January 30, 2019 7:53 AM
> To: m...@redhat.com; marcel.apfelb...@gmail.com; pbonz...@redhat.com;
> r...@twiddle.net; ehabk...@redhat.com
> Cc: qemu-devel@nongnu.org; Kang, Luwei
> Subject: [PATCH V2] i386: extended the cpuid_l
On 2/27/19 11:37 AM, David Hildenbrand wrote:
> #define CHECK_SIGILL(STATEMENT) \
> do { \
> if (signal(SIGILL, sig_sigill) == SIG_ERR) { \
> check("SIGILL not registered", false); \
> }
On 2/26/19 3:39 AM, David Hildenbrand wrote:
> Combine all variant in a single handler. As source and destination
> have different element sizes, we can't use gvec expansion. Expand
> manually. Also watch out for overlapping source and destination and
> use a temporary register in that case.
>
> S
On 2/27/19 3:14 AM, David Hildenbrand wrote:
> Especially for inline asm with immediates;
>
> static inline void some_instr(uint8_t imm)
> {
> asm volatile("...", :: "i" (imm));
> }
>
> static void test()
> {
> some_instr(1);
> }
FWIW, __attribute__((always_inline)) should work even with
On 2/27/19 1:40 PM, Alex Bennée wrote:
> And crucially have nice regular sized instructions. Is that not an option?
s390 insns are {2,4,6} bytes. I don't think that there's an easy way to pick
out the hw status codes that would give the ilen of the faulting insn.
r~
On Wed, Feb 27, 2019 at 06:27:49PM +0100, Igor Mammedov wrote:
>On Wed, 27 Feb 2019 13:59:20 +
>Wei Yang wrote:
>
>> On Wed, Feb 27, 2019 at 02:12:42PM +0100, Igor Mammedov wrote:
>> >On Mon, 25 Feb 2019 12:47:14 +
>> >Wei Yang wrote:
>> >
>> >> >> To me, this is a general rule for PCDI
On 2/24/19 3:31 PM, David Gibson wrote:
> I have access to POWER8 and POWER9 machines, but I haven't worked with
> RISU before. If you can give me a straightforward recipe I can try
> running the tests.
From
https://git.linaro.org/people/peter.maydell/risu.git
First you need to generate the t
On Wed, Feb 27, 2019 at 12:04:49PM -0300, Murilo Opsfelder Araujo wrote:
> Hi, David.
>
> On Wed, Feb 27, 2019 at 10:19:20AM +1100, David Gibson wrote:
> > On Tue, Feb 26, 2019 at 04:11:40PM -0300, Murilo Opsfelder Araujo wrote:
> > > On Tue, Feb 26, 2019 at 02:08:30PM -0300, Murilo Opsfelder Arau
On Wed, Feb 27, 2019 at 08:51:11AM -0500, Michael S. Tsirkin wrote:
>On Wed, Feb 27, 2019 at 01:33:19PM +0800, Wei Yang wrote:
>> On Tue, Feb 26, 2019 at 11:10:06AM -0500, Michael S. Tsirkin wrote:
>> >On Tue, Feb 26, 2019 at 03:31:59PM +0800, Wei Yang wrote:
>> >> Leverage __ATTR_RO_MODE to define
On 2/27/19 9:40 AM, Mateja Marjanovic wrote:
> +void helper_msa_ilvev_df(CPUMIPSState *env, uint32_t df, uint32_t wd,
> + uint32_t ws, uint32_t wt)
> +{
> +wr_t *pwd = &(env->active_fpu.fpr[wd].wr);
> +wr_t *pws = &(env->active_fpu.fpr[ws].wr);
> +wr_t *pwt = &(e
On Wed, Feb 27, 2019 at 07:04:02PM +0100, Igor Mammedov wrote:
>On Mon, 25 Feb 2019 09:15:34 +0800
>Wei Yang wrote:
>
>> On Mon, Feb 25, 2019 at 09:07:08AM +0800, Wei Yang wrote:
>> >Currently we do device realization like below:
>> >
>> > hotplug_handler_pre_plug()
>> > dc->realize()
>> > h
On 2/26/19 10:31 AM, Peter Maydell wrote:
> On Wed, 20 Feb 2019 at 23:50, Richard Henderson
> wrote:
>>
>> Signed-off-by: Richard Henderson
>
>
>> @@ -9192,6 +9192,17 @@ static void disas_arm_insn(DisasContext *s, unsigned
>> int insn)
>> */
>> gen_goto_tb(s,
ping
From: no-re...@patchew.org
Sent: Thursday, January 31, 2019 9:53
To: mhi...@scalecomputing.com
Cc: f...@euphon.net; qemu-devel@nongnu.org; mhi...@scalecomputing.com;
mdr...@linux.vnet.ibm.com
Subject: Re: [Qemu-devel] [PATCH v3] QGA: Fix guest-get-fsinfo PCI
addresscollection in Windows
This is named "Execution and Data prediction restriction instructions"
within the ARMv8.5 manual, and given the name "PredRes" by binutils.
Signed-off-by: Richard Henderson
---
target/arm/cpu.h| 13 ++-
target/arm/cpu.c| 1 +
target/arm/cpu64.c | 2 ++
target/arm/helper.c | 55
Signed-off-by: Richard Henderson
---
target/arm/cpu.h | 10 ++
linux-user/elfload.c | 1 +
target/arm/cpu.c | 1 +
target/arm/cpu64.c | 2 ++
target/arm/translate-a64.c | 14 ++
target/arm/translate.c | 22 ++
6 file
Minimize the number of places that will need updating when
the virtual host extensions are added.
Signed-off-by: Richard Henderson
---
target/arm/cpu.h| 26 --
target/arm/helper.c | 8 ++--
2 files changed, 18 insertions(+), 16 deletions(-)
diff --git a/target/a
Changes since v2:
* Rebase on master, cherry-picking one required patch from
the ARMv8.5-MemTag patch set.
* Use the same form of TB exit for SB as for ISB.
* Rename all the bits related to PredInv.
* Fix registration for PredInv cache flush special regs,
and spell out why in a comm
On 2019/2/28 上午1:39, Nikhil Agarwal wrote:
Hi Stefan,
Thanks for directing question to correct people, yes your understanding is
correct.
I want virtio-net control virtqueue to be handled by vhost-user-net device
based backend for vdpa use case where control message would do some
configura
On Mon, Feb 25, 2019 at 05:39:06PM +1100, Alexey Kardashevskiy wrote:
>
>
> On 15/02/2019 16:21, David Gibson wrote:
> > On Fri, Feb 15, 2019 at 03:34:52PM +1100, Alexey Kardashevskiy wrote:
> >>
> >>
> >> On 15/02/2019 14:54, David Gibson wrote:
> >>> On Fri, Feb 15, 2019 at 02:32:14PM +1100, Al
On Wed, Feb 27, 2019 at 07:51:44PM +1100, Alexey Kardashevskiy wrote:
> sPAPR code will use it too so move it from VFIO to the common code.
>
> Signed-off-by: Alexey Kardashevskiy
> Reviewed-by: David Gibson
> Reviewed-by: Alistair Francis
Not technically my purview, but since it's to enable t
On Thu, Feb 28, 2019 at 10:59:56AM +1100, Alexey Kardashevskiy wrote:
>
>
> On 28/02/2019 01:33, Greg Kurz wrote:
> > On Wed, 27 Feb 2019 19:51:47 +1100
> > Alexey Kardashevskiy wrote:
> >
> >> On sPAPR vfio_listener_region_add() is called in 2 situations:
> >> 1. a new listener is registered f
On Wed, Feb 27, 2019 at 07:51:46PM +1100, Alexey Kardashevskiy wrote:
> The "systempagesize" name suggests that it is the host system page size
> while it is the smallest page size of memory backing the guest RAM so
> let's rename it to stop confusion. This should cause no behavioral change.
>
> S
On Thu, Feb 28, 2019 at 10:16:00AM +1100, Suraj Jitindar Singh wrote:
> On Wed, 2019-02-27 at 17:16 +1100, David Gibson wrote:
> > On Wed, Feb 27, 2019 at 03:30:05PM +1100, Suraj Jitindar Singh wrote:
> > > Add spapr_cap SPAPR_CAP_LARGE_DECREMENTER to be used to control the
> > > availability of th
On Wed, Feb 27, 2019 at 07:51:45PM +1100, Alexey Kardashevskiy wrote:
> The current code assumes that we can address more bits on a PCI bus
> for DMA than we really can but there is no way knowing the actual limit.
>
> This makes a better guess for the number of levels and if the kernel
> fails to
On Wed, Feb 27, 2019 at 07:51:49PM +1100, Alexey Kardashevskiy wrote:
> NVIDIA V100 GPUs have on-board RAM which is mapped into the host memory
> space and accessible as normal RAM via an NVLink bus. The VFIO-PCI driver
> implements special regions for such GPUs and emulates an NVLink bridge.
> NVL
On 2/27/2019 4:05 PM, Mark Kanda wrote:
Hi all,
I noticed nested SVM is enabled only in pc-i440fx-2.1 (default is
disabled); this was added when 2.1 was the latest:
75d373ef97 ("target-i386: Disable SVM by default in KVM mode")
However, this change was not carried forward to newer machi
On Wed, Feb 27, 2019 at 04:47:30PM -0800, Richard Henderson wrote:
> On 2/24/19 3:31 PM, David Gibson wrote:
> > I have access to POWER8 and POWER9 machines, but I haven't worked with
> > RISU before. If you can give me a straightforward recipe I can try
> > running the tests.
>
> From
>
> htt
The configure script checks multiple times whether it works in a git
repository and it does this by "test -e "${source_path}/.git" in 4 cases
but in one case where it tries to enable werror "-d" is used there which
fails on git worktrees as .git is a file then and not a directory.
This changes the
On Thu, Feb 28, 2019 at 03:35:03PM +1100, Alexey Kardashevskiy wrote:
> The configure script checks multiple times whether it works in a git
> repository and it does this by "test -e "${source_path}/.git" in 4 cases
> but in one case where it tries to enable werror "-d" is used there which
> fails
On 27/02/2019 05:27, Gerd Hoffmann wrote:
> On Tue, Feb 26, 2019 at 04:11:06PM -0500, G 3 wrote:
>> When I use edid=on, I do see a lot of extra resolutions available in Mac OS
>> 9 and Mac OS X, just not the resolution I want to use. Is there some kind
>> of rule like the resolution value has to b
On 26/02/2019 22:25, Andrew Randrianasulu wrote:
(adding qemu-ppc, Richard and David - please make sure you add the relevant
maintainer on bug reports, as otherwise due to the high volume of mails to the
list
it's very easy to miss things)
> Hello.
>
> I bisected this problem with fonts (and mu
On 2/27/19 8:01 PM, David Gibson wrote:
> On Wed, Feb 27, 2019 at 04:47:30PM -0800, Richard Henderson wrote:
>> On 2/24/19 3:31 PM, David Gibson wrote:
>>> I have access to POWER8 and POWER9 machines, but I haven't worked with
>>> RISU before. If you can give me a straightforward recipe I can try
1 - 100 of 412 matches
Mail list logo
