On Thu, 2017-10-12 at 10:34 -0400, Meng Xu wrote:
> On Thu, Oct 12, 2017 at 5:02 AM, Wei Liu wrote:
> >
> > FYI all patches except the xentrace one were committed yesterday.
>
> Thank you very much, Wei!
>
Hey Meng,
Any update on that missing patch, though?
IIRC you said you'd look into it. T
On Tue, 2017-10-17 at 09:26 +0200, Dario Faggioli wrote:
> On Thu, 2017-10-12 at 10:34 -0400, Meng Xu wrote:
> > On Thu, Oct 12, 2017 at 5:02 AM, Wei Liu
> > wrote:
> > >
> > > FYI all patches except the xentrace one were committed yesterday.
> >
> > Thank you very much, Wei!
> >
>
> Hey Meng,
On Wed, 2017-10-11 at 14:02 -0400, Meng Xu wrote:
> Change repl_budget event output for xentrace formats and xenalyze
>
> Signed-off-by: Meng Xu
>
I'd say:
Reviewed-by: Dario Faggioli
However...
> diff --git a/tools/xentrace/xenalyze.c b/tools/xentrace/xenalyze.c
> index 79bdba7..19e050f 100
> -Original Message-
> From: Jan Beulich [mailto:jbeul...@suse.com]
> Sent: 17 October 2017 07:43
> To: Paul Durrant
> Cc: Andrew Cooper ; Wei Liu
> ; George Dunlap ; Ian
> Jackson ; sstabell...@kernel.org; xen-
> de...@lists.xenproject.org; konrad.w...@oracle.com; Tim (Xen.org)
>
> Subje
On 10/16/2017 11:55 AM, Ian Jackson wrote:
Ross Lagerwall writes ("[PATCH v2 2/2] xentoolcore_restrict_all: Implement for
libxenevtchn"):
Signed-off-by: Ross Lagerwall
...
int osdep_evtchn_open(xenevtchn_handle *xce);
diff --git a/tools/libs/toolcore/include/xentoolcore.h
b/tools/libs/too
>>> On 17.10.17 at 10:30, wrote:
>> From: Jan Beulich [mailto:jbeul...@suse.com]
>> Sent: 17 October 2017 07:43
>> >>> Paul Durrant 10/12/17 6:28 PM >>>
>> >+int gnttab_get_grant_frame(struct domain *d, unsigned long idx,
>> >+ mfn_t *mfn)
>> >+{
>> >+struct grant_ta
> -Original Message-
> From: Jan Beulich [mailto:jbeul...@suse.com]
> Sent: 17 October 2017 10:06
> To: Paul Durrant
> Cc: Andrew Cooper ; George Dunlap
> ; Ian Jackson ; Wei Liu
> ; sstabell...@kernel.org; xen-
> de...@lists.xenproject.org; konrad.w...@oracle.com; Tim (Xen.org)
>
> Subje
Hi Bhupinder,
first thing: As the bulk of the series has been merged now, please
restart your patch and version numbering, so a (potential) next post
should be prefixed [PATCH v3 1/2]. And please have a cover letter giving
a brief overview what this series fixes.
On 13/10/17 11:40, Bhupinder Thak
fetch_type_names usage is guarded by SHADOW_DEBUG_PROPAGATE in
SHADOW_DEBUG, fix the declaration so it's also guarded by
SHADOW_DEBUG_PROPAGATE instead of DEBUG_TRACE_DUMP.
Signed-off-by: Roger Pau Monné
---
Cc: Tim Deegan
Cc: George Dunlap
Cc: Jan Beulich
Cc: Andrew Cooper
Cc: Julien Grall
Fix Julien Grall address, sorry.
On Tue, Oct 17, 2017 at 11:23:53AM +0100, Roger Pau Monne wrote:
> fetch_type_names usage is guarded by SHADOW_DEBUG_PROPAGATE in
> SHADOW_DEBUG, fix the declaration so it's also guarded by
> SHADOW_DEBUG_PROPAGATE instead of DEBUG_TRACE_DUMP.
>
> Signed-off-by: R
On 17/10/17 11:23, Roger Pau Monne wrote:
> fetch_type_names usage is guarded by SHADOW_DEBUG_PROPAGATE in
> SHADOW_DEBUG, fix the declaration so it's also guarded by
> SHADOW_DEBUG_PROPAGATE instead of DEBUG_TRACE_DUMP.
>
> Signed-off-by: Roger Pau Monné
Possibly worth noting that this is expose
On 16/10/17 17:21, Jan Beulich wrote:
On 16.10.17 at 18:07, wrote:
>> On 16/10/17 16:41, Jan Beulich wrote:
>>> >>> On 16.10.17 at 16:38, wrote:
--- a/xen/arch/x86/hvm/dom0_build.c
+++ b/xen/arch/x86/hvm/dom0_build.c
@@ -614,6 +614,7 @@ static int __init pvh_setup_cpus(struct
>>> On 17.10.17 at 12:38, wrote:
> On 16/10/17 17:21, Jan Beulich wrote:
> On 16.10.17 at 18:07, wrote:
>>> On 16/10/17 16:41, Jan Beulich wrote:
>>> On 16.10.17 at 16:38, wrote:
> --- a/xen/arch/x86/hvm/dom0_build.c
> +++ b/xen/arch/x86/hvm/dom0_build.c
> @@ -614,6 +614,7
On Tue, Oct 17, 2017 at 11:29:14AM +0100, Andrew Cooper wrote:
> On 17/10/17 11:23, Roger Pau Monne wrote:
> > fetch_type_names usage is guarded by SHADOW_DEBUG_PROPAGATE in
> > SHADOW_DEBUG, fix the declaration so it's also guarded by
> > SHADOW_DEBUG_PROPAGATE instead of DEBUG_TRACE_DUMP.
> >
> >
On Mon, Oct 16, 2017 at 03:38:03PM +0100, Andrew Cooper wrote:
> * x86 PV and ARM dom0's must not clear _VPF_down from v->pause_flags until
>all state is actually set up. As it currently stands, d0v0 is eligible for
>scheduling before its registers have been set. This is latent as we als
On some operating systems, the default umask is not 002 as it should
be (for the sensible setup with personal groups).
If a user with an 022 or 077 umask invokes osstest in Executive mode,
they end up creating directories in $c{Logs} which are writeable only
by them, and that can stop the whole sy
On Tue, Oct 17, 2017 at 10:51:07AM +0100, Andre Przywara wrote:
> Hi Bhupinder,
>
> first thing: As the bulk of the series has been merged now, please
> restart your patch and version numbering, so a (potential) next post
> should be prefixed [PATCH v3 1/2]. And please have a cover letter giving
>
Currently there are many offenders of the unaligned access checks,
which makes booting with the unaligned check a PVH Dom0 impossible.
The main offenders seem to be the ACPI code, the VMX code and
specially the intremap code (set_ire_sid).
Signed-off-by: Roger Pau Monné
---
Cc: Andrew Cooper
Cc
clang 5.0 changed the layout of the type_mismatch_data structure and
introduced __ubsan_handle_type_mismatch_v1 and
__ubsan_handle_pointer_overflow.
This commit adds support for the new structure layout, adds the
missing handlers and the new types for type_check_kinds.
Signed-off-by: Roger Pau Mo
On 14/10/2017 00:46, Stefano Stabellini wrote:
> On Fri, 13 Oct 2017, Jan Beulich wrote:
> On 13.10.17 at 13:13, wrote:
>>> To Jan, Andrew, Stefano and Anthony,
>>>
>>> what do you think about allowing QEMU to build the entire guest ACPI
>>> and letting SeaBIOS to load it? ACPI builder code in
ubsan in clang 5.0 complains with:
(XEN) UBSAN: Undefined behaviour in string.c:50:28
(XEN) pointer overflow:
(XEN) addition of unsigned offset to 8310 overflowed to
830f
[...]
(XEN) Xen call trace:
(XEN)[] ubsan.c#ubsan_epilogue+0xd/0xc0
(XEN)[] __ubsan_handle_poi
On 10/17/17 13:45 +0200, Paolo Bonzini wrote:
> On 14/10/2017 00:46, Stefano Stabellini wrote:
> > On Fri, 13 Oct 2017, Jan Beulich wrote:
> > On 13.10.17 at 13:13, wrote:
> >>> To Jan, Andrew, Stefano and Anthony,
> >>>
> >>> what do you think about allowing QEMU to build the entire guest ACP
>>> On 17.10.17 at 14:03, wrote:
> --- a/xen/arch/x86/string.c
> +++ b/xen/arch/x86/string.c
> @@ -39,6 +39,9 @@ void *(memmove)(void *dest, const void *src, size_t n)
> {
> long d0, d1, d2;
>
> +if ( !n )
> +return;
memmove() hopefully isn't on any really hot path, so the ext
> -Original Message-
>
> > --- a/xen/include/xsm/dummy.h
> > +++ b/xen/include/xsm/dummy.h
> > @@ -724,3 +724,9 @@ static XSM_INLINE int xsm_xen_version
> (XSM_DEFAULT_ARG uint32_t op)
> > return xsm_default_action(XSM_PRIV, current->domain, NULL);
> > }
> > }
> > +
> > +sta
On 17/10/17 13:03, Roger Pau Monne wrote:
> ubsan in clang 5.0 complains with:
>
> (XEN) UBSAN: Undefined behaviour in string.c:50:28
> (XEN) pointer overflow:
> (XEN) addition of unsigned offset to 8310 overflowed to
> 830f
> [...]
> (XEN) Xen call trace:
> (XEN)[] ubs
>>> On 17.10.17 at 13:36, wrote:
> clang 5.0 changed the layout of the type_mismatch_data structure and
> introduced __ubsan_handle_type_mismatch_v1 and
> __ubsan_handle_pointer_overflow.
>
> This commit adds support for the new structure layout, adds the
> missing handlers and the new types for
Hello,
We are seeing some build issues since XSA 240 was released, since I
didn't know if it was related to our build job I've isolated everything
so anybody could recreate the test.
We use Xen 4.8.2 and build it on debian 9 (9.1 to be exact) and since
XSA 240 we have xen crashing on some serv
>>> On 17.10.17 at 13:36, wrote:
> --- a/xen/Rules.mk
> +++ b/xen/Rules.mk
> @@ -120,7 +120,7 @@ $(filter-out %.init.o $(nogcov-y),$(obj-y) $(obj-bin-y)
> $(extra-y)): CFLAGS += -
> endif
>
> ifeq ($(CONFIG_UBSAN),y)
> -$(filter-out %.init.o $(noubsan-y),$(obj-y) $(obj-bin-y) $(extra-y)): CFL
>>> On 17.10.17 at 14:28, wrote:
>> -Original Message-
>>
>> > --- a/xen/include/xsm/dummy.h
>> > +++ b/xen/include/xsm/dummy.h
>> > @@ -724,3 +724,9 @@ static XSM_INLINE int xsm_xen_version
>> (XSM_DEFAULT_ARG uint32_t op)
>> > return xsm_default_action(XSM_PRIV, current->domai
> -Original Message-
> From: Jan Beulich [mailto:jbeul...@suse.com]
> Sent: 17 October 2017 13:53
> To: Paul Durrant
> Cc: Andrew Cooper ; George Dunlap
> ; Ian Jackson ; Wei Liu
> ; Stefano Stabellini ; xen-
> de...@lists.xenproject.org; KonradRzeszutek Wilk
> ; Daniel de Graaf ; Tim
> (X
On Tue, Oct 17, 2017 at 01:41:35PM +0100, Andrew Cooper wrote:
> On 17/10/17 13:03, Roger Pau Monne wrote:
> > ubsan in clang 5.0 complains with:
> >
> > (XEN) UBSAN: Undefined behaviour in string.c:50:28
> > (XEN) pointer overflow:
> > (XEN) addition of unsigned offset to 8310 overflow
On Tue, Oct 17, 2017 at 6:19 AM, Dave Martin wrote:
> On Tue, Oct 17, 2017 at 10:51:07AM +0100, Andre Przywara wrote:
>> Hi Bhupinder,
>>
>> first thing: As the bulk of the series has been merged now, please
>> restart your patch and version numbering, so a (potential) next post
>> should be prefi
On Tue, Oct 17, 2017 at 12:36:44PM +0100, Roger Pau Monne wrote:
> Currently there are many offenders of the unaligned access checks,
> which makes booting with the unaligned check a PVH Dom0 impossible.
>
> The main offenders seem to be the ACPI code, the VMX code and
> specially the intremap cod
>>> On 17.10.17 at 14:44, wrote:
> We are seeing some build issues since XSA 240 was released, since I
> didn't know if it was related to our build job I've isolated everything
> so anybody could recreate the test.
> We use Xen 4.8.2 and build it on debian 9 (9.1 to be exact) and since
> XSA 240
On Tue, Oct 17, 2017 at 06:43:28AM -0600, Jan Beulich wrote:
> >>> On 17.10.17 at 13:36, wrote:
> > clang 5.0 changed the layout of the type_mismatch_data structure and
> > introduced __ubsan_handle_type_mismatch_v1 and
> > __ubsan_handle_pointer_overflow.
> >
> > This commit adds support for the
On Tue, Oct 17, 2017 at 01:56:18PM +0100, Wei Liu wrote:
> On Tue, Oct 17, 2017 at 12:36:44PM +0100, Roger Pau Monne wrote:
> > Currently there are many offenders of the unaligned access checks,
> > which makes booting with the unaligned check a PVH Dom0 impossible.
> >
> > The main offenders seem
>>> On 17.10.17 at 14:52, wrote:
> On Tue, Oct 17, 2017 at 01:41:35PM +0100, Andrew Cooper wrote:
>> There are many passed values which could trigger this warning. Does
>>
>> diff --git a/xen/arch/x86/string.c b/xen/arch/x86/string.c
>> index cd85a38..4f55856 100644
>> --- a/xen/arch/x86/string.
On Tue, Oct 17, 2017 at 01:58:47PM +0100, Roger Pau Monné wrote:
> On Tue, Oct 17, 2017 at 01:56:18PM +0100, Wei Liu wrote:
> > On Tue, Oct 17, 2017 at 12:36:44PM +0100, Roger Pau Monne wrote:
> > > Currently there are many offenders of the unaligned access checks,
> > > which makes booting with th
>>> On 17.10.17 at 14:57, wrote:
> On Tue, Oct 17, 2017 at 06:43:28AM -0600, Jan Beulich wrote:
>> >>> On 17.10.17 at 13:36, wrote:
>> > clang 5.0 changed the layout of the type_mismatch_data structure and
>> > introduced __ubsan_handle_type_mismatch_v1 and
>> > __ubsan_handle_pointer_overflow.
>
On Mon, Oct 16, 2017 at 2:18 PM, Boris Ostrovsky
wrote:
> On 10/12/2017 03:53 PM, Boris Ostrovsky wrote:
>> On 10/12/2017 03:27 PM, Andrew Cooper wrote:
>>> On 12/10/17 20:11, Boris Ostrovsky wrote:
There is also another problem:
[1.312425] general protection fault: [#1] SM
Hi Andrew,
On 16/10/17 15:38, Andrew Cooper wrote:
* x86 PV and ARM dom0's must not clear _VPF_down from v->pause_flags until
all state is actually set up. As it currently stands, d0v0 is eligible for
scheduling before its registers have been set. This is latent as we also
hold a
On 17/10/17 13:58, Roger Pau Monné wrote:
> On Tue, Oct 17, 2017 at 01:56:18PM +0100, Wei Liu wrote:
>> On Tue, Oct 17, 2017 at 12:36:44PM +0100, Roger Pau Monne wrote:
>>> Currently there are many offenders of the unaligned access checks,
>>> which makes booting with the unaligned check a PVH Dom0
Hi,
On 17/10/17 11:29, Andrew Cooper wrote:
On 17/10/17 11:23, Roger Pau Monne wrote:
fetch_type_names usage is guarded by SHADOW_DEBUG_PROPAGATE in
SHADOW_DEBUG, fix the declaration so it's also guarded by
SHADOW_DEBUG_PROPAGATE instead of DEBUG_TRACE_DUMP.
Signed-off-by: Roger Pau Monné
P
On Tue, Oct 17, 2017 at 3:29 AM, Dario Faggioli wrote:
> On Tue, 2017-10-17 at 09:26 +0200, Dario Faggioli wrote:
> > On Thu, 2017-10-12 at 10:34 -0400, Meng Xu wrote:
> > > On Thu, Oct 12, 2017 at 5:02 AM, Wei Liu
> > > wrote:
> > > >
> > > > FYI all patches except the xentrace one were committ
On Tue, Oct 17, 2017 at 4:10 AM, Dario Faggioli wrote:
> On Wed, 2017-10-11 at 14:02 -0400, Meng Xu wrote:
>> Change repl_budget event output for xentrace formats and xenalyze
>>
>> Signed-off-by: Meng Xu
>>
> I'd say:
>
> Reviewed-by: Dario Faggioli
>
> However...
>
>> diff --git a/tools/xentra
...to allow the calling domain to prevent translation of specified l1e
value.
Despite what the comment in public/xen.h might imply, specifying a
command value of MMU_NORMAL_PT_UPDATE will not simply update an l1e with
the specified value. Instead, mod_l1_entry() tests whether foreign_dom
has PG_tr
This patch adjusts the ioreq server code to use type-safe gfn_t values
where possible. No functional change.
Signed-off-by: Paul Durrant
Reviewed-by: Roger Pau Monné
Reviewed-by: Wei Liu
Acked-by: Jan Beulich
---
Cc: Andrew Cooper
---
xen/arch/x86/hvm/ioreq.c | 44 +++
... XENMEM_resource_ioreq_server
This patch adds support for a new resource type that can be mapped using
the XENMEM_acquire_resource memory op.
If an emulator makes use of this resource type then, instead of mapping
gfns, the IOREQ server will allocate pages from the heap. These pages
will never
A subsequent patch will introduce a new scheme to allow an emulator to
map ioreq server pages directly from Xen rather than the guest P2M.
This patch lays the groundwork for that change by deferring mapping of
gfns until their values are requested by an emulator. To that end, the
pad field of the
A subsequent patch will remove the current implicit limitation on creation
of ioreq servers which is due to the allocation of gfns for the ioreq
structures and buffered ioreq ring.
It will therefore be necessary to introduce an explicit limit and, since
this limit should be small, it simplifies th
A previous patch introduced a new HYPERVISOR_memory_op to acquire guest
resources for direct priv-mapping.
This patch adds new functionality into libxenforeignmemory to make use
of a new privcmd ioctl [1] that uses the new memory op to make such
resources available via mmap(2).
[1]
http://xenbit
By using a static inline stub in private.h for OS where this functionality
is not implemented, the various duplicate stubs in the OS-specific source
modules can be avoided.
Signed-off-by: Paul Durrant
Reviewed-by: Roger Pau Monné
Acked-by: Wei Liu
---
Cc: Ian Jackson
v4:
- Removed extraneous
Certain memory resources associated with a guest are not necessarily
present in the guest P2M.
This patch adds the boilerplate for new memory op to allow such a resource
to be priv-mapped directly, by either a PV or HVM tools domain.
NOTE: Whilst the new op is not intrinsicly specific to the x86
This series introduces support for direct mapping of guest resources.
The resources are:
- IOREQ server pages
- Grant tables
v12:
- Responded to more comments from Jan.
v11:
- Responded to more comments from Jan.
v10:
- Responded to comments from Jan.
v9:
- Change to patch #1 only.
v8:
This patch re-works much of the ioreq server initialization and teardown
code:
- The hvm_map/unmap_ioreq_gfn() functions are expanded to call through
to hvm_alloc/free_ioreq_gfn() rather than expecting them to be called
separately by outer functions.
- Several functions now test the validity o
flight 114645 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/114645/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-i3866 xen-buildfail REGR. vs. 114507
build-amd64
A previous patch added support for priv-mapping guest resources directly
(rather than having to foreign-map, which requires P2M modification for
HVM guests).
This patch makes use of the new API to seed the guest grant table unless
the underlying infrastructure (i.e. privcmd) doesn't support it, in
This patch allows grant table frames to be mapped using the
XENMEM_acquire_resource memory op.
Signed-off-by: Paul Durrant
---
Cc: Andrew Cooper
Cc: George Dunlap
Cc: Ian Jackson
Cc: Jan Beulich
Cc: Konrad Rzeszutek Wilk
Cc: Stefano Stabellini
Cc: Tim Deegan
Cc: Wei Liu
v12:
- Dropped l
Hi,
On 16/10/17 13:16, Ross Lagerwall wrote:
On 10/16/2017 12:29 PM, Ian Jackson wrote:
Ross Lagerwall writes ("Re: [PATCH v1 1/2] tools/libs/evtchn: Add
support for restricting a handle"):
No. As far as I can see, it can only be used to bind new interdomain
events, not other events.
OK, goo
At 11:23 +0100 on 17 Oct (1508239433), Roger Pau Monne wrote:
> fetch_type_names usage is guarded by SHADOW_DEBUG_PROPAGATE in
> SHADOW_DEBUG, fix the declaration so it's also guarded by
> SHADOW_DEBUG_PROPAGATE instead of DEBUG_TRACE_DUMP.
>
> Signed-off-by: Roger Pau Monné
Acked-by: Tim Deegan
Hi George,
On 13/10/17 10:00, George Dunlap wrote:
Changeset introduced "batch mode" to afl-harness, which allowed
the handling of several inputs in sequence.
Unfortunately, it introduced a file pointer leak when the file was
larger than the maximum size. Restructure the code to always cl
On Tue, Oct 17, 2017 at 07:53:36AM -0500, Rob Herring wrote:
> On Tue, Oct 17, 2017 at 6:19 AM, Dave Martin wrote:
> > On Tue, Oct 17, 2017 at 10:51:07AM +0100, Andre Przywara wrote:
> >> Hi Bhupinder,
> >>
> >> first thing: As the bulk of the series has been merged now, please
> >> restart your p
On 10/17/2017 01:24 AM, Josh Poimboeuf wrote:
> On Mon, Oct 16, 2017 at 02:18:48PM -0400, Boris Ostrovsky wrote:
>> On 10/12/2017 03:53 PM, Boris Ostrovsky wrote:
>>> On 10/12/2017 03:27 PM, Andrew Cooper wrote:
On 12/10/17 20:11, Boris Ostrovsky wrote:
> There is also another problem:
>>>
On Tue, Oct 17, 2017 at 02:44:29PM +0100, Dave Martin wrote:
> arch/arm/kernel/debug.S:
>
> ENTRY(printascii)
> addruart_current r3, r1, r2
> b 2f
> 1: waituart r2, r3
> senduart r1, r3
> busyuart r2, r3
>
On 10/17/2017 09:10 AM, Brian Gerst wrote:
> On Mon, Oct 16, 2017 at 2:18 PM, Boris Ostrovsky
> wrote:
>>
>> Replacing the macro with
>>
>> #define PV_INDIRECT(addr) *addr // well, it's not so much
>> indirect anymore
>>
>> makes things work. Or maybe it can be adjusted top be kept truly in
Discovered when running the XSA-232 PoC on a UBSAN-enabled hypervisor.
(d79) XSA-232 PoC
(XEN)
(XEN) UBSAN: Undefined behaviour in grant_table.c:3217:25
(XEN) left shift of 1 by 31 places cannot be represente
On Tue, Oct 17, 2017 at 03:11:51PM +0100, Andrew Cooper wrote:
> Discovered when running the XSA-232 PoC on a UBSAN-enabled hypervisor.
>
> (d79) XSA-232 PoC
> (XEN)
>
> (XEN) UBSAN: Undefined behaviour in gran
On Tue, 17 Oct 2017 06:57:45 -0600
"Jan Beulich" wrote:
> >>> On 17.10.17 at 14:44, wrote:
> > We are seeing some build issues since XSA 240 was released, since I
> > didn't know if it was related to our build job I've isolated everything
> > so anybody could recreate the test.
> > We use Xen
On Tue, Oct 17, 2017 at 09:58:59AM -0400, Boris Ostrovsky wrote:
> On 10/17/2017 01:24 AM, Josh Poimboeuf wrote:
> > On Mon, Oct 16, 2017 at 02:18:48PM -0400, Boris Ostrovsky wrote:
> >> On 10/12/2017 03:53 PM, Boris Ostrovsky wrote:
> >>> On 10/12/2017 03:27 PM, Andrew Cooper wrote:
> On 12/1
On 10/17/2017 09:24 AM, Paul Durrant wrote:
Certain memory resources associated with a guest are not necessarily
present in the guest P2M.
This patch adds the boilerplate for new memory op to allow such a resource
to be priv-mapped directly, by either a PV or HVM tools domain.
NOTE: Whilst the
On Tue, Oct 17, 2017 at 03:03:02PM +0100, Russell King - ARM Linux wrote:
> On Tue, Oct 17, 2017 at 02:44:29PM +0100, Dave Martin wrote:
> > arch/arm/kernel/debug.S:
> >
> > ENTRY(printascii)
> > addruart_current r3, r1, r2
> > b 2f
> > 1: waituart
Rather than opencoding it in two places. While only used in the PV emulation
code, this helper is in principle usable anywhere in the hypervisor.
No functional change.
Signed-off-by: Andrew Cooper
---
CC: Jan Beulich
CC: Wei Liu
---
xen/arch/x86/pv/emul-gate-op.c | 5 +
xen/arch/x86/pv/
On 10/09/2017 04:57 PM, Ian Jackson wrote:
Signed-off-by: Ian Jackson
Acked-by: Wei Liu
---
v2: Bump library minor version, as this is a new function
---
snip
diff --git a/tools/libs/devicemodel/libxendevicemodel.map
b/tools/libs/devicemodel/libxendevicemodel.map
index 130222c..b0765fa 10064
On 10/03/2017 12:55 PM, Joao Martins wrote:
> Right now there is only a pvclock_pvti_cpu0_va() which is defined
> on kvmclock since:
>
> commit dac16fba6fc5
> ("x86/vdso: Get pvclock data from the vvar VMA instead of the fixmap")
>
> The only user of this interface so far is kvm. This commit adds
On 10/17/2017 10:36 AM, Josh Poimboeuf wrote:
>
> Maybe we can add a new field to the alternatives entry struct which
> specifies the offset to the CALL instruction, so apply_alternatives()
> can find it.
We'd also have to assume that the restore part of an alternative entry
is the same size as th
Ross Lagerwall writes ("Re: [PATCH 03/26] tools: libxendevicemodel: Provide
xendevicemodel_shutdown"):
> On 10/09/2017 04:57 PM, Ian Jackson wrote:
> > Signed-off-by: Ian Jackson
> > Acked-by: Wei Liu
...
> Why did all the symbols get moved to VERS_1.1 rather than adding only
> the new one to V
On Mon, Oct 16, 2017 at 01:00:21PM +0100, Julien Grall wrote:
>
>
> On 11/10/17 20:01, Volodymyr Babchuk wrote:
> >Hello all,
>
> Hi Volodymyr,
Hi Julien
>
> >
> >I want to present TEE mediator, that was discussed earlier ([1]).
> >
> >I selected design with built-in mediators. This is easiest
On 10/06/2017 08:30 PM, Stefano Stabellini wrote:
> Introduce a data structure named pvcalls_bedata. It contains pointers to
> the command ring, the event channel, a list of active sockets and a list
> of passive sockets. Lists accesses are protected by a spin_lock.
>
> Introduce a waitqueue to all
On Mon, Oct 16, 2017 at 02:00:32PM +0100, Julien Grall wrote:
> Hi Volodymyr,
Hi Julien,
[...]
> >This is how it works: user can build XEN with multiple TEE mediators
> >(see the next patches, where OP-TEE mediator is introduced).
> >TEE mediator register self with REGISTER_TEE_MEDIATOR() macro in
On Mon, Oct 16, 2017 at 03:04:44PM +0100, Julien Grall wrote:
> Hi Volodymyr,
Hi Julien,
> On 11/10/17 20:01, Volodymyr Babchuk wrote:
> >This header files describe protocol between OP-TEE and OP-TEE client
> >driver in Linux. They are needed for upcomient OP-TEE mediator, which
> >is added in the
On 17/10/17 17:22, Volodymyr Babchuk wrote:
On Mon, Oct 16, 2017 at 02:00:32PM +0100, Julien Grall wrote:
diff --git a/xen/arch/arm/Kconfig b/xen/arch/arm/Kconfig
index d46b98c..e1f112a 100644
--- a/xen/arch/arm/Kconfig
+++ b/xen/arch/arm/Kconfig
@@ -50,6 +50,14 @@ config HAS_ITS
promp
Hi,
On 17/10/17 17:24, Volodymyr Babchuk wrote:
On Mon, Oct 16, 2017 at 03:04:44PM +0100, Julien Grall wrote:
Hi Volodymyr,
Hi Julien,
On 11/10/17 20:01, Volodymyr Babchuk wrote:
This header files describe protocol between OP-TEE and OP-TEE client
driver in Linux. They are needed for upcomi
Wei Liu writes ("Re: [Xen-devel] [PATCH] ipxe: update to newer commit"):
> Ian is away. I don't know who else has permission to generate and
> upload that tarball. :-)
I have done it now. The permission required is the ability to become
xen@xenbits.
Ian.
___
Currently, ring_ref is read as an integer in console_create_ring which could
lead to
truncation of the value as it is reading a 64-bit value.
The fix is to modify the type of ring_ref to xen_pfn_t and use the correct
format
specifier to read the value correctly for all architectures.
Signed-off
Currently the data type of mfn paramter passed to xc_map_foreign_range() is
unsigned
long. This could be problem for 32-bit arm architectures where the lengh of
long is
32 bits while mfn happens to be a 64-bit value.
To avoid truncating a 64-bit value, the type of mfn is changed from "unsigned
In libxl__device_vuart_add vuart_gfn is getting stored as a hex value:
> flexarray_append(ro_front, GCSPRINTF("%"PRI_xen_pfn, state->vuart_gfn));
However, xenstore reads this value as a decimal value and tries to map the
wrong address and fails.
This patch introduces a new format specifier "PRIu
xenconsole will use a new macro INVALID_XEN_PFN instead of -1 for initializing
ring-ref.
Signed-off-by: Bhupinder Thakur
---
CC: Ian Jackson
CC: Wei Liu
CC: Andrew Cooper
CC: George Dunlap
CC: Jan Beulich
CC: Konrad Rzeszutek Wilk
CC: Stefano Stabellini
CC: Julien Grall
tools/console/d
Signed-off-by: Bhupinder Thakur
---
CC: Ian Jackson
CC: Wei Liu
CC: Stefano Stabellini
CC: Julien Grall
tools/libxl/libxl_console.c | 2 +-
tools/libxl/libxl_dom.c | 2 +-
tools/libxl/libxl_internal.h | 2 +-
3 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/tools/libxl/li
flight 114653 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/114653/
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
oxenstored is our default implementation of xenstore, for platforms
that have ocaml support. We need it to be maintained. Dave Scott,
the only existing maintainer, has had limited availability.
Christian has been reveiwing patches and offering opinions where
necessary, although activity in this
On 10/06/2017 08:30 PM, Stefano Stabellini wrote:
> Send a PVCALLS_SOCKET command to the backend, use the masked
> req_prod_pvt as req_id. This way, req_id is guaranteed to be between 0
> and PVCALLS_NR_REQ_PER_RING. We already have a slot in the rsp array
> ready for the response, and there cannot
On Tue, Oct 17, 2017 at 04:05:23PM +0100, Andrew Cooper wrote:
> Rather than opencoding it in two places. While only used in the PV emulation
> code, this helper is in principle usable anywhere in the hypervisor.
>
> No functional change.
>
> Signed-off-by: Andrew Cooper
Reviewed-by: Wei Liu
In 1462f9ea8f4219d520a530787b80c986e050aa98
"tools: libxendevicemodel: Provide xendevicemodel_shutdown"
we added a new version 1.1 to the symbol map and simply abolished
the old one. That is quite wrong.
Instead, we should have left the 1.0 map alone and added a new version
which simply adds the
On Tue, Oct 17, 2017 at 06:05:35PM +0100, Ian Jackson wrote:
> In 1462f9ea8f4219d520a530787b80c986e050aa98
> "tools: libxendevicemodel: Provide xendevicemodel_shutdown"
> we added a new version 1.1 to the symbol map and simply abolished
> the old one. That is quite wrong.
>
> Instead, we should h
On Mon, Oct 16, 2017 at 03:36:38PM +0100, Julien Grall wrote:
> Hi Volodymyr,
Hi Julien,
> On 11/10/17 20:01, Volodymyr Babchuk wrote:
> >Add basic OP-TEE mediator as an example how TEE mediator framework
> >works.
> >
> >Currently it support only calls from Dom0. Calls from other guests
> >will b
On 10/17/2017 06:10 PM, George Dunlap wrote:
> Allowing pagetables to point to other pagetables of the same level
> (often called 'linear pagetables') has been included in Xen since its
> inception; but recently it has been the source of a number of subtle
> reference-counting bugs.
>
> It is not
Allowing pagetables to point to other pagetables of the same level
(often called 'linear pagetables') has been included in Xen since its
inception; but recently it has been the source of a number of subtle
reference-counting bugs.
It is not used by Linux or MiniOS; but it used used by NetBSD and
N
TSS_ENTRY is a compile time constant, so HOST_TR_SELECTOR can be set up during
VMCS construction and left alone thereafter, rather than rewriting it on every
context switch.
Signed-off-by: Andrew Cooper
---
CC: Jan Beulich
CC: Wei Liu
CC: Jun Nakajima
CC: Kevin Tian
---
xen/arch/x86/hvm/vmx/
On 17/10/17 18:06, Wei Liu wrote:
> On Tue, Oct 17, 2017 at 06:05:35PM +0100, Ian Jackson wrote:
>> In 1462f9ea8f4219d520a530787b80c986e050aa98
>> "tools: libxendevicemodel: Provide xendevicemodel_shutdown"
>> we added a new version 1.1 to the symbol map and simply abolished
>> the old one. That i
Hi Julien,
On Tue, Oct 17, 2017 at 05:39:29PM +0100, Julien Grall wrote:
Excuse me, looks like you skipped my thoughts about how to detect
TEE if we are not sure, that we are running on SMCCC-capable platform.
How do you think, is it appropriate to rely on DT?
[...]
> >>>@@ -673,6 +674,9 @@ int
1 - 100 of 126 matches
Mail list logo
