flight 162882 xen-4.15-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/162882/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-libvirt-vhd 19 guest-start/debian.repeat fail blocked in
162561
test-amd64-amd64-xl-qemuu-win
Marek Marczykowski-Górecki writes:
> Kernel on Xen is loaded via fw_cfg. Previously it used non-DMA version,
> which loaded the kernel (and initramfs) byte by byte. Change this
> to DMA, to load in bigger chunks.
> This change alone reduces load time of a (big) kernel+initramfs from
> ~10s down
A single slash gives a float, a double slash gives an int.
bitmap = unpack_exact("Q" * ((max_id/64) + 1))
TypeError: can't multiply sequence by non-int of type 'float'
This is broken for unknown reasons since 4.14.
Signed-off-by: Olaf Hering
---
tools/python/scripts/convert-legacy-stream |
On 18/06/2021 10:31, Olaf Hering wrote:
> A single slash gives a float, a double slash gives an int.
>
> bitmap = unpack_exact("Q" * ((max_id/64) + 1))
> TypeError: can't multiply sequence by non-int of type 'float'
>
> This is broken for unknown reasons since 4.14.
:(
This is a Py2 vs Py3 di
Am Fri, 18 Jun 2021 10:42:58 +0100
schrieb Andrew Cooper :
> This is a Py2 vs Py3 difference.
Indeed, my build wrapper changes every 'env python' to 'python3.4' in 4.14+
builds.
That explains why it happens to work with my 4.13 builds, which changes every
'env python' to 'python2.7'.
Olaf
pg
On 18/06/2021 01:12, Stefano Stabellini wrote:
> On Thu, 17 Jun 2021, Daniel P. Smith wrote:
>> Would like to add myself as a reviewer for XSM.
>>
>> Signed-off-by: Daniel P. Smith
> Acked-by: Stefano Stabellini
Acked-by: Andrew Cooper
On 18/06/2021 00:39, Daniel P. Smith wrote:
> Based on feedback from 2021 Xen Developers Summit the xsm-roles RFC
> patch set is being split into two separate patch sets. This is the first
> patch set and is focused purely on the clean up and refactoring of the
> XSM hooks.
>
> This patch set refac
The present remaining osstest failures are due to truncation of the GFN
resulting from the hypercall return value being passed back through the
ioctl() return value (on Linux and Solaris), which is "int", plus the
same for some further internal interfaces (osdep_hypercall(),
xencall()). Some of the
To be able to use them from, in particular, the tool stack, they need to
be supported for all guest types. Note that xc_resource_op() already
does, so would not work without this on PVH Dom0.
Signed-off-by: Jan Beulich
--- a/xen/arch/x86/hvm/hypercall.c
+++ b/xen/arch/x86/hvm/hypercall.c
@@ -26,
Some hypercalls, memory-op in particular, can return values requiring
more than 31 bits to represent. Hence the underlying layers need to make
sure they won't truncate such values. (Note that for Solaris the
function also gets renamed, to match the other OSes.)
Signed-off-by: Jan Beulich
--- a/t
Some hypercalls, memory-op in particular, can return values requiring
more than 31 bits to represent. Hence the underlying layers need to make
sure they won't truncate such values.
While adding the new function to the map file, I noticed the stray
xencall6 there. I'm taking the liberty to remove i
Some sub-functions, XENMEM_maximum_gpfn in particular, can return values
requiring more than 31 bits to represent. Hence we cannot issue the
hypercall directly when the return value of ioctl() is used to propagate
this value (note that this is not the case for the BSDs, and MiniOS
already wraps all
libxc generally uses uint32_t to represent domain IDs. This is fine as
long as addresses of such variables aren't taken, to then pass into
hypercalls: To the hypervisor, a domain ID is a 16-bit value. Use an
intermediate variable to deal with the issue. (On architectures with
arguments passed in re
> On May 24, 2021, at 9:36 PM, Nick Rosbrook wrote:
>
> Re-generate code to reflect changes to libxl_types.idl from the
> following commits:
>
> 0570d7f276 x86/msr: introduce an option for compatible MSR behavior selection
> 7e5cffcd1e viridian: allow vCPU hotplug for Windows VMs
> 9835246710
Introduces following functions in Xenctrl and associated types:
get_system_cpu_policy
cpu_policy_to_featureset,
string_of_xen_cpu_policy_index
These are wrappers around the existing C functions in xenctrl.h,
that will be used by xenopsd initially.
-Wno-declaration-after-statement is disabled to a
> On May 24, 2021, at 9:36 PM, Nick Rosbrook wrote:
>
> The current implementation of StringList.toC does not correctly account
> for how libxl_string_list is expected to be laid out in C, which is clear
> when one looks at libxl_string_list_length in libxl.c. In particular,
> StringList.toC d
> On May 24, 2021, at 9:36 PM, Nick Rosbrook wrote:
>
> In gengotypes.py, the toC functions only set C string fields when
> the Go strings are non-empty. However, to prevent segfaults in some
> cases, these fields should always at least be set to nil so that the C
> memory is zeroed out.
>
> U
flight 162881 xen-4.14-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/162881/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-armhf-armhf-libvirt 16 saverestore-support-checkfail like 162547
test-amd64-i386-xl-qemuu-win7-am
> On May 24, 2021, at 9:36 PM, Nick Rosbrook wrote:
>
> For structs that have a keyed union, e.g. DomainBuildInfo, the TypeUnion
> field must be exported so that package users can get/set the fields
> within. This means that users are aware of the existence of the
> interface type used in thos
> On May 24, 2021, at 9:36 PM, Nick Rosbrook wrote:
>
> Currently, when marshalig Go types with keyed union fields, we assign the
> value of the struct (e.g. DomainBuildInfoTypeUnionHvm) which implements the
> interface of the keyed union field (e.g. DomainBuildInfoTypeUnion).
> As-is, this me
On 18/06/2021 00:39, Daniel P. Smith wrote:
> The assignment and setup of xsm_ops structure was refactored to make it a
> one-time assignment. The calling of the xsm_ops were refactored to use the
> alternate_call framework to reduce the need for retpolines.
>
> Signed-off-by: Daniel P. Smith
I t
> On May 24, 2021, at 9:36 PM, Nick Rosbrook wrote:
>
> As a matter of style, it is strange to see capitalized receiver names,
> due to the significance of capitalized symbols in Go (although there is
> in fact nothing special about a capitalized receiver name). Fix this in
> xenlight.go by ru
On 18.06.2021 13:34, Andrew Cooper wrote:
> On 18/06/2021 00:39, Daniel P. Smith wrote:
>> @@ -197,16 +204,21 @@ bool __init has_xsm_magic(paddr_t start)
>>
>> int __init register_xsm(struct xsm_operations *ops)
>> {
>> -if ( verify(ops) )
>> +if ( xsm_ops_registered != XSM_OPS_UNREGIST
On 18/06/2021 12:44, Jan Beulich wrote:
> On 18.06.2021 13:34, Andrew Cooper wrote:
>> On 18/06/2021 00:39, Daniel P. Smith wrote:
>>> @@ -197,16 +204,21 @@ bool __init has_xsm_magic(paddr_t start)
>>>
>>> int __init register_xsm(struct xsm_operations *ops)
>>> {
>>> -if ( verify(ops) )
>>>
On 18.06.2021 12:14, Andrew Cooper wrote:
> On 18/06/2021 00:39, Daniel P. Smith wrote:
>> Based on feedback from 2021 Xen Developers Summit the xsm-roles RFC
>> patch set is being split into two separate patch sets. This is the first
>> patch set and is focused purely on the clean up and refactori
flight 162884 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/162884/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-xl-qemuu-ovmf-amd64 12 debian-hvm-install fail REGR. vs. 162359
test-amd64-amd64-xl-qemuu
On 18/06/2021 00:39, Daniel P. Smith wrote:
> The only difference between !CONFIG_XSM and CONFIG_XSM with !CONFIG_XSM_SILO
> and !CONFIG_XSM_FLASK
> is whether the XSM hooks in dummy.h are called as static inline functions or
> as function
> pointers to static functions. As such this commit,
> *
On 18/06/2021 00:39, Daniel P. Smith wrote:
> With the conversion of making XSM always enabled even the dummy XSM module is
> being invoked through the xsm_ops dispatch which does not use passing of the
> default privilege. This commit removes the xen_default_t parameter from the
> hook
> definiti
On 18/06/2021 00:39, Daniel P. Smith wrote:
> diff --git a/xen/xsm/dummy.h b/xen/xsm/dummy.h
> index 7e2bb09dac..0f8ea163af 100644
> --- a/xen/xsm/dummy.h
> +++ b/xen/xsm/dummy.h
> @@ -9,7 +9,7 @@
> *
> *
> * Each XSM hook implementing an access check should have its first
> parameter
> - *
Hi, all!
What do we need in order to move on on this?
It seems this can be good to have for many use-cases around
Thank you,
Oleksandr
On 20.05.21 19:21, Stefano Stabellini wrote:
On Thu, 20 May 2021, Julien Grall wrote:
On 20/05/2021 00:25, Stefano Stabellini wrote:
On Sat, 15 May 2021, J
Am Wed, 2 Jun 2021 08:59:13 +0200
schrieb Juergen Gross :
> > @@ -152,9 +152,8 @@ int populate_pfns(struct xc_sr_context *ctx, unsigned
> > int count,
> >
> > for ( i = 0; i < count; ++i )
> > {
> > -if ( (!types || (types &&
> > - (types[i] != XEN_D
On 18.06.2021 01:39, Daniel P. Smith wrote:
> The only difference between !CONFIG_XSM and CONFIG_XSM with !CONFIG_XSM_SILO
> and !CONFIG_XSM_FLASK
> is whether the XSM hooks in dummy.h are called as static inline functions or
> as function
> pointers to static functions. As such this commit,
> *
On 18.06.2021 01:39, Daniel P. Smith wrote:
> With the conversion of making XSM always enabled even the dummy XSM module is
> being invoked through the xsm_ops dispatch which does not use passing of the
> default privilege. This commit removes the xen_default_t parameter from the
> hook
> definiti
On 18.06.2021 14:03, Andrew Cooper wrote:
> On 18/06/2021 00:39, Daniel P. Smith wrote:
>> diff --git a/xen/xsm/dummy.h b/xen/xsm/dummy.h
>> index 7e2bb09dac..0f8ea163af 100644
>> --- a/xen/xsm/dummy.h
>> +++ b/xen/xsm/dummy.h
>> @@ -9,7 +9,7 @@
>> *
>> *
>> * Each XSM hook implementing an a
On 18.06.2021 14:40, Jan Beulich wrote:
> On 18.06.2021 14:03, Andrew Cooper wrote:
>> On 18/06/2021 00:39, Daniel P. Smith wrote:
>>> diff --git a/xen/xsm/dummy.h b/xen/xsm/dummy.h
>>> index 7e2bb09dac..0f8ea163af 100644
>>> --- a/xen/xsm/dummy.h
>>> +++ b/xen/xsm/dummy.h
>>> @@ -9,7 +9,7 @@
>>>
On 18/06/2021 11:23, Jan Beulich wrote:
> To be able to use them from, in particular, the tool stack, they need to
> be supported for all guest types. Note that xc_resource_op() already
> does, so would not work without this on PVH Dom0.
I'm not a fan of multicalls as a concept - they're mostly a
As to the title, xc_maximum_ram_page() is similarly affected. Plus,
perhaps less worrying, xc_sharing_{freed,used}_pages().
Jan
flight 162886 xtf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/162886/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
xtf 3e800027016ea4eb19887bf626b46f45fc43fa5d
baseline version:
xtf 5ead491e36af6cb8681fc1
On 18 Jun 2021, at 11:45, Edwin Török
mailto:edvin.to...@citrix.com>> wrote:
Introduces following functions in Xenctrl and associated types:
get_system_cpu_policy
cpu_policy_to_featureset,
string_of_xen_cpu_policy_index
These are wrappers around the existing C functions in xenctrl.h,
that will
On 18.06.2021 15:02, Andrew Cooper wrote:
> On 18/06/2021 11:23, Jan Beulich wrote:
>> To be able to use them from, in particular, the tool stack, they need to
>> be supported for all guest types. Note that xc_resource_op() already
>> does, so would not work without this on PVH Dom0.
>
> I'm not a
> On May 24, 2021, at 9:36 PM, Nick Rosbrook wrote:
>
> Add some logging methods to Context to provide easy use of the
> Contenxt's xentoollog_logger. These are not exported, but the LogLevel
> type is so that a later commit can allow the Context's log level to be
> configurable.
>
> Becuase c
On 18/06/2021 11:45, Edwin Török wrote:
> diff --git a/tools/ocaml/libs/xc/xenctrl_stubs.c
> b/tools/ocaml/libs/xc/xenctrl_stubs.c
> index d05d7bb30e..4a230de8b7 100644
> --- a/tools/ocaml/libs/xc/xenctrl_stubs.c
> +++ b/tools/ocaml/libs/xc/xenctrl_stubs.c
> @@ -34,6 +34,9 @@
> #include
> #incl
> On Jun 18, 2021, at 2:17 PM, George Dunlap wrote:
>
>
>
>> On May 24, 2021, at 9:36 PM, Nick Rosbrook wrote:
>>
>> Add some logging methods to Context to provide easy use of the
>> Contenxt's xentoollog_logger. These are not exported, but the LogLevel
>> type is so that a later commit can
On 18/06/2021 11:23, Jan Beulich wrote:
> Some hypercalls, memory-op in particular, can return values requiring
> more than 31 bits to represent. Hence the underlying layers need to make
> sure they won't truncate such values. (Note that for Solaris the
> function also gets renamed, to match the ot
On 18.06.2021 15:26, Andrew Cooper wrote:
> On 18/06/2021 11:23, Jan Beulich wrote:
>> Some hypercalls, memory-op in particular, can return values requiring
>> more than 31 bits to represent. Hence the underlying layers need to make
>> sure they won't truncate such values. (Note that for Solaris th
> On 18 Jun 2021, at 14:09, Christian Lindig
> wrote:
>
>
>
>> On 18 Jun 2021, at 11:45, Edwin Török wrote:
>>
>> Introduces following functions in Xenctrl and associated types:
>> get_system_cpu_policy
>> cpu_policy_to_featureset,
>> string_of_xen_cpu_policy_index
>>
>> These are wrapper
On 18/06/2021 11:24, Jan Beulich wrote:
> Some hypercalls, memory-op in particular, can return values requiring
> more than 31 bits to represent. Hence the underlying layers need to make
> sure they won't truncate such values.
>
> While adding the new function to the map file, I noticed the stray
>
> On 18 Jun 2021, at 14:17, Andrew Cooper wrote:
>
> On 18/06/2021 11:45, Edwin Török wrote:
>> diff --git a/tools/ocaml/libs/xc/xenctrl_stubs.c
>> b/tools/ocaml/libs/xc/xenctrl_stubs.c
>> index d05d7bb30e..4a230de8b7 100644
>> --- a/tools/ocaml/libs/xc/xenctrl_stubs.c
>> +++ b/tools/ocaml/lib
On 14.05.2021 22:54, Daniel P. Smith wrote:
> --- a/xen/include/xen/sched.h
> +++ b/xen/include/xen/sched.h
> @@ -457,6 +457,24 @@ struct domain
> */
> bool creation_finished;
>
> +/* When SILO or Flask are not in use, a domain may have one or more roles
> + * that
On 14.05.2021 22:54, Daniel P. Smith wrote:
> --- a/xen/common/domain.c
> +++ b/xen/common/domain.c
> @@ -556,6 +556,9 @@ struct domain *domain_create(domid_t domid,
> /* Sort out our idea of is_control_domain(). */
> d->is_privileged = is_priv;
With the change to is_control_domain() thi
On 6/18/21 1:25 AM, Claire Chang wrote:
> On Fri, Jun 18, 2021 at 7:30 AM Stefano Stabellini
> wrote:
>>
>> On Thu, 17 Jun 2021, Claire Chang wrote:
>>> Add a new function, swiotlb_init_io_tlb_mem, for the io_tlb_mem struct
>>> initialization to make the code reusable.
>>>
>>> Signed-off-by: Clair
On 14.05.2021 22:54, Daniel P. Smith wrote:
In the title, did you mean just one of "convert" or "rewrite", or
did you omit some punctuation?
> --- a/xen/include/xen/sched.h
> +++ b/xen/include/xen/sched.h
> @@ -475,6 +475,12 @@ struct domain
> #define XSM_XENSTORE (1U<<31) /* Xenstore: domain t
On Fri, Jun 18, 2021 at 09:09:17AM -0500, Tom Lendacky wrote:
> > swiotlb_init_with_tbl uses memblock_alloc to allocate the io_tlb_mem
> > and memblock_alloc[1] will do memset in memblock_alloc_try_nid[2], so
> > swiotlb_init_with_tbl is also good.
> > I'm happy to add the memset in swiotlb_init_io
> On May 24, 2021, at 9:36 PM, Nick Rosbrook wrote:
>
> Add a ContextOption type to support functional options in NewContext.
> Then, add a variadic ContextOption parameter to NewContext, which allows
> callers to specify 0 or more configuration options.
>
> For now, just add the WithLogLevel
On 14.05.2021 22:54, Daniel P. Smith wrote:
> --- a/xen/arch/x86/cpu/vpmu.c
> +++ b/xen/arch/x86/cpu/vpmu.c
> @@ -169,13 +169,14 @@ int vpmu_do_msr(unsigned int msr, uint64_t *msr_content,
> static inline struct vcpu *choose_hwdom_vcpu(void)
> {
> unsigned idx;
> +struct domain *hwdom =
> On May 24, 2021, at 9:36 PM, Nick Rosbrook wrote:
>
> Add a wrapper around libxl_domain_destroy.
>
> Signed-off-by: Nick Rosbrook
Reviewed-by: George Dunlap
> On May 24, 2021, at 9:36 PM, Nick Rosbrook wrote:
>
> Add a warpper around libxl_send_trigger.
>
> Signed-off-by: Nick Rosbrook
Reviewed-by: George Dunlap
On 18.06.2021 15:46, Andrew Cooper wrote:
> On 18/06/2021 11:24, Jan Beulich wrote:
>> Some hypercalls, memory-op in particular, can return values requiring
>> more than 31 bits to represent. Hence the underlying layers need to make
>> sure they won't truncate such values.
>>
>> While adding the ne
On 18/06/2021 11:24, Jan Beulich wrote:
> Some sub-functions, XENMEM_maximum_gpfn in particular, can return values
> requiring more than 31 bits to represent. Hence we cannot issue the
> hypercall directly when the return value of ioctl() is used to propagate
> this value (note that this is not the
On 18/06/2021 11:25, Jan Beulich wrote:
> libxc generally uses uint32_t to represent domain IDs. This is fine as
> long as addresses of such variables aren't taken, to then pass into
> hypercalls: To the hypervisor, a domain ID is a 16-bit value. Use an
> intermediate variable to deal with the issu
On Fri, Jun 18, 2021 at 02:44:15PM +, George Dunlap wrote:
>
>
> > On May 24, 2021, at 9:36 PM, Nick Rosbrook wrote:
> >
> > Add a ContextOption type to support functional options in NewContext.
> > Then, add a variadic ContextOption parameter to NewContext, which allows
> > callers to spec
> On May 24, 2021, at 9:36 PM, Nick Rosbrook wrote:
>
> There are several locations where the return code from calling into C is
> negated when being converted to Error. This results in error strings
> like "libxl error: ", rather than the correct message. Fix all
> occurrances of this by runni
On Fri, Jun 18, 2021 at 01:17:07PM +, George Dunlap wrote:
>
>
> > On May 24, 2021, at 9:36 PM, Nick Rosbrook wrote:
> >
> > Add some logging methods to Context to provide easy use of the
> > Contenxt's xentoollog_logger. These are not exported, but the LogLevel
> > type is so that a later
On 18/06/2021 16:06, Andrew Cooper wrote:
> On 18/06/2021 11:25, Jan Beulich wrote:
>> libxc generally uses uint32_t to represent domain IDs. This is fine as
>> long as addresses of such variables aren't taken, to then pass into
>> hypercalls: To the hypervisor, a domain ID is a 16-bit value. Use a
On 18/06/2021 16:22, Andrew Cooper wrote:
> On 18/06/2021 16:06, Andrew Cooper wrote:
>> On 18/06/2021 11:25, Jan Beulich wrote:
>>> libxc generally uses uint32_t to represent domain IDs. This is fine as
>>> long as addresses of such variables aren't taken, to then pass into
>>> hypercalls: To the
On Fri, Jun 18, 2021 at 01:21:40PM +, George Dunlap wrote:
>
>
> > On Jun 18, 2021, at 2:17 PM, George Dunlap wrote:
> >
> >
> >
> >> On May 24, 2021, at 9:36 PM, Nick Rosbrook wrote:
> >>
> >> Add some logging methods to Context to provide easy use of the
> >> Contenxt's xentoollog_log
On 18.06.2021 17:05, Andrew Cooper wrote:
> On 18/06/2021 11:24, Jan Beulich wrote:
>> Some sub-functions, XENMEM_maximum_gpfn in particular, can return values
>> requiring more than 31 bits to represent. Hence we cannot issue the
>> hypercall directly when the return value of ioctl() is used to pr
On Fri, Jun 18, 2021 at 03:13:03PM +, George Dunlap wrote:
>
>
> > On May 24, 2021, at 9:36 PM, Nick Rosbrook wrote:
> >
> > There are several locations where the return code from calling into C is
> > negated when being converted to Error. This results in error strings
> > like "libxl erro
Am Fri, 18 Jun 2021 10:42:58 +0100
schrieb Andrew Cooper :
> This is a Py2 vs Py3 difference.
This script is not ready for python 3.
At a first glance it is the usual type confusion.
It seems the type 'bytearray' exists in both variants.
Perhaps stream_read() should return such an object, instea
On 18.06.2021 17:24, Andrew Cooper wrote:
> On 18/06/2021 16:22, Andrew Cooper wrote:
>> On 18/06/2021 16:06, Andrew Cooper wrote:
>>> On 18/06/2021 11:25, Jan Beulich wrote:
libxc generally uses uint32_t to represent domain IDs. This is fine as
long as addresses of such variables aren't
On 6/18/21 6:14 AM, Andrew Cooper wrote:
> On 18/06/2021 00:39, Daniel P. Smith wrote:
>> Based on feedback from 2021 Xen Developers Summit the xsm-roles RFC
>> patch set is being split into two separate patch sets. This is the first
>> patch set and is focused purely on the clean up and refactorin
At the time of d838ac2539cf ("x86: don't allow Dom0 access to the HT
address range") documentation correctly stated that the range was
completely fixed. For Fam17 and newer, it lives at the top of physical
address space, though.
To correctly determine the top of physical address space, we need to
On 6/18/21 7:34 AM, Andrew Cooper wrote:
> On 18/06/2021 00:39, Daniel P. Smith wrote:
>> The assignment and setup of xsm_ops structure was refactored to make it a
>> one-time assignment. The calling of the xsm_ops were refactored to use the
>> alternate_call framework to reduce the need for retpol
> On Jun 18, 2021, at 4:08 PM, Nick Rosbrook wrote:
>
> On Fri, Jun 18, 2021 at 02:44:15PM +, George Dunlap wrote:
>>
>>
>>> On May 24, 2021, at 9:36 PM, Nick Rosbrook wrote:
>>>
>>> Add a ContextOption type to support functional options in NewContext.
>>> Then, add a variadic ContextOp
On 6/18/21 7:44 AM, Jan Beulich wrote:
> On 18.06.2021 13:34, Andrew Cooper wrote:
>> On 18/06/2021 00:39, Daniel P. Smith wrote:
>>> @@ -197,16 +204,21 @@ bool __init has_xsm_magic(paddr_t start)
>>>
>>> int __init register_xsm(struct xsm_operations *ops)
>>> {
>>> -if ( verify(ops) )
>>>
> On Jun 18, 2021, at 4:26 PM, Nick Rosbrook wrote:
>
> On Fri, Jun 18, 2021 at 01:21:40PM +, George Dunlap wrote:
>>
>>
>>> On Jun 18, 2021, at 2:17 PM, George Dunlap wrote:
>>>
>>>
>>>
On May 24, 2021, at 9:36 PM, Nick Rosbrook wrote:
Add some logging methods to Con
On 18/06/2021 17:00, Jan Beulich wrote:
> At the time of d838ac2539cf ("x86: don't allow Dom0 access to the HT
> address range") documentation correctly stated that the range was
> completely fixed. For Fam17 and newer, it lives at the top of physical
> address space, though.
>
> To correctly deter
> On Jun 18, 2021, at 4:17 PM, Nick Rosbrook wrote:
>
> On Fri, Jun 18, 2021 at 01:17:07PM +, George Dunlap wrote:
>> Also, is ‘xenlight’ informative enough? I haven’t looked at the other
>> “context” strings; would “go-xenlight” or something be better?
>>
>
> I believe libxl uses "libx
On 6/18/21 7:53 AM, Andrew Cooper wrote:
> On 18/06/2021 00:39, Daniel P. Smith wrote:
>> The only difference between !CONFIG_XSM and CONFIG_XSM with !CONFIG_XSM_SILO
>> and !CONFIG_XSM_FLASK
>> is whether the XSM hooks in dummy.h are called as static inline functions or
>> as function
>> pointer
On 6/18/21 7:56 AM, Andrew Cooper wrote:
> On 18/06/2021 00:39, Daniel P. Smith wrote:
>> With the conversion of making XSM always enabled even the dummy XSM module is
>> being invoked through the xsm_ops dispatch which does not use passing of the
>> default privilege. This commit removes the xen_d
On 6/18/21 8:03 AM, Andrew Cooper wrote:
> On 18/06/2021 00:39, Daniel P. Smith wrote:
>> diff --git a/xen/xsm/dummy.h b/xen/xsm/dummy.h
>> index 7e2bb09dac..0f8ea163af 100644
>> --- a/xen/xsm/dummy.h
>> +++ b/xen/xsm/dummy.h
>> @@ -9,7 +9,7 @@
>> *
>> *
>> * Each XSM hook implementing an ac
On 6/18/21 8:44 AM, Jan Beulich wrote:
> On 18.06.2021 14:40, Jan Beulich wrote:
>> On 18.06.2021 14:03, Andrew Cooper wrote:
>>> On 18/06/2021 00:39, Daniel P. Smith wrote:
diff --git a/xen/xsm/dummy.h b/xen/xsm/dummy.h
index 7e2bb09dac..0f8ea163af 100644
--- a/xen/xsm/dummy.h
Fixes commit fa5afbbc20ef3577c5338f9d0b24dad45cef59cd,
due to lack of commit 534519f0514f52007d504e0f2eeb714de7b2468d.
Signed-off-by: Olaf Hering
---
xen/include/xen/compiler.h | 7 +++
1 file changed, 7 insertions(+)
diff --git a/xen/include/xen/compiler.h b/xen/include/xen/compiler.h
inde
On 18/06/2021 17:42, Olaf Hering wrote:
> Fixes commit fa5afbbc20ef3577c5338f9d0b24dad45cef59cd,
> due to lack of commit 534519f0514f52007d504e0f2eeb714de7b2468d.
>
> Signed-off-by: Olaf Hering
Presumably you're intending this for Xen 4.13 and older?
~Andrew
Am Fri, 18 Jun 2021 17:46:47 +0100
schrieb Andrew Cooper :
> On 18/06/2021 17:42, Olaf Hering wrote:
> > Fixes commit fa5afbbc20ef3577c5338f9d0b24dad45cef59cd,
> > due to lack of commit 534519f0514f52007d504e0f2eeb714de7b2468d.
> Presumably you're intending this for Xen 4.13 and older?
722f59d38
flight 162888 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/162888/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-armhf-libvirt 6 libvirt-buildfail REGR. vs. 151777
build-amd64-libvirt
On Fri, Jun 18, 2021 at 04:18:44PM +, George Dunlap wrote:
>
>
> > On Jun 18, 2021, at 4:08 PM, Nick Rosbrook wrote:
> >
> > On Fri, Jun 18, 2021 at 02:44:15PM +, George Dunlap wrote:
> >>
> >>
> >>> On May 24, 2021, at 9:36 PM, Nick Rosbrook wrote:
> >>>
> >>> Add a ContextOption t
On 18/06/2021 14:46, Edwin Torok wrote:
>> On 18 Jun 2021, at 14:17, Andrew Cooper wrote:
>>
>> On 18/06/2021 11:45, Edwin Török wrote:
>>> diff --git a/tools/ocaml/libs/xc/xenctrl_stubs.c
>>> b/tools/ocaml/libs/xc/xenctrl_stubs.c
>>> index d05d7bb30e..4a230de8b7 100644
>>> --- a/tools/ocaml/libs
On 18/06/2021 17:00, Jan Beulich wrote:
At the time of d838ac2539cf ("x86: don't allow Dom0 access to the HT
address range") documentation correctly stated that the range was
completely fixed. For Fam17 and newer, it lives at the top of physical
address space, though.
From "Open-Source Register
On 18/06/2021 18:15, Igor Druzhinin wrote:
On 18/06/2021 17:00, Jan Beulich wrote:
At the time of d838ac2539cf ("x86: don't allow Dom0 access to the HT
address range") documentation correctly stated that the range was
completely fixed. For Fam17 and newer, it lives at the top of physical
address
> On Jun 18, 2021, at 6:00 PM, Nick Rosbrook wrote:
>
> On Fri, Jun 18, 2021 at 04:18:44PM +, George Dunlap wrote:
>>
>>
>>> On Jun 18, 2021, at 4:08 PM, Nick Rosbrook wrote:
>>>
>>> On Fri, Jun 18, 2021 at 02:44:15PM +, George Dunlap wrote:
> On May 24, 2021, at 9:3
> On May 24, 2021, at 9:36 PM, Nick Rosbrook wrote:
>
> Add a helper function to wait for domain death events, and then write
> the events to a provided channel. This handles the enabling/disabling of
> the event type, freeing the event, and converting it to a Go type. The
> caller can then han
flight 162885 xen-unstable real [real]
flight 162893 xen-unstable real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/162885/
http://logs.test-lab.xenproject.org/osstest/logs/162893/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be r
> On Jun 18, 2021, at 7:28 PM, George Dunlap wrote:
>
>
>
>> On May 24, 2021, at 9:36 PM, Nick Rosbrook wrote:
>>
>> Add a helper function to wait for domain death events, and then write
>> the events to a provided channel. This handles the enabling/disabling of
>> the event type, freeing t
On 6/18/21 8:26 AM, Jan Beulich wrote:
> On 18.06.2021 01:39, Daniel P. Smith wrote:
>> The only difference between !CONFIG_XSM and CONFIG_XSM with !CONFIG_XSM_SILO
>> and !CONFIG_XSM_FLASK
>> is whether the XSM hooks in dummy.h are called as static inline functions or
>> as function
>> pointers
On 18/06/2021 13:26, Jan Beulich wrote:
> On 18.06.2021 01:39, Daniel P. Smith wrote:
>> The only difference between !CONFIG_XSM and CONFIG_XSM with !CONFIG_XSM_SILO
>> and !CONFIG_XSM_FLASK
>> is whether the XSM hooks in dummy.h are called as static inline functions or
>> as function
>> pointers
On 18/06/2021 12:48, Jan Beulich wrote:
> On 18.06.2021 12:14, Andrew Cooper wrote:
>> On 18/06/2021 00:39, Daniel P. Smith wrote:
>>> Based on feedback from 2021 Xen Developers Summit the xsm-roles RFC
>>> patch set is being split into two separate patch sets. This is the first
>>> patch set and i
flight 162887 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/162887/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-xl-xsm7 xen-install fail REGR. vs. 152332
test-amd64-i386-xl-
flight 162889 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/162889/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-qemuu-freebsd11-amd64 16 guest-saverestore fail REGR. vs.
152631
test-amd64-am
This series implements mitigations for lack of DMA access control on
systems without an IOMMU, which could result in the DMA accessing the
system memory at unexpected times and/or unexpected addresses, possibly
leading to data leakage or corruption.
For example, we plan to use the PCI-e bus for Wi
1 - 100 of 114 matches
Mail list logo
