With being able to specify a dom0_mem value depending on host memory
size on x86 make it easy for distros to specify a default dom0 size by
adding a CONFIG_DOM0_MEM item which presets the dom0_mem boot parameter
value.
It will be used only if no dom0_mem parameter was specified in the
boot paramet
Setting the memory size of dom0 on a server for the non autoballooning
case requires always specification of a boot parameter today. The value
to set will depend mostly on the host memory size.
In order to support that scenario add the possibility to set dom0_mem
depending on the amount of physica
Introduce parse_size_and_unit_or_int() similar to parse_size_and_unit()
but not defaulting to kbytes in case the parameter is a number followed
by a specified character.
Signed-off-by: Juergen Gross
---
xen/common/lib.c | 11 +--
xen/include/xen/lib.h | 2 ++
2 files changed, 11 in
Today the memory size of dom0 can be specified only in terms of bytes
(either an absolute value or "host-mem - value"). When dom0 shouldn't
be auto-ballooned this requires nearly always a manual adaption of the
Xen boot parameters to reflect the actual host memory size.
Add more possibilities to s
>>> On 05.12.18 at 21:33, wrote:
> On 10/09/2018 11:13, Jan Beulich wrote:
>>
>>> Equally, it may still be able to service #MC's, so I can't see how it is
>>> safe for us to ever free the percpu data.
>> I'm having trouble seeing how this remark relates to the series here.
>
> Because you've trie
>>> On 05.12.18 at 18:50, wrote:
> On 05/12/2018 16:39, Jan Beulich wrote:
> On 03.12.18 at 17:18, wrote:
>>> As an alternative, MSR_VIRT_SPEC_CTRL is specified as an architectural
>>> control
>>> (with semantics equivilent to MSR_SPEC_CTRL) which is provided by the
>>> hypervisor. This abs
>>> On 05.12.18 at 18:09, wrote:
> On 05/12/2018 16:50, Jan Beulich wrote:
>>
>>> --- a/xen/include/asm-x86/cpufeatures.h
>>> +++ b/xen/include/asm-x86/cpufeatures.h
>>> @@ -25,6 +25,7 @@ XEN_CPUFEATURE(XEN_SMAP,(FSCAPINTS+0)*32+11) /*
>>> SMAP gets used by Xen it
>>> XEN_CPUFEATURE(LFEN
>>> On 05.12.18 at 18:05, wrote:
> On 05/12/2018 16:57, Jan Beulich wrote:
> On 03.12.18 at 17:18, wrote:
>>> --- a/xen/arch/x86/cpu/amd.c
>>> +++ b/xen/arch/x86/cpu/amd.c
>>> @@ -419,6 +419,97 @@ static void __init noinline amd_probe_legacy_ssbd(void)
>>> }
>>>
>>> /*
>>> + * This is all
>>> On 05.12.18 at 20:09, wrote:
> On 05/12/2018 08:41, Jan Beulich wrote:
> On 04.12.18 at 22:35, wrote:
>>> The other thing I don't get is why advertise virtualized SSBD when the
>>> guest setting it does nothing? If ssbd_opt=true is set, as the code is
>>> now, why even advertise it to th
>>> On 05.12.18 at 20:45, wrote:
> --- a/xen/arch/x86/mm.c
> +++ b/xen/arch/x86/mm.c
> @@ -1444,7 +1444,13 @@ static int create_pae_xen_mappings(struct domain *d,
> l3_pgentry_t *pl3e)
>
> pl3e = (l3_pgentry_t *)((unsigned long)pl3e & PAGE_MASK);
>
> -/* 3rd L3 slot contains L2 with
01: support AVX512{F,BW} shift/rotate insns
02: support AVX512{F,BW,DQ} extract insns
03: support AVX512{F,BW,DQ} insert insns
04: basic AVX512F testing
05: support AVX512{F,BW,DQ} integer broadcast insns
06: basic AVX512VL testing
07: support AVX512{F,BW} zero- and sign-extending moves
08: support
>>> On 06.12.18 at 09:06, wrote:
> @@ -477,7 +478,8 @@ unsigned long long parse_size_and_unit(const char *s,
> const char **ps)
> s1++;
> break;
> default:
> -ret <<= 10; /* default to kB */
> +if ( *s1 && *s1 != no_size )
> +ret <<= 10; /* defau
Signed-off-by: Jan Beulich
---
v4: Make use of d8s_dq64.
v3: New.
--- a/tools/tests/x86_emulator/evex-disp8.c
+++ b/tools/tests/x86_emulator/evex-disp8.c
@@ -212,6 +212,7 @@ static const struct test avx512f_all[] =
};
static const struct test avx512f_128[] = {
+INSN(extractps, 66, 0f3a, 1
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
Also correct the comment of the AVX form of VINSERTPS.
Signed-off-by: Jan Beulich
---
v6: Don't refuse to emulate VINSERTPS without AVX512VL.
v4: Make use of d8s_dq64.
v3: New.
--- a/tools/tests/x86_emulator/evex-disp8.c
+++ b/tools/tests/x86_emulator/evex-disp8.c
@@ -213,6 +213,7 @@ static cons
Test various of the insns which have been implemented already.
Signed-off-by: Jan Beulich
---
v6: Fix formatting in simd.h.
v5: Add VSQRT* tests.
v4: Make eq() also work for 4- and 8-byte integer element sizes.
v3: New.
--- a/tools/tests/x86_emulator/Makefile
+++ b/tools/tests/x86_emulator/Makef
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
@@ -164,6 +164,9 @@ stati
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
Test the 128- and 256-bit variants of the insns which have been
implemented already.
Signed-off-by: Jan Beulich
---
v6: Don't enable AVX512VL for scalar tests, nor for S/G ones with index
wider than data. Re-base over changes earlier in the series.
v4: Move OVR() additions into __AVX512VL__ c
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
---
v5: Also adjust x86_insn_is_mem_write().
v4: Also #UD when evex.z is set with a memory operand.
v3: New.
--- a
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
---
v6: Re-base over changes earlier in the series.
v4: Move OVR() add
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
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
Also include shuff{32x4,64x2} as being very similar to shufi{32x4,64x2}.
Signed-off-by: Jan Beulich
---
v6: Re-base over changes earlier in the series.
v5: Re-base over changes earlier in the series.
v4: Move OVR() addition into __AVX512VL__ conditional. Correct comments.
v3: New.
--- a/tools/te
Test various of the insns which have been implemented already.
Signed-off-by: Jan Beulich
---
v6: Re-base over changes earlier in the series.
v4: Add __AVX512VL__ conditional around majority of OVR() additions.
Correct eq() for 1- and 2-byte cases.
v3: New.
--- a/tools/tests/x86_emulator/Mak
Test various of the insns which have been implemented already.
Signed-off-by: Jan Beulich
---
v6: Re-base.
v5: Re-base over changes earlier in the series.
v4: Wrap OVR(pmullq) in __AVX512VL__ conditional.
v3: New.
--- a/tools/tests/x86_emulator/Makefile
+++ b/tools/tests/x86_emulator/Makefile
@@
No explicit test harness additions other than the overrides, as the
compiler already makes use of the insns.
Signed-off-by: Jan Beulich
---
v4: New.
--- a/tools/tests/x86_emulator/evex-disp8.c
+++ b/tools/tests/x86_emulator/evex-disp8.c
@@ -253,6 +253,16 @@ static const struct test avx512f_128[]
Signed-off-by: Jan Beulich
---
v5: Re-base over changes earlier in the series.
v4: New.
--- a/tools/tests/x86_emulator/evex-disp8.c
+++ b/tools/tests/x86_emulator/evex-disp8.c
@@ -178,6 +178,10 @@ static const struct test avx512f_all[] =
INSN(pcmpu,66, 0f3a, 1e,vl, dq, vl),
Judging from insn prefixes, these are scalar insns, but their (memory)
operands are vector ones (with the exception of 128-bit VMOVDDUP). For
this some adjustments to disp8scale calculation code are needed.
No explicit test harness additions other than the overrides, as the
compiler already makes
No further test harness additions - what is there is good enough for
these rather "regular" insns.
Signed-off-by: Jan Beulich
---
v4: New.
--- a/tools/tests/x86_emulator/evex-disp8.c
+++ b/tools/tests/x86_emulator/evex-disp8.c
@@ -306,6 +306,10 @@ static const struct test avx512bw_all[]
INS
... including the two AVX512DQ forms which shared encodings, just with
EVEX.W set there.
VCVTDQ2PD, sharing its main opcode with others, needs a "manual"
override of disp8scale.
The simd_size changes for the twobyte_table[] entries are benign to
pre-existing code, but allow decode_disp8scale() to
VCVTPS2PD, sharing its main opcode with others, needs a "manual"
override of disp8scale.
The simd_size change for twobyte_table[0x5a] is benign to pre-existing
code, but allows decode_disp8scale() to work as is here.
Also correct the comment on an AVX counterpart.
Signed-off-by: Jan Beulich
---
VCVT{,T}S{S,D}2SI use EVEX.W for their destination (register) rather
than their (possibly memory) source operand size and hence need a
"manual" override of disp8scale.
Slightly adjust the scalar to_int() in the test harness, to increase the
chances of the operand ending up in memory.
Signed-off-b
On 06/12/2018 10:50, Jan Beulich wrote:
On 06.12.18 at 09:06, wrote:
>> @@ -477,7 +478,8 @@ unsigned long long parse_size_and_unit(const char *s,
>> const char **ps)
>> s1++;
>> break;
>> default:
>> -ret <<= 10; /* default to kB */
>> +if ( *s1 && *s1
VCVT{,T}PS2QQ, sharing their main opcodes with others, once again need
"manual" overrides of disp8scale.
While not directly related here, also add a scalar variant of to_wint()
to the test harness.
Signed-off-by: Jan Beulich
---
v6: Workaround for gcc 7 quirk.
v5: Re-base over changes earlier in
Some "manual" overrides of disp8scale are needed here again. In
particular code ends up simpler when using d8s_dq64 in the
twobyte_table[] entry.
Test harness additions will be done once the reverse conversions are
also available.
Signed-off-by: Jan Beulich
---
v4: New.
--- a/tools/tests/x86_em
Along the lines of prior patches, VCVT{,T}PS2UQQ as well as
VCVT{,T}S{S,D}2USI need "manual" overrides of disp8scale.
The twobyte_table[] entries get altered, with their prior values
now put in place in x86_decode_twobyte().
Signed-off-by: Jan Beulich
---
v4: New.
--- a/tools/tests/x86_emulator
Also include the only other AVX512ER insn pair, VEXP2P{D,S}.
Note that despite the replacement of the SHA insns' table slots there's
no need to special case their decoding: Their insn-specific code already
sets op_bytes (as was required due to simd_other), and TwoOp is of no
relevance for legacy e
Signed-off-by: Jan Beulich
---
v5: New.
--- a/tools/tests/x86_emulator/evex-disp8.c
+++ b/tools/tests/x86_emulator/evex-disp8.c
@@ -354,6 +354,7 @@ static const struct test avx512bw_all[]
INSN(paddusb, 66, 0f, dc,vl,b, vl),
INSN(paddusw, 66, 0f, dd,vl,w, vl),
Plus their AVX512BW counterparts.
Take the opportunity and also eliminate a pair of open coded instances
of scalar_1op().
Signed-off-by: Jan Beulich
---
v6: Re-base over changes earlier in the series.
v5: New.
--- a/tools/tests/x86_emulator/evex-disp8.c
+++ b/tools/tests/x86_emulator/evex-disp8
Signed-off-by: Jan Beulich
---
v5: New.
--- a/tools/tests/x86_emulator/evex-disp8.c
+++ b/tools/tests/x86_emulator/evex-disp8.c
@@ -140,6 +140,8 @@ static const struct test avx512f_all[] =
INSN(cvtusi2sd,f2, 0f, 7b,el, dq64, el),
INSN(cvtusi2ss,f3, 0f, 7b,el, dq6
This completes support of AVX512DQ in the insn emulator.
Signed-off-by: Jan Beulich
---
v5: New.
--- a/tools/tests/x86_emulator/evex-disp8.c
+++ b/tools/tests/x86_emulator/evex-disp8.c
@@ -457,11 +457,17 @@ static const struct test avx512dq_all[]
INSN(cvttps2uqq, 66, 0f, 78, vl_2, d,
Signed-off-by: Jan Beulich
---
v6: Re-base. Add tests for the byte/word forms.
v5: New.
--- a/tools/tests/x86_emulator/evex-disp8.c
+++ b/tools/tests/x86_emulator/evex-disp8.c
@@ -109,6 +109,7 @@ static const struct test avx512f_all[] =
INSN_FP(cmp, 0f, c2),
INSN(comisd,
This completes support of AVX512BW in the insn emulator, and leaves just
the scatter/gather ones open in the AVX512F set.
Signed-off-by: Jan Beulich
---
v5: New.
---
TBD: The *blendm* inline functions don't reliably produce the intended
insns, as the respective moves are about as good a fit
This requires getting modrm_reg and sib_index set correctly in the EVEX
case, to account for the high 16 [XYZ]MM registers. Extend the
adjustments to modrm_rm as well, such that x86_insn_modrm() would
correctly report register numbers (this was a latent issue only as we
don't currently have callers
In order to verify that in particular the index register decoding works
correctly in the S/G emulation paths, add dedicated (64-bit only) cases
disallowing the compiler to use the lower registers. Other than in the
generic SIMD case, where occasional uses of %xmm or %ymm registers in
generated code
Some adjustments are necessary to the EVEX Disp8 scaling test code to
account for the zero byte reads/writes. I have to admit though that I'm
not fully convinced the SDM describes the faulting behavior correctly:
Other prefetch insns, including the Xeon Phi Coprocessor S/G ones, don't
produce #GP/#
This completes support of AVX512F in the insn emulator.
Note that in the test harness there's a little bit of trickery needed to
get around the not fully consistent naming of AVX512VL gather and
scatter built-ins. To suppress expansion of the "di" and "si" tokens
they get constructed by token conc
Since the insns here and in particular their memory access patterns
follow the usual scheme I didn't think it was necessary to add
contrived tests specifically for them, beyond the Disp8 scaling ones.
Signed-off-by: Jan Beulich
---
v6: New.
--- a/tools/tests/x86_emulator/evex-disp8.c
+++ b/tools
Also add testing of ones support for which was added before. Sadly gcc's
command line option naming is not in line with Intel's naming of the
feature, which makes it necessary to mis-name things in the test harness.
Since the only new insn here and in particular its memory access pattern
follows t
Once again take the liberty and also correct the (public interface) name
of the AVX512_IFMA feature flag, on the assumption that no external
consumer has actually been using that flag so far.
As in a few cases before, since the insns here and in particular their
memory access patterns follow the u
Plus the only other AVX512_BITALG one.
As in a few cases before, since the insns here and in particular their
memory access patterns follow the usual scheme, I didn't think it was
necessary to add a contrived test specifically for them, beyond the
Disp8 scaling one.
Signed-off-by: Jan Beulich
--
As in a few cases before, since the insns here and in particular their
memory access patterns follow the usual scheme, I didn't think it was
necessary to add a contrived test specifically for them, beyond the
Disp8 scaling one.
Signed-off-by: Jan Beulich
---
v6: New.
--- a/tools/tests/x86_emulat
Signed-off-by: Jan Beulich
---
v6: New.
--- a/tools/tests/x86_emulator/evex-disp8.c
+++ b/tools/tests/x86_emulator/evex-disp8.c
@@ -538,6 +538,13 @@ static const struct test avx512pf_512[]
INSNX(scatterpf1q, 66, 0f38, c7, 6, vl, sd, el),
};
+static const struct test avx512_4fmaps_512[] =
As in a few cases before, since the insns here and in particular their
memory access patterns follow the AVX512_4FMAPS scheme, I didn't think
it was necessary to add contrived tests specifically for them, beyond
the Disp8 scaling ones.
Signed-off-by: Jan Beulich
---
v6: New.
--- a/tools/tests/x8
>>> On 06.12.18 at 11:01, wrote:
> On 06/12/2018 10:50, Jan Beulich wrote:
> On 06.12.18 at 09:06, wrote:
>>> @@ -477,7 +478,8 @@ unsigned long long parse_size_and_unit(const char *s,
> const char **ps)
>>> s1++;
>>> break;
>>> default:
>>> -ret <<= 10; /* defa
On 06/12/2018 11:15, Jan Beulich wrote:
On 06.12.18 at 11:01, wrote:
>> On 06/12/2018 10:50, Jan Beulich wrote:
>> On 06.12.18 at 09:06, wrote:
@@ -477,7 +478,8 @@ unsigned long long parse_size_and_unit(const char *s,
>> const char **ps)
s1++;
break;
>>>
It isn't currently written how one is supposed to update the domain
configuration in libxl's private data store. This patch attempt to
document the unwritten rules.
Signed-off-by: Anthony PERARD
---
tools/libxl/CODING_STYLE | 24
1 file changed, 24 insertions(+)
diff --
>>> On 03.12.18 at 17:18, wrote:
> --- a/xen/arch/x86/cpu/amd.c
> +++ b/xen/arch/x86/cpu/amd.c
> @@ -442,6 +442,74 @@ static struct ssbd_ls_cfg {
> } *ssbd_ls_cfg[4];
> static unsigned int ssbd_max_cores;
>
> +/*
> + * Must only be called when the LEGACY_SSBD is in used. Called with NULL to
flight 75638 distros-debian-wheezy real [real]
http://osstest.xensource.com/osstest/logs/75638/
Perfect :-)
All tests in this flight passed as required
baseline version:
flight 75626
jobs:
build-amd64 pass
build-armhf
>>> On 03.12.18 at 17:18, wrote:
> The semantics of MSR_VIRT_SPEC_CTRL are that unknown bits are write-discard
> and read as zero. Only VIRT_SPEC_CTRL.SSBD is defined at the moment.
>
> To facilitate making this per-guest, the legacy SSBD state needs context
> switching between vcpus. amd_ctxt_
>>> On 03.12.18 at 17:18, wrote:
> --- a/xen/arch/x86/cpuid.c
> +++ b/xen/arch/x86/cpuid.c
> @@ -370,6 +370,16 @@ static void __init
> guest_common_feature_adjustments(uint32_t *fs)
> */
> if ( host_cpuid_policy.feat.ibrsb )
> __set_bit(X86_FEATURE_IBPB, fs);
> +
> +/*
> +
>>> On 03.12.18 at 17:18, wrote:
> --- a/xen/include/asm-x86/cpufeatures.h
> +++ b/xen/include/asm-x86/cpufeatures.h
> @@ -25,6 +25,7 @@ XEN_CPUFEATURE(XEN_SMAP,(FSCAPINTS+0)*32+11) /*
> SMAP gets used by Xen it
> XEN_CPUFEATURE(LFENCE_DISPATCH, (FSCAPINTS+0)*32+12) /* lfence set as
> D
>>> On 06.12.18 at 09:06, wrote:
> Today the memory size of dom0 can be specified only in terms of bytes
> (either an absolute value or "host-mem - value"). When dom0 shouldn't
> be auto-ballooned this requires nearly always a manual adaption of the
> Xen boot parameters to reflect the actual host
>>> On 06.12.18 at 09:06, wrote:
> With being able to specify a dom0_mem value depending on host memory
> size on x86 make it easy for distros to specify a default dom0 size by
> adding a CONFIG_DOM0_MEM item which presets the dom0_mem boot parameter
> value.
>
> It will be used only if no dom0_m
On Thu, Nov 29, 2018 at 02:35:17PM +0100, Juergen Gross wrote:
> On 29/11/2018 14:26, Kirill A. Shutemov wrote:
> > On Thu, Nov 29, 2018 at 09:41:25AM +, Juergen Gross wrote:
> >> On 29/11/2018 02:22, Hans van Kranenburg wrote:
> >>> Hi,
> >>>
> >>> As also seen at:
> >>> https://bugs.debian.or
On 06/12/2018 12:08, Jan Beulich wrote:
On 06.12.18 at 09:06, wrote:
>> Today the memory size of dom0 can be specified only in terms of bytes
>> (either an absolute value or "host-mem - value"). When dom0 shouldn't
>> be auto-ballooned this requires nearly always a manual adaption of the
>> X
>>> On 06.12.18 at 12:20, wrote:
> On 06/12/2018 12:08, Jan Beulich wrote:
> On 06.12.18 at 09:06, wrote:
>>> Today the memory size of dom0 can be specified only in terms of bytes
>>> (either an absolute value or "host-mem - value"). When dom0 shouldn't
>>> be auto-ballooned this requires nea
On 06/12/2018 12:13, Greg KH wrote:
> On Thu, Nov 29, 2018 at 02:35:17PM +0100, Juergen Gross wrote:
>> On 29/11/2018 14:26, Kirill A. Shutemov wrote:
>>> On Thu, Nov 29, 2018 at 09:41:25AM +, Juergen Gross wrote:
On 29/11/2018 02:22, Hans van Kranenburg wrote:
> Hi,
>
> As als
On 12/6/18 12:31 PM, Juergen Gross wrote:
> On 06/12/2018 12:13, Greg KH wrote:
>> On Thu, Nov 29, 2018 at 02:35:17PM +0100, Juergen Gross wrote:
>>> On 29/11/2018 14:26, Kirill A. Shutemov wrote:
On Thu, Nov 29, 2018 at 09:41:25AM +, Juergen Gross wrote:
> On 29/11/2018 02:22, Hans va
On 06/12/2018 12:28, Jan Beulich wrote:
On 06.12.18 at 12:20, wrote:
>> On 06/12/2018 12:08, Jan Beulich wrote:
>> On 06.12.18 at 09:06, wrote:
Today the memory size of dom0 can be specified only in terms of bytes
(either an absolute value or "host-mem - value"). When dom0 shou
On Wed, Dec 05, 2018 at 04:26:02PM +, Anthony PERARD wrote:
> Those functions can return NULL on failure, document it in the public
> header.
>
> Signed-off-by: Anthony PERARD
Acked-by: Wei Liu
___
Xen-devel mailing list
Xen-devel@lists.xenprojec
On Thu, Dec 06, 2018 at 12:31:15PM +0100, Juergen Gross wrote:
> On 06/12/2018 12:13, Greg KH wrote:
> > On Thu, Nov 29, 2018 at 02:35:17PM +0100, Juergen Gross wrote:
> >> On 29/11/2018 14:26, Kirill A. Shutemov wrote:
> >>> On Thu, Nov 29, 2018 at 09:41:25AM +, Juergen Gross wrote:
> On
Hi,
On 12/4/18 8:26 PM, Julien Grall wrote:
At the moment, the implementation of Set/Way operations will go through
all the entries of the guest P2M and flush them. However, this is very
expensive and may render unusable a guest OS using them.
For instance, Linux 32-bit will use Set/Way operati
On Thu, Dec 06, 2018 at 10:43:32AM +, Anthony PERARD wrote:
> It isn't currently written how one is supposed to update the domain
> configuration in libxl's private data store. This patch attempt to
> document the unwritten rules.
>
> Signed-off-by: Anthony PERARD
> ---
> tools/libxl/CODING_
> -Original Message-
> From: Anthony PERARD [mailto:anthony.per...@citrix.com]
> Sent: 04 December 2018 12:34
> To: Paul Durrant
> Cc: qemu-bl...@nongnu.org; qemu-de...@nongnu.org; xen-
> de...@lists.xenproject.org; Stefano Stabellini ;
> Kevin Wolf ; Max Reitz
> Subject: Re: [PATCH 14/18
On Wed, Dec 05, 2018 at 03:54:59PM +0100, Roger Pau Monne wrote:
> To note it's calculating the approximate amount of memory required by
> shadow paging.
>
> No functional change.
>
> Signed-off-by: Roger Pau Monné
Reviewed-by: Wei Liu
___
Xen-devel
> -Original Message-
> From: Anthony PERARD [mailto:anthony.per...@citrix.com]
> Sent: 04 December 2018 15:35
> To: Paul Durrant
> Cc: qemu-bl...@nongnu.org; qemu-de...@nongnu.org; xen-
> de...@lists.xenproject.org; Stefano Stabellini
> Subject: Re: [PATCH 15/18] xen: add a mechanism to a
On Wed, Dec 05, 2018 at 03:55:00PM +0100, Roger Pau Monne wrote:
> Current approximation of paging memory usage is based on the required
> amount when running in shadow mode and doesn't take into account the
> memory required by the IOMMU page tables.
>
> Fix this by introducing a function to calc
On Mon, Dec 03, 2018 at 04:18:16PM +, Andrew Cooper wrote:
> For gen-cpuid.py, fix a comment describing self.names, and generate the
> reverse mapping in self.values. Write out INIT_FEATURE_NAMES which maps a
> string name to a bit position.
>
> For parse_cpuid(), introduce a slightly fuzzy s
On Tue, Dec 04, 2018 at 03:28:57PM +0100, Juergen Gross wrote:
> The Xenstore domid isn't set for HVM domains. This will result in
> failure when booting a HVM domain on a system with Xenstore not running
> in dom0.
>
> Same applies for console domid, so set both.
>
> This is broken since commit
> -Original Message-
> From: Anthony PERARD [mailto:anthony.per...@citrix.com]
> Sent: 04 December 2018 16:41
> To: Paul Durrant
> Cc: qemu-bl...@nongnu.org; qemu-de...@nongnu.org; xen-
> de...@lists.xenproject.org; Kevin Wolf ; Max Reitz
> ; Stefano Stabellini
> Subject: Re: [PATCH 16/18
Don't call xen_be_set_max_grant_refs() in usbback_alloc(), as the
gnttabdev pointer won't be initialised yet. The call can easily be
moved to usbback_connect().
Signed-off-by: Juergen Gross
---
hw/usb/xen-usb.c | 12 ++--
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/hw/u
Hey,
Yeah, fallout cleanup after verifiers introduction. Sorry about that.
Now I test build all x86 and ARM supported platforms. I am going to
add others to my test script soon to avoid such mess in the future.
Daniel
grub-core/loader/arm64/xen_boot.c | 8
grub-core/loader/i386/xen.c
Xen fallout cleanup after commit ca0a4f689 (verifiers: File type for
fine-grained signature-verification controlling).
Signed-off-by: Daniel Kiper
---
grub-core/loader/i386/xen.c | 14 +++---
1 file changed, 7 insertions(+), 7 deletions(-)
diff --git a/grub-core/loader/i386/xen.c b/grub
ARM Xen fallout cleanup after commit ca0a4f689 (verifiers: File type for
fine-grained signature-verification controlling).
Signed-off-by: Daniel Kiper
---
grub-core/loader/arm64/xen_boot.c | 8
include/grub/file.h | 5 +
2 files changed, 9 insertions(+), 4 deletions(-)
On Mon, Nov 19, 2018 at 06:05:10PM +, Lars Kurth wrote:
> This patch makes a few clarifications which were discussed on
> IRC recently.
>
> Specifically:
> - Highlight the principle that license deviations
> should be brought to the attention of maintainers
> - Add a requirement for GPLv2
flight 131014 linux-4.9 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/131014/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-armhf-armhf-xl-multivcpu 16 guest-start/debian.repeat fail REGR. vs.
130869
Tests which are fa
flight 131076 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/131076/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-libvirt 13 migrate-support-checkfail never pass
test-armhf-armhf-xl 1
>>> On 05.12.18 at 12:29, wrote:
> A subsequent patch will add semantically different versions of
> iommu_map/unmap() so, in advance of that change, this patch renames the
> existing functions to iommu_legacy_map/unmap() and modifies all call-sites.
> It also adjusts a comment that refers to iommu
On Thu, Dec 06, 2018 at 12:16:40PM +, Wei Liu wrote:
> On Thu, Dec 06, 2018 at 10:43:32AM +, Anthony PERARD wrote:
> > +UPDATE OF DOMAIN CONFIGURATION
> > +--
> > +
> > +Also known as "libxl-json" userdata or `libxl_domain_config'.
> > +
> > +Whenever a running d
I've pulled this into the dma-mapping for-next tree, with the suggestion
from Robin that improves bisectability, and two unused variables found
by the build bot.
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailm
Removing the qmp connection is logically part of the device model
destruction; having the caller destroy it is a mild layering
violation.
Move libxl__qmp_cleanup() into libxl__destroy_device_model(). This
will make it easier when we make devicemodel destruction asynchronous.
Signed-off-by: Georg
To reliably kill an untrusted devicemodel, we need to know not only
its pid, but its uid. In preparation for this, move the userid
determination logic into a helper function.
Create a new field, `dm_runas`, in libxl__domain_build_state to store
the value during domain creation.
This change also
Or at least, give it an asynchronous interface so that we can make it
actually asynchronous in subsequent patches.
Create state structures and callback function signatures. Add the
state structure to libxl__destroy_domid_state. Break
libxl__destroy_domid down into two functions.
No functional c
Bring conventions more in line with libxl__xs_read_checked():
- If found, return 0 and set pointer to non-NULL
- If not found, return 0 and set pointer to NULL
- On error, return libxl-style error number.
Update documentation to match.
Use CODING_STYLE compliant `r` rather than `ret`.
On error,
QEMU_USER_BASE allows a user to specify the UID to use when running
the devicemodel for a specific domain number. Unfortunately, this is
not really practical: It requires nearly 32,000 entries in
/etc/passwd. QEMU_USER_RANGE_BASE is much more practical.
Remove support for QEMU_USER_BASE.
Signed
At the moment, we check for equivalence to literal "root" before
deciding whether to add the `runas` command-line option to QEMU. This
is unsatisfactory for several reasons.
First, just because the string doesn't match "root" doesn't mean the
final uid won't end up being zero; in particular, the
A number of subsequent patches rely on as-yet undefined behavior for
what the `device_model_user` parameter does. Rather than implement it
incorrectly (or randomly), or remove the feature, describe an expected
usage for the feature. Further patches will make decisions based on
this expected usage
Using kill(-1) to killing an untrusted dm process with the real uid
equal to the dm_uid isn't guaranteed to succeed: the process in
question may be able to kill the reaper process after the setresuid()
and before the kill().
Instead, set the real uid to the QEMU user for domain 0
(QEMU_USER_RANGE_
1 - 100 of 188 matches
Mail list logo
