Hi,
On Mon, Sep 17, 2018 at 02:06:02PM -0400, Boris Ostrovsky wrote:
> On 9/16/18 7:43 AM, Pasi Kärkkäinen wrote:
> > Hi,
> >
> > On Mon, Dec 18, 2017 at 12:32:11PM -0500, Boris Ostrovsky wrote:
> >> On 12/18/2017 02:36 AM, Jan Beulich wrote:
> >> On 15.12.17 at 20:52, wrote:
> >>> +stati
flight 127701 xen-4.10-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/127701/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-rtds broken
test-amd64-i386-libvirt-pair
Ping?
> -Original Message-
> From: Paul Durrant [mailto:paul.durr...@citrix.com]
> Sent: 11 September 2018 16:01
> To: xen-devel@lists.xenproject.org
> Cc: Paul Durrant ; Andrew Cooper
> ; George Dunlap ; Ian
> Jackson ; Jan Beulich ; Julien
> Grall ; Konrad Rzeszutek Wilk
> ; Stefano Stab
On Mon, Sep 17, 2018 at 10:15:11AM -0600, Jan Beulich wrote:
> >>> On 17.09.18 at 15:37, wrote:
> > On Mon, Sep 17, 2018 at 07:03:27AM -0600, Jan Beulich wrote:
> >> >>> On 14.09.18 at 13:16, wrote:
> >> > @@ -420,16 +393,24 @@ static int __init pvh_setup_p2m(struct domain *d)
> >> > add
Identity mapping RAM regions on the low 1MB for Dom0 is not ideal,
since there's data there that could be used by Xen during runtime
(like the AP trampoline), so instead of identity mapping the low 1MB
into the Dom0 physmap populate those RAM regions and copy the data.
Note that this allows to rem
flight 127707 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/127707/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf b06dfd40bb5cf9fdd626a79a300253f193b600ae
baseline version:
ovmf cfd10276ce747129bb264
> On Sep 18, 2018, at 8:15 AM, Pasi Kärkkäinen wrote:
>
> Hi,
>
> On Mon, Sep 17, 2018 at 02:06:02PM -0400, Boris Ostrovsky wrote:
>> On 9/16/18 7:43 AM, Pasi Kärkkäinen wrote:
>>> Hi,
>>>
>>> On Mon, Dec 18, 2017 at 12:32:11PM -0500, Boris Ostrovsky wrote:
On 12/18/2017 02:36 AM, Jan Be
When a driver domain (e.g. dom0) is running out of maptrack entries it
can't map any more foreign domain pages. Instead of silently stalling
the affected domUs issue a rate limited warning in this case in order
to make it easier to detect that situation.
Signed-off-by: Juergen Gross
---
drivers/
On Thu, 2018-09-13 at 08:17 -0600, Jan Beulich wrote:
> > > > On 12.09.18 at 11:47, wrote:
> >
> > The original version of the patch emulated the current instruction
> > (which, as a side-effect, emulated the page-walk as well), however
> > we
> > need finer-grained control. We want to emulate th
flight 75240 distros-debian-snapshot real [real]
http://osstest.xensource.com/osstest/logs/75240/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-armhf-pvopsbroken
build-i386
>>> On 18.09.18 at 11:47, wrote:
> On Thu, 2018-09-13 at 08:17 -0600, Jan Beulich wrote:
>> > > > On 12.09.18 at 11:47, wrote:
>> >
>> > The original version of the patch emulated the current instruction
>> > (which, as a side-effect, emulated the page-walk as well), however
>> > we
>> > need fi
flight 127704 xen-4.11-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/127704/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-xl-qemuu-debianhvm-amd64-shadow broken
test-amd64-i386-migrupgrad
>>> On 18.09.18 at 08:02, wrote:
> Instead of using binary hypervisor interfaces for new parameters of
> domains or cpupools this patch series adds support for generic text
> based parameter parsing.
>
> Parameters are defined via new macros similar to those of boot
> parameters. Parsing of param
>>> On 13.09.18 at 17:01, wrote:
> Create a single mapping for multiple domain pages.
At least as far as map_domain_pages_global() goes, you will want to justify
why what we have isn't enough.
> --- a/tools/libxc/xc_vm_event.c
> +++ b/tools/libxc/xc_vm_event.c
> @@ -74,7 +74,7 @@ static int xc_v
On 18/09/18 12:32, Jan Beulich wrote:
On 18.09.18 at 08:02, wrote:
>> Instead of using binary hypervisor interfaces for new parameters of
>> domains or cpupools this patch series adds support for generic text
>> based parameter parsing.
>>
>> Parameters are defined via new macros similar to t
On 09/13/2018 12:53 PM, Dario Faggioli wrote:
> Whether or not a CPU is assigned to a runqueue (and, if yes, to which
> one) within a Credit2 scheduler instance must be both a per-cpu and
> per-scheduler instance one.
>
> In fact, when we move a CPU between cpupools, we first setup its per-cpu
> d
On 18/09/18 12:32, Jan Beulich wrote:
On 18.09.18 at 08:02, wrote:
>> Instead of using binary hypervisor interfaces for new parameters of
>> domains or cpupools this patch series adds support for generic text
>> based parameter parsing.
>>
>> Parameters are defined via new macros similar to t
On 09/18/2018 12:10 PM, Juergen Gross wrote:
> On 18/09/18 12:32, Jan Beulich wrote:
> On 18.09.18 at 08:02, wrote:
>>> Instead of using binary hypervisor interfaces for new parameters of
>>> domains or cpupools this patch series adds support for generic text
>>> based parameter parsing.
>>>
>
>>> On 18.09.18 at 13:02, wrote:
> On 18/09/18 12:32, Jan Beulich wrote:
> On 18.09.18 at 08:02, wrote:
>>> Instead of using binary hypervisor interfaces for new parameters of
>>> domains or cpupools this patch series adds support for generic text
>>> based parameter parsing.
>>>
>>> Paramete
>>> On 18.09.18 at 13:10, wrote:
> On 18/09/18 12:32, Jan Beulich wrote:
> On 18.09.18 at 08:02, wrote:
>>> Instead of using binary hypervisor interfaces for new parameters of
>>> domains or cpupools this patch series adds support for generic text
>>> based parameter parsing.
>>>
>>> Paramete
On 09/18/2018 12:19 PM, Jan Beulich wrote:
On 18.09.18 at 13:02, wrote:
>> On 18/09/18 12:32, Jan Beulich wrote:
>> On 18.09.18 at 08:02, wrote:
Instead of using binary hypervisor interfaces for new parameters of
domains or cpupools this patch series adds support for generic te
flight 127765 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/127765/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-libvirt 13 migrate-support-checkfail never pass
test-arm64-arm64-xl-xsm 1
>>> On 18.09.18 at 13:20, wrote:
> On 09/18/2018 12:19 PM, Jan Beulich wrote:
> On 18.09.18 at 13:02, wrote:
>>> On 18/09/18 12:32, Jan Beulich wrote:
>>> On 18.09.18 at 08:02, wrote:
> Instead of using binary hypervisor interfaces for new parameters of
> domains or cpupools this
On 18/09/18 13:20, George Dunlap wrote:
> On 09/18/2018 12:19 PM, Jan Beulich wrote:
> On 18.09.18 at 13:02, wrote:
>>> On 18/09/18 12:32, Jan Beulich wrote:
>>> On 18.09.18 at 08:02, wrote:
> Instead of using binary hypervisor interfaces for new parameters of
> domains or cpupool
On 18/09/18 13:19, Jan Beulich wrote:
On 18.09.18 at 13:02, wrote:
>> On 18/09/18 12:32, Jan Beulich wrote:
>> On 18.09.18 at 08:02, wrote:
Instead of using binary hypervisor interfaces for new parameters of
domains or cpupools this patch series adds support for generic text
>>
On 18/09/18 13:23, Jan Beulich wrote:
On 18.09.18 at 13:20, wrote:
>> On 09/18/2018 12:19 PM, Jan Beulich wrote:
>> On 18.09.18 at 13:02, wrote:
On 18/09/18 12:32, Jan Beulich wrote:
On 18.09.18 at 08:02, wrote:
>> Instead of using binary hypervisor interfaces for new
On 09/18/2018 12:23 PM, Jan Beulich wrote:
On 18.09.18 at 13:20, wrote:
>> On 09/18/2018 12:19 PM, Jan Beulich wrote:
>> On 18.09.18 at 13:02, wrote:
On 18/09/18 12:32, Jan Beulich wrote:
On 18.09.18 at 08:02, wrote:
>> Instead of using binary hypervisor interfaces for
On 18/09/18 13:18, George Dunlap wrote:
> On 09/18/2018 12:10 PM, Juergen Gross wrote:
>> On 18/09/18 12:32, Jan Beulich wrote:
>> On 18.09.18 at 08:02, wrote:
Instead of using binary hypervisor interfaces for new parameters of
domains or cpupools this patch series adds support for g
On 18/09/18 13:20, Jan Beulich wrote:
On 18.09.18 at 13:10, wrote:
>> On 18/09/18 12:32, Jan Beulich wrote:
>> On 18.09.18 at 08:02, wrote:
Instead of using binary hypervisor interfaces for new parameters of
domains or cpupools this patch series adds support for generic text
>>
On 18/09/18 13:29, George Dunlap wrote:
> On 09/18/2018 12:23 PM, Jan Beulich wrote:
> On 18.09.18 at 13:20, wrote:
>>> On 09/18/2018 12:19 PM, Jan Beulich wrote:
>>> On 18.09.18 at 13:02, wrote:
> On 18/09/18 12:32, Jan Beulich wrote:
> On 18.09.18 at 08:02, wrote:
>>> I
01: support AVX512 opmask insns
02: x86/HVM: grow MMIO cache data size to 64 bytes
03: correct EVEX decoding
04: generalize vector length handling for AVX512/EVEX
05: support basic AVX512 moves
06: test for correct EVEX Disp8 scaling
07: use AVX512 logic for emulating V{,P}MASKMOV*
08: support AVX5
>>> On 18.09.18 at 13:26, wrote:
> On 18/09/18 13:19, Jan Beulich wrote:
> On 18.09.18 at 13:02, wrote:
>>> On 18/09/18 12:32, Jan Beulich wrote:
>>> On 18.09.18 at 08:02, wrote:
> Instead of using binary hypervisor interfaces for new parameters of
> domains or cpupools this patc
There seem to be some problems as result of 30467e0b3be ("mm, hotplug:
fix concurrent memory hot-add deadlock"), which tried to fix a possible
lock inversion reported and discussed in [1] due to the two locks
a) device_lock()
b) mem_hotplug_lock
While add_memory() first takes b), f
Reading through the code and studying how mem_hotplug_lock is to be used,
I noticed that there are two places where we can end up calling
device_online()/device_offline() - online_pages()/offline_pages() without
the mem_hotplug_lock. And there are other places where we call
device_online()/device_o
remove_memory() is exported right now but requires the
device_hotplug_lock, which is not exported. So let's provide a variant
that takes the lock and only export that one.
The lock is already held in
arch/powerpc/platforms/pseries/hotplug-memory.c
drivers/acpi/acpi_memhotplug.c
So,
Let's perform all checking + offlining + removing under
device_hotplug_lock, so nobody can mess with these devices via
sysfs concurrently.
Cc: Benjamin Herrenschmidt
Cc: Paul Mackerras
Cc: Michael Ellerman
Cc: Rashmica Gupta
Cc: Balbir Singh
Cc: Michael Neuling
Reviewed-by: Pavel Tatashin
S
device_online() should be called with device_hotplug_lock() held.
Cc: Benjamin Herrenschmidt
Cc: Paul Mackerras
Cc: Michael Ellerman
Cc: Rashmica Gupta
Cc: Balbir Singh
Cc: Michael Neuling
Reviewed-by: Pavel Tatashin
Signed-off-by: David Hildenbrand
---
arch/powerpc/platforms/powernv/memt
add_memory() currently does not take the device_hotplug_lock, however
is aleady called under the lock from
arch/powerpc/platforms/pseries/hotplug-memory.c
drivers/acpi/acpi_memhotplug.c
to synchronize against CPU hot-remove and similar.
In general, we should hold the device_hotplug
Let's document the magic a bit, especially why device_hotplug_lock is
required when adding/removing memory and how it all play together with
requests to online/offline memory from user space.
Cc: Jonathan Corbet
Cc: Michal Hocko
Cc: Andrew Morton
Reviewed-by: Pavel Tatashin
Signed-off-by: Davi
>>> On 18.09.18 at 13:29, wrote:
> On 09/18/2018 12:23 PM, Jan Beulich wrote:
> On 18.09.18 at 13:20, wrote:
>>> On 09/18/2018 12:19 PM, Jan Beulich wrote:
>>> On 18.09.18 at 13:02, wrote:
> On 18/09/18 12:32, Jan Beulich wrote:
> On 18.09.18 at 08:02, wrote:
>>> Instead
These are all VEX encoded, so the EVEX decoding logic continues to
remain unused at this point.
The new testcase is deliberately coded in assembly, as a C one would
have become almost unreadable due to the overwhelming amount of
__builtin_...() that would need to be used. After all the compiler ha
This is needed before enabling any AVX512 insns in the emulator. Change
the way alignment is enforced at the same time.
Add a check that the buffer won't actually overflow, and while at it
also convert the check for accesses to not cross page boundaries.
Signed-off-by: Jan Beulich
---
v3: New.
flight 127721 freebsd-master real [real]
http://logs.test-lab.xenproject.org/osstest/logs/127721/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
freebsd 6c2192b1ef8c50788c751f878552526800b1e319
baseline version:
freebsd 209b94df870
Fix an inverted pair of checks, drop an incorrect instance of #UD
raising for non-64-bit mode, and add further generic checks.
Note: Other than SDM Vol 2 rev 067 states, EVEX.V' is _not_ ignored
outside of 64-bit mode when the field does not encode a register.
Just like EVEX. is re
To allow for some code sharing where possible, copy VEX.L into EVEX.LR
even for VEX (or XOP) encoded insns. Make operand size determination
use this right away, at the same time adding consistency checks for the
EVEX scalar insn cases (the non-scalar ones aren't uniform enough for
the checking to b
Note: SDM Vol 2 rev 067 is not really consistent about EVEX.L'L for LIG
insns - the only place where this is made explicit is a table in
the section titled "Vector Length Orthogonality": While they
tolerate 0, 1, and 2, a value of 3 uniformly leads to #UD.
Signed-off-by: Jan Beul
Besides the already existing tests (which are going to be extended once
respective ISA extension support is complete), let's also ensure for
every individual insn that their Disp8 scaling (and memory access width)
are correct.
Signed-off-by: Jan Beulich
---
v3: New.
--- a/tools/tests/x86_emulato
The more generic AVX512 implementation allows quite a bit of insn-
specific code to be dropped/shared.
Signed-off-by: Jan Beulich
--- a/xen/arch/x86/x86_emulate/x86_emulate.c
+++ b/xen/arch/x86/x86_emulate/x86_emulate.c
@@ -437,8 +437,8 @@ static const struct ext0f38_table {
[0x28 ... 0x29]
Signed-off-by: Jan Beulich
---
v3: New.
--- a/tools/tests/x86_emulator/evex-disp8.c
+++ b/tools/tests/x86_emulator/evex-disp8.c
@@ -130,6 +130,13 @@ static const struct test avx512bw_all[]
INSN(movdqu16,f2, 0f, 7f,vl, w, vl),
};
+static const struct test avx512dq_all[] = {
+
Signed-off-by: Jan Beulich
---
v3: New.
--- a/tools/tests/x86_emulator/evex-disp8.c
+++ b/tools/tests/x86_emulator/evex-disp8.c
@@ -90,6 +90,10 @@ enum esz {
INSN_SFP(m, sp, o)
static const struct test avx512f_all[] = {
+INSN_FP(add, 0f, 58),
+INSN_FP(div,
Also correct the AVX counterpart's comment.
Signed-off-by: Jan Beulich
---
v3: New.
--- a/tools/tests/x86_emulator/evex-disp8.c
+++ b/tools/tests/x86_emulator/evex-disp8.c
@@ -91,6 +91,7 @@ enum esz {
static const struct test avx512f_all[] = {
INSN_FP(add, 0f, 58),
+INSN_
Also correct an AVX counterpart's comment.
Signed-off-by: Jan Beulich
---
v3: New.
--- a/tools/tests/x86_emulator/evex-disp8.c
+++ b/tools/tests/x86_emulator/evex-disp8.c
@@ -113,8 +113,11 @@ static const struct test avx512f_all[] =
INSN_PFP_NB(movu,0f, 10),
INSN_PFP_NB(movu,
Signed-off-by: Jan Beulich
---
v3: New.
--- a/tools/tests/x86_emulator/evex-disp8.c
+++ b/tools/tests/x86_emulator/evex-disp8.c
@@ -93,6 +93,36 @@ static const struct test avx512f_all[] =
INSN_FP(add, 0f, 58),
INSN_FP(cmp, 0f, c2),
INSN_FP(div, 0
Plus vpternlog{d,q} as being extensively used by the compiler, in order
to facilitate test enabling in the harness as soon as possible. Also the
twobyte_table[] entries for a few more insns get their .d8s field set
right away, in order to not split and later re-combine the groups.
Signed-off-by: J
Signed-off-by: Jan Beulich
---
v3: New.
--- a/tools/tests/x86_emulator/evex-disp8.c
+++ b/tools/tests/x86_emulator/evex-disp8.c
@@ -91,6 +91,7 @@ enum esz {
static const struct test avx512f_all[] = {
INSN_FP(add, 0f, 58),
+INSN(broadcastss, 66, 0f38, 18,el, d, el
In preparation for sensible to-boolean conversion on AVX512, wrap
another abstraction function around the present to_bool( == ), to
get rid of the open-coded == (which will get in the way of using
built-in functions instead). For the future AVX512 use scalar operands
can't be used then anymore: Use
Signed-off-by: Jan Beulich
---
v3: New.
--- a/tools/tests/x86_emulator/evex-disp8.c
+++ b/tools/tests/x86_emulator/evex-disp8.c
@@ -93,6 +93,8 @@ static const struct test avx512f_all[] =
INSN_FP(add, 0f, 58),
INSN(broadcastss, 66, 0f38, 18,el, d, el),
INSN_FP(
Include VPTEST{,N}M{B,D,Q,W} as once again possibly used by the compiler
for comparison against all-zero vectors.
Also table entries for a few more insns get their .d8s field set right
away, again in order to not split and later re-combine the groups.
Signed-off-by: Jan Beulich
---
v3: New.
---
Note: vpadd* / vpsub* et al are put at seemingly the wrong slot of the
big switch(). This is in anticipation of adding vpunpck* to those
groups (see the legacy/VEX encoded case labels nearby to support this).
Signed-off-by: Jan Beulich
---
v3: New.
--- a/tools/tests/x86_emulator/evex-disp8.c
+++
Note that simd_packed_fp for the opcode space 0f38 major opcodes 14 and
15 is not really correct, but sufficient for the purposes here. Further
adjustments may later be needed for the down conversion unsigned
saturating VPMOV* insns, first and foremost for the different Disp8
scaling those ones use
This eliminates a separate case block here, and allows to get away with
fewer new ones when adding AVX512 vector shifts.
Signed-off-by: Jan Beulich
---
v3: New.
--- a/xen/arch/x86/x86_emulate/x86_emulate.c
+++ b/xen/arch/x86/x86_emulate/x86_emulate.c
@@ -364,19 +364,19 @@ static const struct two
Signed-off-by: Jan Beulich
---
v3: New.
--- a/tools/tests/x86_emulator/evex-disp8.c
+++ b/tools/tests/x86_emulator/evex-disp8.c
@@ -198,6 +198,7 @@ static const struct test avx512f_all[] =
};
static const struct test avx512f_128[] = {
+INSN(extractps, 66, 0f3a, 17, el,d, el),
INS
Also correct the comment of the AVX form of VINSERTPS.
Signed-off-by: Jan Beulich
---
v3: New.
--- a/tools/tests/x86_emulator/evex-disp8.c
+++ b/tools/tests/x86_emulator/evex-disp8.c
@@ -199,6 +199,7 @@ static const struct test avx512f_all[] =
static const struct test avx512f_128[] = {
I
Test various of the insns which have been implemented already.
Signed-off-by: Jan Beulich
---
v3: New.
--- a/tools/tests/x86_emulator/Makefile
+++ b/tools/tests/x86_emulator/Makefile
@@ -11,7 +11,7 @@ all: $(TARGET)
run: $(TARGET)
./$(TARGET)
-SIMD := 3dnow sse sse2 sse4 avx avx2 xop
Note that the pbroadcastw table entry in evex-disp8.c is slightly
different from what one would expect, due to it requiring EVEX.W to be
zero.
Signed-off-by: Jan Beulich
---
v3: New.
--- a/tools/tests/x86_emulator/evex-disp8.c
+++ b/tools/tests/x86_emulator/evex-disp8.c
@@ -150,6 +150,9 @@ stati
Test the 128- and 256-bit variants of the insns which have been
implemented already.
Signed-off-by: Jan Beulich
---
v3: New.
--- a/tools/tests/x86_emulator/Makefile
+++ b/tools/tests/x86_emulator/Makefile
@@ -52,7 +52,7 @@ avx2-sg-flts := 4 8
xop-vecs := $(avx-vecs)
xop-ints := 1 2 4 8
xop-fl
Note that the vpmov{,s,us}{d,q}w table entries in evex-disp8.c are
slightly different from what one would expect, due to them requiring
EVEX.W to be zero.
Signed-off-by: Jan Beulich
---
v3: New.
--- a/tools/tests/x86_emulator/evex-disp8.c
+++ b/tools/tests/x86_emulator/evex-disp8.c
@@ -163,11 +1
Note that the testing in simd.c doesn't really follow the ISA extension
pattern - to fit the scheme, extensions from byte and word granular
vectors can (currently) sensibly only happen in the AVX512BW case (and
hence respective abstraction macros will be added there rather than
here).
Signed-off-b
There's once again one extra twobyte_table[] entry which gets its Disp8
shift value set right away without getting support implemented just yet,
again to avoid needlessly splitting groups of entries.
Signed-off-by: Jan Beulich
---
v3: New.
--- a/tools/tests/x86_emulator/evex-disp8.c
+++ b/tools/
Take the liberty and also correct the (public interface) name of the
AVX512_VBMI feature flag, on the assumption that no external consumer
has actually been using that flag so far. Furthermore make it have
AVX512BW instead of AVX512F as a prerequisite, for requiring full
64-bit mask registers (the
Also include shuff{32x4,64x2} as being very similar to shufi{32x4,64x2}.
Signed-off-by: Jan Beulich
---
v3: New.
--- a/tools/tests/x86_emulator/evex-disp8.c
+++ b/tools/tests/x86_emulator/evex-disp8.c
@@ -200,6 +200,7 @@ static const struct test avx512f_all[] =
INSN(prolv,66, 0f38,
Entries to the tables in evex-disp8.c are added despite these insns not
allowing for memory operands, with the goal of the tables giving a
complete picture of the supported EVEX-encoded insns in the end.
Signed-off-by: Jan Beulich
---
v3: New.
--- a/tools/tests/x86_emulator/evex-disp8.c
+++ b/to
Test various of the insns which have been implemented already.
Signed-off-by: Jan Beulich
---
v3: New.
--- a/tools/tests/x86_emulator/Makefile
+++ b/tools/tests/x86_emulator/Makefile
@@ -11,7 +11,7 @@ all: $(TARGET)
run: $(TARGET)
./$(TARGET)
-SIMD := 3dnow sse sse2 sse4 avx avx2 xop
In order to be able to verify the 32-bit variant builds and runs,
introduce a respective target (and the necessary other adjustments).
Signed-off-by: Jan Beulich
---
v3: New.
--- a/.gitignore
+++ b/.gitignore
@@ -240,6 +240,7 @@ tools/security/xensec_tool
tools/tests/depriv/depriv-fd-checker
t
Test various of the insns which have been implemented already.
Signed-off-by: Jan Beulich
---
v3: New.
--- a/tools/tests/x86_emulator/Makefile
+++ b/tools/tests/x86_emulator/Makefile
@@ -11,7 +11,7 @@ all: $(TARGET)
run: $(TARGET)
./$(TARGET)
-SIMD := 3dnow sse sse2 sse4 avx avx2 xop
Having noticed that VMLOAD alone is about as fast as a single of the
involved WRMSRs, I thought it might be a reasonable idea to also use it
for PV. Measurements, however, have shown that an actual improvement can
be achieved only with an early prefetch of the VMCB (thanks to Andrew
for suggesting
1: use PDEP/PEXT for maddr/direct-map-offset conversion when available
2: use PDEP/PEXT for PFN/PDX conversion when available
3: use MOV for PFN/PDX conversion when possible
4: use PDEP for PTE flags insertion when available
Signed-off-by: Jan Beulich
---
v4: Indentation adjustments. Comments.
v3
This allows to fold 6 instructions into a single one, reducing code size
quite a bit, especially when not considering the fallback functions
(which won't ever need to be brought into iCache or their mappings into
iTLB on systems supporting BMI2).
Make use of gcc's new V operand modifier, even if t
Both replace 6 instructions by a single one, further reducing code size,
cache, and TLB footprint (in particular on systems supporting BMI2).
Signed-off-by: Jan Beulich
---
v4: "Bodge" alternative_io() indentation here so that it'll come out
right without re-indenting after patch 3.
v2: Avoid
Most x86 systems don't actually require the use of PDX compression. Now
that we have patching for the conversion code in place anyway, extend it
to use simple MOV when possible. Introduce a new pseudo-CPU-feature to
key the patching off of.
Signed-off-by: Jan Beulich
Acked-by: Andrew Cooper
---
This replaces 5 instructions by a single one, further reducing code size,
cache, and TLB footprint (in particular on systems supporting BMI2).
Signed-off-by: Jan Beulich
---
Irrespective of the note regarding a possible alternative route, I think
the change here is an improvement until someone wo
Ping?
>>> On 11.09.18 at 10:20, wrote:
On 29.08.18 at 14:36, wrote:
>> On 21/08/18 11:44, Jan Beulich wrote:
>>> While commit 2a3b34ec47 ("x86/spec-ctrl: Yet more fixes for xpti=
>>> parsing") indeed fixed "xpti=dom0", it broke "xpti=no-dom0", in that
>>> this then became equivalent to "xpt
>>> On 30.08.18 at 10:13, wrote:
> On Wed, Aug 29, 2018 at 10:03:01AM -0600, Jan Beulich wrote:
>> Eliminates a couple of branches in particular from the context switch
>> path.
>>
>> Signed-off-by: Jan Beulich
>
> Reviewed-by: Wei Liu
Andrew?
Thanks, Jan
_
>>> On 10.09.18 at 16:01, wrote:
> That earlier change introduced two "else switch ()" constructs which now
> get converted back to "normal" style (indentation). To limit indentation
> depth, a conditional gets inverted in ptwr_emulated_update().
>
> No functional change intended.
>
> Requested-
>>> On 10.09.18 at 16:02, wrote:
> Rather than unconditionally using vCPU 0, use the current vCPU if the
> subject domain is the current one.
>
> Signed-off-by: Jan Beulich
>
> --- a/xen/arch/x86/mm/paging.c
> +++ b/xen/arch/x86/mm/paging.c
> @@ -858,7 +858,7 @@ void pagetable_dying(struct doma
flight 127717 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/127717/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-i386-libvirt6 libvirt-buildfail REGR. vs. 123814
build-amd64-libvirt
>>> On 13.09.18 at 17:02, wrote:
> --- a/xen/arch/x86/domain_page.c
> +++ b/xen/arch/x86/domain_page.c
> @@ -331,10 +331,9 @@ void *__map_domain_pages_global(const struct page_info
> *pg, unsigned int nr)
> {
> mfn_t mfn[nr];
> int i;
> -struct page_info *cur_pg = (struct page_info
>>> On 14.09.18 at 15:58, wrote:
> Or else it can lead to freezes when enabling the iommu on certain
> Intel hardware:
>
> [...]
> (XEN) ELF: addresses:
> (XEN) virt_base= 0x8000
> (XEN) elf_paddr_offset = 0x0
> (XEN) virt_offset = 0x8000
> (XEN)
>>> On 18.09.18 at 10:55, wrote:
> @@ -399,7 +372,8 @@ static int __init pvh_setup_p2m(struct domain *d)
> } while ( preempted );
>
> /*
> - * Memory below 1MB is identity mapped.
> + * Memory below 1MB is identity mapped except RAM regions that are
> + * populated and copi
>>> On 13.09.18 at 17:21, wrote:
> --- a/xen/include/asm-arm/p2m.h
> +++ b/xen/include/asm-arm/p2m.h
> @@ -303,6 +303,10 @@ static inline struct page_info *get_page_from_gfn(
> return page;
> }
>
> +int __must_check check_get_page_from_gfn(struct domain *d, gfn_t gfn,
> +
>>> On 13.09.18 at 17:21, wrote:
> @@ -179,9 +181,17 @@ struct iommu_ops {
> #endif /* HAS_PCI */
>
> void (*teardown)(struct domain *d);
> +
> +/*
> + * This block of operations must be appropriately locked against each
> + * other to have meaningful results.
> + */
>
On 09/18/2018 12:32 PM, Juergen Gross wrote:
> On 18/09/18 13:20, Jan Beulich wrote:
> On 18.09.18 at 13:10, wrote:
>>> On 18/09/18 12:32, Jan Beulich wrote:
>>> On 18.09.18 at 08:02, wrote:
> Instead of using binary hypervisor interfaces for new parameters of
> domains or cpupool
The patch file 00cvs is an import of a new upstream version of
grub1 from upstream CVS.
Unfortunately, in the period covered by the update, upstream changed
the documentation licence from a simple permissive licence, to the GNU
"Free Documentation Licence" with Front and Back Cover Texts.
The Deb
On 18/09/18 15:25, George Dunlap wrote:
> On 09/18/2018 12:32 PM, Juergen Gross wrote:
>> On 18/09/18 13:20, Jan Beulich wrote:
>> On 18.09.18 at 13:10, wrote:
On 18/09/18 12:32, Jan Beulich wrote:
On 18.09.18 at 08:02, wrote:
>> Instead of using binary hypervisor interfaces
On Tue, Sep 18, 2018 at 2:36 PM Ian Jackson wrote:
>
> The patch file 00cvs is an import of a new upstream version of
> grub1 from upstream CVS.
>
> Unfortunately, in the period covered by the update, upstream changed
> the documentation licence from a simple permissive licence, to the GNU
> "Free
On 09/18/2018 02:36 PM, Juergen Gross wrote:
> On 18/09/18 15:25, George Dunlap wrote:
>> On 09/18/2018 12:32 PM, Juergen Gross wrote:
>>> On 18/09/18 13:20, Jan Beulich wrote:
>>> On 18.09.18 at 13:10, wrote:
> On 18/09/18 12:32, Jan Beulich wrote:
> On 18.09.18 at 08:02, wrote:
> -Original Message-
> From: Jan Beulich [mailto:jbeul...@suse.com]
> Sent: 18 September 2018 14:20
> To: Paul Durrant
> Cc: George Dunlap ; Wei Liu
> ; Kevin Tian ; xen-devel de...@lists.xenproject.org>
> Subject: Re: [PATCH v9 7/7] vtd: add lookup_page method to iommu_ops
>
> >>> On 13
This matches the nomenclature used by the rest of the guest-related
functions.
No functional change.
Signed-off-by: Roger Pau Monné
---
Cc: Jan Beulich
Cc: Andrew Cooper
Cc: Wei Liu
---
xen/arch/x86/guest/pvh-boot.c | 2 +-
xen/arch/x86/guest/xen.c| 2 +-
xen/arch/x86/setup.c
> -Original Message-
> From: Xen-devel [mailto:xen-devel-boun...@lists.xenproject.org] On Behalf
> Of Jan Beulich
> Sent: 18 September 2018 14:17
> To: Paul Durrant
> Cc: Stefano Stabellini ; Wei Liu
> ; Konrad Rzeszutek Wilk ;
> George Dunlap ; Andrew Cooper
> ; Ian Jackson ; Tim
> (Xen.o
This run is configured for baseline tests only.
flight 75241 ovmf real [real]
http://osstest.xensource.com/osstest/logs/75241/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-xsm
1 - 100 of 145 matches
Mail list logo
