flight 129526 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/129526/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-xsm 6 xen-buildfail REGR. vs. 129475
build-amd64
>>> On 06.11.18 at 23:42, wrote:
> On Tue, 9 Oct 2018, Jan Beulich wrote:
>> >>> On 09.10.18 at 01:37, wrote:
>> > --- a/xen/include/xsm/dummy.h
>> > +++ b/xen/include/xsm/dummy.h
>> > @@ -535,6 +535,20 @@ static XSM_INLINE int
>> > xsm_map_gmfn_foreign(XSM_DEFAULT_ARG struct domain *d, str
>>
flight 129461 xen-4.9-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/129461/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-i386-xl-qemuu-ws16-amd64 17 guest-stop fail blocked in 129090
test-armhf-armhf-xl-rtds 16
flight 129462 xen-4.10-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/129462/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict 10 debian-hvm-install
fail never pass
flight 129460 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/129460/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict 7 xen-boot fail REGR. vs.
125898
Hi Ravi,
You could find code here
https://source.codeaurora.org/external/imx/imx-xen/
The latest public branch should be
https://source.codeaurora.org/external/imx/imx-xen/log/?h=imx_4.14.62_1.0.0_beta
but this has not gone through test, you could take as reference. We have some
new code
On Mon, 22 Oct 2018, Julien Grall wrote:
> Hi,
>
> On 09/10/2018 00:37, Stefano Stabellini wrote:
> > reserved-memory regions should be mapped as normal memory.
>
> This is already the case with p2m_mmio_direct_c. The hardware domain should
> have full control on the resulting attributes via its
This run is configured for baseline tests only.
flight 75576 ovmf real [real]
http://osstest.xensource.com/osstest/logs/75576/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-i386-xl-qemuu-ovmf-amd64 10 debian-hvm-install fail like 75574
On Tue, 9 Oct 2018, Jan Beulich wrote:
> >>> On 09.10.18 at 01:37, wrote:
> > --- a/xen/include/xsm/dummy.h
> > +++ b/xen/include/xsm/dummy.h
> > @@ -535,6 +535,20 @@ static XSM_INLINE int
> > xsm_map_gmfn_foreign(XSM_DEFAULT_ARG struct domain *d, str
> > return xsm_default_action(action,
branch xen-unstable
xenbranch xen-unstable
job test-amd64-amd64-qemuu-nested-intel
testid debian-hvm-install/l1/l2
Tree: linux
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git
Tree: linuxfirmware git://xenbits.xen.org/osstest/linux-firmware.git
Tree: qemu
Introduce a macro, SYMBOL, which is a simple wrapper around RELOC_HIDE
to be used everywhere symbols such as _stext and _etext are used in the
code.
RELOC_HIDE is needed when accessing symbols such as _stext and _etext
because the C standard forbids for both comparisons and substraction
(see C
Initialize variable target before passing it as a parameter.
It makes the code a bit nicer and it is a safety certification
requirement.
M3CM Rule-9.1: The value of an object with automatic storage duration
shall not be read before it has been set
QAVerify: 2972
Signed-off-by: Stefano Stabellini
Hi all,
This short patch series fixes a few issues discovered by the safety
certifications code scanner. The first two patches address simple
variable initializations concerns. The third patch introduces a new
macro that is used throughout the code in patch #4 to access _stext,
_etext pointers
Initialize variable *access before returning it back to the caller.
It makes the code a bit nicer and it is a safety certification
requirement.
M3CM Rule-9.1: The value of an object with automatic storage duration
shall not be read before it has been set
QAVerify: 2962
Signed-off-by: Stefano
Use SYMBOL everywhere _stext, _etext, etc. are used. Technically, it
is required when comparing and subtracting pointers [1], but use it
everywhere to avoid confusion.
M3CM: Rule-18.2: Subtraction between pointers shall only be applied to
pointers that address elements of the same array
[1]
On Wed, 17 Oct 2018, Julien Grall wrote:
> Hi,
>
> On 17/10/2018 15:31, Stefano Stabellini wrote:
> > Use __symbol everywhere _stext, _etext, etc. are used. Technically, it
> > is only required when comparing pointers, but use it everywhere to avoid
>
> Well no. It is also required when
On Thu, 25 Oct 2018, Jan Beulich wrote:
> >>> On 15.10.18 at 11:56, wrote:
> > Use __symbol everywhere _stext, _etext, etc. are used. Technically, it
> > is only required when comparing pointers, but use it everywhere to avoid
> > confusion.
>
> While the description slightly limits the scope,
On Wed, Nov 7, 2018 at 12:16 AM Rishi <2rushike...@gmail.com> wrote:
>
>
> On Tue, Nov 6, 2018 at 10:41 PM Rishi <2rushike...@gmail.com> wrote:
>
>>
>>
>> On Tue, Nov 6, 2018 at 5:47 PM Wei Liu wrote:
>>
>>> On Tue, Nov 06, 2018 at 03:31:31PM +0530, Rishi wrote:
>>> >
>>> > So after knowing the
Hi - just some cosmetic suggestions.
Subject s/Swich/Switch/
> diff --git a/xen/arch/x86/pv/emul-priv-op.c b/xen/arch/x86/pv/emul-priv-op.c
> index f73ea4a163..a529ebcc3f 100644
> --- a/xen/arch/x86/pv/emul-priv-op.c
> +++ b/xen/arch/x86/pv/emul-priv-op.c
> @@ -760,12 +760,12 @@ static int
flight 129519 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/129519/
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
branch xen-unstable
xenbranch xen-unstable
job test-amd64-i386-qemuu-rhel6hvm-intel
testid xen-boot
Tree: linux git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git
Tree: linuxfirmware git://xenbits.xen.org/osstest/linux-firmware.git
Tree: qemu
From: Benjamin Sanda
get_pg_owner() and put_pg_owner() will be necessary in a follow-up
commit to support xentrace on Arm. So move the helper to common code.
Note that put_pg_owner() has been turned to a macro rather than static
inline because of inter-dependency between includes.
For auto-translated domain, the only way to map page to itself is the
using foreign map API. The current code does not allow mapping page from
special page (such as DOMID_XEN).
As xentrace buffer are shared using DOMID_XEN, it is not possible to use
tracing for Arm.
This could be solved by using
No functional change intended.
Only reasonable clean-ups are done in this patch. The rest will use _gfn
for the time being.
Signed-off-by: Julien Grall
---
xen/arch/arm/guestcopy.c | 2 +-
xen/arch/arm/mm.c| 2 +-
xen/arch/x86/cpu/vpmu.c | 2 +-
Current, foreign mappings can only be read-write. A follow-up patch will
extend foreign mapping for Xen backend memory (via XEN_DOMID), some of
that memory should only be read accessible for the mapping domain.
Introduce a new p2m_type to cater read-only foreign mappings. For now,
the decision
From: Benjamin Sanda
Modified to provide building of the xenalyze binary for both ARM and
x86 platforms. The xenalyze binary is now built as part of the BIN
list for both platforms.
Signed-off-by: Benjamin Sanda
Signed-off-by: Julien Grall
---
tools/xentrace/Makefile | 3 +--
1 file changed,
In a follow-up patches, we will need to handle get_page_from_gfn
differently for DOMID_XEN. To keep the code simple move the current
content in a new separate helper p2m_get_page_from_gfn.
Note the new helper is a not anymore a static inline function as the helper
is quite complex.
Finally, take
A follow-up patch will introduce another type of foreign mapping. Rename
the type to make clear it is only used for read-write mapping.
No functional changes intended.
Signed-off-by: Julien Grall
---
xen/arch/arm/mm.c | 2 +-
xen/arch/arm/p2m.c| 2 +-
xen/include/asm-arm/p2m.h
Hi all,
This patch series is a rework of the series sent by Benjamin Sanda in April
2016 [1]. It finally adds support for xentrace/xenanalyze on Arm.
Cheers,
[1] https://lists.xenproject.org/archives/html/xen-devel/2016-04/msg00464.html
Benjamin Sanda (3):
xen/page_alloc: Move
From: Benjamin Sanda
Now that we allow a privileged domain to map tracing buffer, initialize
them so a user can effectively trace Xen.
Signed-off-by: Benjamin Sanda
[julien: rework commit message]
Signed-off-by: Julien Grall
---
xen/arch/arm/setup.c | 3 +++
1 file changed, 3 insertions(+)
Hi,
I am CCing Peng Fan who is working for NXP and also on Xen. Peng, do you have
any pointer to getting Xen running on iMX8QM?
Cheers,
On 06/11/2018 18:59, Stefano Stabellini wrote:
Hi Ravi,
Please have a look at our wiki as a reference:
Hi Ravi,
Please have a look at our wiki as a reference:
http://wiki.xenproject.org/wiki/Xen_ARM_with_Virtualization_Extensions
I would start from cross-compiling the Xen hypervisor (the xen/
directory), no need to build the Xen userspace tools initially.
Make sure to have the right early boot
On Tue, Nov 6, 2018 at 10:41 PM Rishi <2rushike...@gmail.com> wrote:
>
>
> On Tue, Nov 6, 2018 at 5:47 PM Wei Liu wrote:
>
>> On Tue, Nov 06, 2018 at 03:31:31PM +0530, Rishi wrote:
>> >
>> > So after knowing the stack trace, it appears that the CPU was getting
>> stuck
>> > for
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Xen Security Advisory XSA-282
guest use of HLE constructs may lock up host
ISSUE DESCRIPTION
=
Various Intel CPU models have an erratum listed under the title
"Processor May Hang When Executing
On Tue, 6 Nov 2018, Julien Grall wrote:
> On 06/11/2018 17:43, Stefano Stabellini wrote:
> > On Mon, 5 Nov 2018, Julien Grall wrote:
> > > Hi Stefano,
> > >
> > > On 11/5/18 9:35 PM, Stefano Stabellini wrote:
> > > > On Mon, 8 Oct 2018, Julien Grall wrote:
> > > > > At the moment, the
On 06/11/2018 17:43, Stefano Stabellini wrote:
On Mon, 5 Nov 2018, Julien Grall wrote:
Hi Stefano,
On 11/5/18 9:35 PM, Stefano Stabellini wrote:
On Mon, 8 Oct 2018, Julien Grall wrote:
At the moment, the implementation of Set/Way operations will go through
all the entries of the guest P2M
On Tue, 6 Nov 2018, Julien Grall wrote:
> Hi Stefano,
>
> On 06/11/2018 17:36, Stefano Stabellini wrote:
> > On Mon, 5 Nov 2018, Julien Grall wrote:
> > > Hi Stefano,
> > >
> > > On 11/5/18 7:47 PM, Stefano Stabellini wrote:
> > > > On Mon, 8 Oct 2018, Julien Grall wrote:
> > > > > A follow-up
Hi Stefano,
On 06/11/2018 17:36, Stefano Stabellini wrote:
On Mon, 5 Nov 2018, Julien Grall wrote:
Hi Stefano,
On 11/5/18 7:47 PM, Stefano Stabellini wrote:
On Mon, 8 Oct 2018, Julien Grall wrote:
A follow-up patch will require to emulate some accesses to some
co-processors registers
On Mon, 5 Nov 2018, Julien Grall wrote:
> Hi Stefano,
>
> On 11/5/18 9:35 PM, Stefano Stabellini wrote:
> > On Mon, 8 Oct 2018, 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
On Tue, 6 Nov 2018, Julien Grall wrote:
> Hi Stefano,
>
> On 06/11/2018 17:31, Stefano Stabellini wrote:
> > On Mon, 5 Nov 2018, Julien Grall wrote:
> > > > This will affect all the registers trapped with TVM. Shouldn't we only
> > > > call p2m_toggle_cache when relevant? i.e. when changing
On Mon, 5 Nov 2018, Julien Grall wrote:
> Hi Stefano,
>
> On 11/5/18 7:47 PM, Stefano Stabellini wrote:
> > On Mon, 8 Oct 2018, Julien Grall wrote:
> > > A follow-up patch will require to emulate some accesses to some
> > > co-processors registers trapped by HCR_EL2.TVM. When set, all NS EL1
> >
Hi Stefano,
On 06/11/2018 17:31, Stefano Stabellini wrote:
On Mon, 5 Nov 2018, Julien Grall wrote:
This will affect all the registers trapped with TVM. Shouldn't we only
call p2m_toggle_cache when relevant? i.e. when changing SCTLR?
I think it would be better to only modify the SCTLR emulation
On Mon, 5 Nov 2018, Julien Grall wrote:
> > > +void p2m_set_way_flush(struct vcpu *v)
> > > +{
> > > +/* This function can only work with the current vCPU. */
> > > +ASSERT(v == current);
> >
> > NIT: if it can only operate on current, it makes sense to remove the
> > struct vcpu*
flight 129512 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/129512/
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
On Mon, Nov 5, 2018 at 2:54 AM Alexandru Stefan ISAILA
wrote:
>
> This patch adds a couple of regs to the vm_event that are used by
> the introspection. The base, limit and ar
> bits are compressed into a uint64_t union so as not to enlarge the
> vm_event.
>
> Signed-off-by: Alexandru Isaila
On Tue, 6 Nov 2018, Peng Fan wrote:
> Hi Julien,
>
> > -Original Message-
> > From: Xen-devel [mailto:xen-devel-boun...@lists.xenproject.org] On Behalf Of
> > Peng Fan
> > Sent: 2018年11月5日 10:11
> > To: Julien Grall ; xen-devel@lists.xenproject.org;
> > Stefano Stabellini
> > Subject:
On Tue, Nov 6, 2018 at 5:47 PM Wei Liu wrote:
> On Tue, Nov 06, 2018 at 03:31:31PM +0530, Rishi wrote:
> >
> > So after knowing the stack trace, it appears that the CPU was getting
> stuck
> > for xen_hypercall_xen_version
>
> That hypercall is used when a PV kernel (re-)enables interrupts. See
>>> On 02.11.18 at 18:59, wrote:
> It’s time again for the x86 community call: for the agenda see
> https://docs.google.com/document/d/1RxW-iwcFFuKzNjjEqLEtiwFVHgAUlk35c0EtTkRE1
> k4/edit#
>
> Please propose new agenda items by next Friday (feel free to just add them
> to the document or
On 10/05/2018 11:14 AM, Jan Beulich wrote:
> The header is (hence its name) supposed to be a helper for the per-arch
> p2m.h files. It was never supposed to be included directly, and for the
> purpose of putting common function declarations into the common header
> it is more helpful if things
>>> On 05.10.18 at 12:14, wrote:
> The header is (hence its name) supposed to be a helper for the per-arch
> p2m.h files. It was never supposed to be included directly, and for the
> purpose of putting common function declarations into the common header
> it is more helpful if things like p2m_t
>>> On 05.10.18 at 12:21, wrote:
>> -Original Message-
>> From: Jan Beulich [mailto:jbeul...@suse.com]
>> Sent: 05 October 2018 11:14
>> To: xen-devel
>> Cc: Julien Grall ; Andrew Cooper
>> ; Paul Durrant ; Wei
>> Liu ; George Dunlap ; Ian
>> Jackson ; Stefano Stabellini
>> ; Konrad
On Mon, Nov 05, 2018 at 11:21:03AM +, Andrew Cooper wrote:
> This will shortly be wanted by the userspace emulator harnesses as well.
>
> Consolidate the cpuid{,_count}_leaf() helpers beside the structure definition,
> rather than having them scattered throughout Xen.
>
> Signed-off-by:
>>> On 06.11.18 at 16:52, wrote:
> On 06/11/18 15:38, Jan Beulich wrote:
> On 05.11.18 at 12:21, wrote:
>>> They are identical, so provide a single x86emul_cpuid() instead.
>>>
>>> As x86_emulate() now only uses the ->cpuid() hook for real CPUID
> instructions,
>>> the hook can be omitted
Marek Marczykowski-Górecki writes ("Re: [PATCH 8/8] tools/libvchan:
libxenvchan_client_init: use ENOENT for no server"):
> On Tue, Nov 06, 2018 at 11:45:47AM +, Ian Jackson wrote:
> > Right. Marek, this series was intended to help with vchan for qmp.
> > But obviously I don't want to break
On 06/11/18 15:38, Jan Beulich wrote:
On 05.11.18 at 12:21, wrote:
>> They are identical, so provide a single x86emul_cpuid() instead.
>>
>> As x86_emulate() now only uses the ->cpuid() hook for real CPUID
>> instructions,
>> the hook can be omitted from all special-purpose emulation ops.
>
>>> On 02.10.18 at 12:38, wrote:
> On 02/10/2018 11:18, Jan Beulich wrote:
>> ARM is intended to gain support for heterogeneous IOMMUs on a single
>> system. This not only disallows boot time replacement of respective
>> indirect calls (handling of which is the main goal of the introduction
>>
>>> On 05.11.18 at 12:21, wrote:
> They are identical, so provide a single x86emul_cpuid() instead.
>
> As x86_emulate() now only uses the ->cpuid() hook for real CPUID instructions,
> the hook can be omitted from all special-purpose emulation ops.
So I was expecting the hook to go away
flight 129453 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/129453/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-armhf-armhf-xl-arndale broken
test-armhf-armhf-xl-arndale 4
>>> On 05.11.18 at 12:21, wrote:
> For a release build of xen, this removes almost 4k of code volume, and removes
> a function pointer call from every instantiation.
>
> add/remove: 0/1 grow/shrink: 0/3 up/down: 0/-3877 (-3877)
> Function old new
>>> On 05.11.18 at 12:21, wrote:
> This will be used to simplify feature checking.
>
> Signed-off-by: Andrew Cooper
Reviewed-by: Jan Beulich
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
>>> On 05.11.18 at 12:21, wrote:
> +#define cache_line_size() (cp.basic.clflush_size * 8)
While the parentheses are indeed needed here, ...
> +#define cpu_has_mmx (cp.basic.mmx)
... they could be omitted here. I'd prefer if they were dropped,
but whichever way you decide to do
Acked-by:
On 11/6/18 7:07 AM, Sergey Dyasli wrote:
> As a convenient helper function and refactor the code to use it.
>
> No functional change.
>
> Signed-off-by: Sergey Dyasli
> ---
> CC: Boris Ostrovsky
> CC: Suravee Suthikulpanit
> CC: Brian Woods
>
> v2:
> - Use the new helper in nestedsvm.c
>>> On 06.11.18 at 15:09, wrote:
> --- a/xen/arch/x86/x86_emulate/x86_emulate.c
> +++ b/xen/arch/x86/x86_emulate/x86_emulate.c
> @@ -4061,6 +4061,12 @@ x86_emulate(
> }
> }
> dst.val &= EFLAGS_MODIFIABLE;
> +
> +/* When IF transitions from 0 to 1, assert the
>>> On 06.11.18 at 15:21, wrote:
> On 06/11/18 13:33, Jan Beulich wrote:
>> 1: skip VIF processing in VME mode for 16-bit POPF at IOPL 3
>> 2: raise #GP(0) in VME mode for POPF with TF set in new value
>
> I'm afraid that I think there is still a bug with PVI emulation.
>
> We only ever read
On 06/11/18 13:33, Jan Beulich wrote:
> 1: skip VIF processing in VME mode for 16-bit POPF at IOPL 3
> 2: raise #GP(0) in VME mode for POPF with TF set in new value
I'm afraid that I think there is still a bug with PVI emulation.
We only ever read cr4 when operating in vm86, which means that the
Hi Stefano,
On 05/11/2018 17:56, Stefano Stabellini wrote:
On Mon, 5 Nov 2018, Julien Grall wrote:
On 02/11/2018 23:27, Stefano Stabellini wrote:
On Mon, 8 Oct 2018, Julien Grall wrote:
Currently a Stage-2 translation fault could happen:
1) MMIO emulation
2) When the page-tables
Signed-off-by: Andrew Cooper
---
CC: Jan Beulich
CC: Wei Liu
---
xen/arch/x86/x86_emulate/x86_emulate.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/xen/arch/x86/x86_emulate/x86_emulate.c
b/xen/arch/x86/x86_emulate/x86_emulate.c
index e69dfdd..e93532d 100644
---
flight 129505 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/129505/
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
Now that there's an almost unconditional CR4 read right at the beginning
of x86_emulate(), centralize its reading there and use result and value
everywhere else without further invoking the hook.
Subsequently we may want to consider having the callers provide
whichever value they deem appropriate
This is a check explicitly listed by the instruction page in the SDM.
Signed-off-by: Jan Beulich
--- a/xen/arch/x86/x86_emulate/x86_emulate.c
+++ b/xen/arch/x86/x86_emulate/x86_emulate.c
@@ -4050,6 +4050,7 @@ x86_emulate(
if ( (cr4 & X86_CR4_VME) &&
At IOPL 3 CR4.VME is irrelevant.
Reported-by: Andrew Cooper
Signed-off-by: Jan Beulich
---
v2: New.
--- a/xen/arch/x86/x86_emulate/x86_emulate.c
+++ b/xen/arch/x86/x86_emulate/x86_emulate.c
@@ -4047,7 +4047,8 @@ x86_emulate(
if ( op_bytes == 2 )
{
dst.val =
>>> On 05.11.18 at 12:21, wrote:
> --- a/xen/include/xen/lib/x86/cpuid.h
> +++ b/xen/include/xen/lib/x86/cpuid.h
> @@ -20,6 +20,21 @@ struct cpuid_leaf
> uint32_t a, b, c, d;
> };
>
> +static inline void cpuid_leaf(uint32_t leaf, struct cpuid_leaf *l)
> +{
> +asm volatile ( "cpuid"
>
1: skip VIF processing in VME mode for 16-bit POPF at IOPL 3
2: raise #GP(0) in VME mode for POPF with TF set in new value
3: consolidate CR4 handling
Jan
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
On Tue, Nov 06, 2018 at 03:31:31PM +0530, Rishi wrote:
>
> So after knowing the stack trace, it appears that the CPU was getting stuck
> for xen_hypercall_xen_version
That hypercall is used when a PV kernel (re-)enables interrupts. See
xen_irq_enable. The purpose is to force the kernel to switch
On 11/06/2018 09:08 AM, Paul Durrant wrote:
>> -Original Message-
>> From: Xen-devel [mailto:xen-devel-boun...@lists.xenproject.org] On Behalf
>> Of George Dunlap
>> Sent: 05 November 2018 18:07
>> To: xen-devel@lists.xenproject.org
>> Cc: Stefano Stabellini ; Wei Liu
>> ; Konrad Wilk ;
On Tue, Nov 06, 2018 at 11:45:47AM +, Ian Jackson wrote:
> Wei Liu writes ("Re: [PATCH 8/8] tools/libvchan: libxenvchan_client_init: use
> ENOENT for no server"):
> > On Fri, Nov 02, 2018 at 05:01:13PM +, Ian Jackson wrote:
> > > * Promise that we will set errno to ENOENT if the server is
The size of Xen's virtual vmcs region is 4096 bytes (see comment about
Virtual VMCS layout in include/asm-x86/hvm/vmx/vvmx.h). Correctly report
it to the guest in case when VMCS shadowing is not available instead of
providing H/W value (which is usually smaller).
Signed-off-by: Sergey Dyasli
---
As a convenient helper function and refactor the code to use it.
No functional change.
Signed-off-by: Sergey Dyasli
---
CC: Boris Ostrovsky
CC: Suravee Suthikulpanit
CC: Brian Woods
v2:
- Use the new helper in nestedsvm.c
---
xen/arch/x86/hvm/svm/nestedsvm.c| 2 +-
And make nvmx_handle_vmptrld() return the new errno in case the provided
address is the same as vmxon region address.
While at it, correct the return value for not-4KB-aligned case.
Signed-off-by: Sergey Dyasli
Acked-by: Kevin Tian
---
v2:
- Added Acked-by
---
xen/arch/x86/hvm/vmx/vvmx.c
These were found by running nested VMX tests from kvm-unit-tests.
Sergey Dyasli (8):
x86/vvmx: introduce nvmx_vcpu_preinit()
x86/nestedhvm: introduce vvmcx_valid()
x86/vvmx: add VMX_INSN_INVEPT_INVVPID_INVALID_OP errno
x86/vvmx: correct vmfail() usage for vmptrld and vmclear
x86/vvmx:
Currently Xen tries to map bitmaps during emulation of vmptrld and
vmwrite. This is wrong: a guest can store arbitrary values in those
fields.
Make bitmaps mapping happen only during a nested vmentry and only if
the appropriate execution controls are turned on by L1 hypervisor.
For performance
Calling vmfail_valid() is correct only if vvmcx is valid. Modify
functions to use vmfail() instead which performs the necessary check.
While at it, add ASSERTs into vmfail_valid/invalid() to quickly catch
an incorrect usage in the future.
Signed-off-by: Sergey Dyasli
---
v2:
- Added ASSERTs
---
And call it during vmx_vcpu_initialise(). This allows to safely use
vvmx functions that rely on the values inside struct nestedvmx and
struct nestedvcpu, independently of the nested virtualisation
(HVM_PARAM_NESTEDHVM) status of a domain.
Signed-off-by: Sergey Dyasli
---
v2:
- new patch
---
And use it in nvmx_handle_invept() and nvmx_handle_invvpid().
Signed-off-by: Sergey Dyasli
---
v2:
- new patch
---
xen/arch/x86/hvm/vmx/vvmx.c| 4 ++--
xen/include/asm-x86/hvm/vmx/vmcs.h | 1 +
2 files changed, 3 insertions(+), 2 deletions(-)
diff --git a/xen/arch/x86/hvm/vmx/vvmx.c
1. Add VMX_INSN_VMCLEAR_WITH_VMXON_PTR errno and add the appropriate
check to the function.
2. Correct the return value for not-4KB-aligned case and for invalid
physaddr (when hvm_map_guest_frame_rw() fails).
3. Remove enum vmx_ops_result and use vmfail/vmsucceed() calls directly.
flight 75575 distros-debian-snapshot real [real]
http://osstest.xensource.com/osstest/logs/75575/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-amd64-daily-netboot-pygrub broken
George Dunlap writes ("[PATCH v4 5/6] tools/dm_depriv: Add first cut RLIMITs"):
> Limit the ability of a potentially compromised QEMU to consume system
> resources. Key limits:
> - RLIMIT_FSIZE (file size): 256KiB
> - RLIMIT_NPROC (after uid changes to a unique uid)
...
> Suggested-by: Ross
George Dunlap writes ("[PATCH v4 2/6] SUPPORT.md: Add qemu-depriv section"):
> Signed-off-by: George Dunlap
Acked-by: Ian Jackson
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
George Dunlap writes ("[PATCH v4 1/6] docs/qemu-deprivilege: Revise and update
with status and future plans"):
> docs/qemu-deprivilege.txt had some basic instructions for using
> dm_restrict, but it was incomplete, misleading, and stale.
Acked-by: Ian Jackson
(Assuming you fix the commit
Wei Liu writes ("Re: [PATCH 8/8] tools/libvchan: libxenvchan_client_init: use
ENOENT for no server"):
> On Fri, Nov 02, 2018 at 05:01:13PM +, Ian Jackson wrote:
> > * Promise that we will set errno to ENOENT if the server is not
> > yet set up.
> > * Arrange that all ENOENT returns other
Wei Liu writes ("Re: [PATCH 4/8] tools/libvchan: init_xs_srv: Simplify error
handling (2)"):
> On Fri, Nov 02, 2018 at 05:01:09PM +, Ian Jackson wrote:
> > * Abolish fail_xs_open which is now exactly the same as fail.
> > * Change all gotos to refer to fail instead.
> > No functional change.
> -Original Message-
> From: Anthony PERARD [mailto:anthony.per...@citrix.com]
> Sent: 06 November 2018 11:11
> To: Paul Durrant
> Cc: George Dunlap ; xen-
> de...@lists.xenproject.org; Ian Jackson ; Wei Liu
>
> Subject: Re: [Xen-devel] [PATCH v4 3/6] tools/dm_restrict: Ask QEMU to
>
On Tue, Nov 06, 2018 at 10:53:48AM +, Paul Durrant wrote:
> Ok. The trace backend is set at build time in tools/Makefile:
>
> if $$source/scripts/tracetool.py --check-backend --backend log ; then
> \
> enable_trace_backend='--enable-trace-backend=log';
> elif
On Tue, Nov 06, 2018 at 09:07:12AM +, Paul Durrant wrote:
> > +## Migration
> > +
> > +When calling xen-save-devices-state, since QEMU is running in a chroot
> > +it is not useful to pass a filename (it doesn't even have write access
> > +inside the chroot). Instead, give it an open fd using
> -Original Message-
> From: George Dunlap [mailto:george.dun...@citrix.com]
> Sent: 06 November 2018 10:28
> To: Paul Durrant ; xen-devel@lists.xenproject.org
> Cc: Anthony Perard ; Ian Jackson
> ; Wei Liu
> Subject: Re: [Xen-devel] [PATCH v4 3/6] tools/dm_restrict: Ask QEMU to
> chroot
On Mon, Nov 05, 2018 at 04:17:56PM +0200, Alexandru Vasile wrote:
> On Mon, Nov 05, 2018 at 12:57 PM, Wei Liu wrote:
> > On Mon, Nov 05, 2018 at 11:58:09AM +0200, Alexandru Vasile wrote:
> > > Hello,
> > > (XEN) event_channel.c:319:d0v1 EVTCHNOP failure: domain 1, error -22
> > > (XEN)
On Tue, Nov 06, 2018 at 11:23:39AM +0100, Paolo Bonzini wrote:
> On 05/11/2018 02:40, Samuel Ortiz wrote:
> > /* RSDP */
> > -static GArray *
> > +static void
> > build_rsdp(GArray *rsdp_table, BIOSLinker *linker, unsigned
> > xsdt_tbl_offset)
> > {
> > AcpiRsdpDescriptor *rsdp =
On 11/06/2018 09:34 AM, Paul Durrant wrote:
>> +# Example input:
>> +# Uid: 1193119311931193
>> +input=$(grep ^Uid: /proc/$dmpid/status)
>> +if [[ "$input" =~ ^Uid:[[:space:]]+([0-9]+)[[:space:]]+([0-
>> 9]+)[[:space:]]+([0-9]+)[[:space:]]+([0-9]+)$ ]] ; then
>> +
On 11/06/2018 09:22 AM, Paul Durrant wrote:
>> -Original Message-
>> From: Xen-devel [mailto:xen-devel-boun...@lists.xenproject.org] On Behalf
>> Of George Dunlap
>> Sent: 05 November 2018 18:07
>> To: xen-devel@lists.xenproject.org
>> Cc: Anthony Perard ; Ian Jackson
>> ; Wei Liu ; George
On Tue, Oct 30, 2018 at 05:10:18PM +, Wei Liu wrote:
> On Fri, Oct 26, 2018 at 12:38:06PM +0200, Juergen Gross wrote:
> > docs/ChangeLog has been updated for Xen 3.3 last time. It seems to be
> > interesting for archaeologists only today.
> >
> > Remove it.
> >
> > Signed-off-by: Juergen
1 - 100 of 131 matches
Mail list logo
