On 04.05.2021 23:31, Andrew Cooper wrote:
> --- a/tools/include/xen-tools/libs.h
> +++ b/tools/include/xen-tools/libs.h
> @@ -63,4 +63,9 @@
> #define ROUNDUP(_x,_w) (((unsigned long)(_x)+(1UL<<(_w))-1) &
> ~((1UL<<(_w))-1))
> #endif
>
> +#ifndef _AC
> +#define __AC(X, Y) (X ## Y)
> +#define
On 04.05.2021 20:53, Andrew Cooper wrote:
> Unsure what to do about x86_cpu_policies_are_compatible(). It would be nice
> to have xc_cpu_policy_is_compatible() sensibly const'd, but maybe that means
> we need a struct const_cpu_policy and that smells like it is spiralling out of
> control.
Not su
flight 161766 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/161766/
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-i3
Hi Jan,
Jan Beulich writes:
> On 21.04.2021 16:59, Jan Beulich wrote:
>> The current use of xzalloc_bytes() in optee is nearly an open-coded
>> version of xzalloc_flex_struct(), which was introduced after the driver
>> was merged.
>>
>> The main difference is xzalloc_bytes() will also force t
flight 161755 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/161755/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-xl-rtds 20 guest-localmigrate/x10 fail like 161628
test-amd64-amd64-xl-qemut-win7-amd64
On Tue, 4 May 2021, Luca Fancellu wrote:
> Create a skeleton for the documentation about hypercalls
Why is there a difference between the arm32, arm64 and x86_64 skeletons?
Shouldn't just we have one? Or if we have to have three, why are they
not identical?
> Signed-off-by: Luca Fancellu
> ---
On Tue, 4 May 2021, Luca Fancellu wrote:
> Modification to include/public/grant_table.h:
>
> 1) Add doxygen tags to:
> - Create Grant tables section
> - include variables in the generated documentation
> - Used @keepindent/@endkeepindent to enclose comment
>section that are indented using s
flight 161775 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/161775/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-libvirt 15 migrate-support-checkfail never pass
test-armhf-armhf-xl 1
Just as with x86_cpu_policies_are_compatible(), make a start on this function
with some token handling.
Add levelling support for MSR_ARCH_CAPS, because RSBA has interesting
properties, and introduce test_calculate_compatible_success() to the unit
tests, covering various cases where the arch_caps
It is bad form in C, perhaps best demonstrated by trying to read
xc_cpu_policy_destroy(), and causes const qualification to have
less-than-obvious behaviour (the hidden pointer becomes const, not the thing
it points at).
xc_cpu_policy_set_domain() needs to drop its (now normal) const qualification
flight 161761 xen-4.12-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/161761/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-xsm 6 xen-buildfail REGR. vs. 159418
build-amd64
On 04/05/2021 13:48, Jason Andryuk wrote:
> The vtpmmgr TPM 2.0 support is incomplete. Add a warning about that to
> the documentation so others don't have to work through discovering it is
> broken.
>
> Signed-off-by: Jason Andryuk
Acked-by: Andrew Cooper
This is definitely the kind of health
On 04/05/2021 15:31, Olaf Hering wrote:
> sysconfig files are not mandatory.
> Adjust xen-init-dom0.service to handle a missing sysconfig file by
> prepending a dash to the to-be-sourced filename.
>
> Signed-off-by: Olaf Hering
Acked-by: Andrew Cooper
On 04/05/2021 14:58, Olaf Hering wrote:
> sysconfig files are not mandatory.
> Adjust xenconsoled.service to handle a missing sysconfig file by
> prepending a dash to the to-be-sourced filename.
>
> Signed-off-by: Olaf Hering
Acked-by: Andrew Cooper
Jason Andryuk, le mar. 04 mai 2021 13:27:36 -0400, a ecrit:
> On Tue, May 4, 2021 at 1:07 PM Samuel Thibault
> wrote:
> >
> > Jason Andryuk, le mar. 04 mai 2021 13:04:47 -0400, a ecrit:
> > > owner_auth & srk_auth don't check :, but then they don't skip : or =
> > > when passing the string to pars
On 04/05/2021 14:50, Olaf Hering wrote:
> --log does not take a file, it specifies what is supposed to be logged.
>
> Signed-off-by: Olaf Hering
Acked-by: Andrew Cooper . That said, ...
> ---
> tools/hotplug/FreeBSD/rc.d/xencommons.in | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
>
Jason Andryuk, le mar. 04 mai 2021 13:23:57 -0400, a ecrit:
> > > @@ -842,6 +889,7 @@ TPM_RESULT vtpmmgr_handle_cmd(
> > > switch(ord) {
> > > case TPM_ORD_GetRandom:
> > > vtpmloginfo(VTPM_LOG_VTPM, "Passthrough:
> > > TPM_GetRandom\n");
> > > +
On Tue, May 04, 2021 at 04:46:52PM +0100, Anthony PERARD wrote:
> On Tue, Mar 02, 2021 at 08:46:12PM -0500, Nick Rosbrook wrote:
> > At a Xen Summit design session for the golang bindings (see [1]), we
> > agreed that it would be beneficial to expand the libxl IDL with function
> > support. In addi
On Tue, May 04, 2021 at 04:02:55PM +0100, Anthony PERARD wrote:
> On Tue, Mar 02, 2021 at 08:46:18PM -0500, Nick Rosbrook wrote:
> > +def libxl_func_define_device_add(func):
> > +s = ''
> > +
> > +return_type = func.return_type.typename
> > +if isinstance(func.return_type, idl.Enumerati
On Tue, May 4, 2021 at 1:07 PM Samuel Thibault
wrote:
>
> Jason Andryuk, le mar. 04 mai 2021 13:04:47 -0400, a ecrit:
> > owner_auth & srk_auth don't check :, but then they don't skip : or =
> > when passing the string to parse_auth_string. So they can't work
> > properly?
>
> They happen to "wor
On Tue, May 04, 2021 at 04:43:27PM +0100, Anthony PERARD wrote:
> On Tue, Mar 02, 2021 at 08:46:17PM -0500, Nick Rosbrook wrote:
> > diff --git a/tools/libs/light/libxl_types.idl
> > b/tools/libs/light/libxl_types.idl
> > index 5b85a7419f..550af7a1c7 100644
> > --- a/tools/libs/light/libxl_types.i
On Tue, May 4, 2021 at 9:33 AM Samuel Thibault
wrote:
>
> Jason Andryuk, le mar. 04 mai 2021 08:48:42 -0400, a ecrit:
> > GetRandom passthrough currently fails when using vtpmmgr with a hardware
> > TPM 2.0.
> > vtpmmgr (8): INFO[VTPM]: Passthrough: TPM_GetRandom
> > vtpm (12): vtpm_cmd.c:120: Err
On 04/05/2021 12:58, Roger Pau Monné wrote:
> On Tue, May 04, 2021 at 01:40:11PM +0200, Jan Beulich wrote:
>> On 04.05.2021 12:56, Roger Pau Monné wrote:
>>> On Mon, May 03, 2021 at 12:41:29PM +0200, Jan Beulich wrote:
On 30.04.2021 17:52, Roger Pau Monne wrote:
> --- a/tools/libs/guest/xg
Jason Andryuk, le mar. 04 mai 2021 13:05:33 -0400, a ecrit:
> On Tue, May 4, 2021 at 9:16 AM Samuel Thibault
> wrote:
> >
> > Jason Andryuk, le mar. 04 mai 2021 08:48:40 -0400, a ecrit:
> > > We're only flushing 2 transients, but there are 3 handles. Use <= to also
> > > flush the third handle.
>
Jason Andryuk, le mar. 04 mai 2021 13:04:47 -0400, a ecrit:
> owner_auth & srk_auth don't check :, but then they don't skip : or =
> when passing the string to parse_auth_string. So they can't work
> properly?
They happen to "work" just because there is no other parameter prefixed
the same.
> >
On Tue, May 4, 2021 at 9:16 AM Samuel Thibault
wrote:
>
> Jason Andryuk, le mar. 04 mai 2021 08:48:40 -0400, a ecrit:
> > We're only flushing 2 transients, but there are 3 handles. Use <= to also
> > flush the third handle.
> >
> > The number of transient handles/keys is hardware dependent, so th
On Tue, May 4, 2021 at 9:13 AM Samuel Thibault
wrote:
>
> Jason Andryuk, le mar. 04 mai 2021 08:48:37 -0400, a ecrit:
> > Bypass taking ownership of the TPM2 if an srk_handle is specified.
> >
> > This srk_handle must be usable with Null auth for the time being.
> >
> > Signed-off-by: Jason Andryu
On 30/04/2021 16:52, Roger Pau Monne wrote:
> Introduce a helper to obtain a compatible cpu policy based on two
> input cpu policies. Currently this is done by and'ing all CPUID
> feature leaves and MSR entries, except for MSR_ARCH_CAPABILITIES which
> has the RSBA bit or'ed.
>
> The _AC macro is p
On 30/04/2021 16:52, Roger Pau Monne wrote:
> Such helpers is just a wrapper to the existing
> x86_cpu_policies_are_compatible function. This requires building
> policy.c from libx86 on user land also.
>
> No user of the interface introduced.
>
> Signed-off-by: Roger Pau Monné
Acked-by: Andrew Co
On 30/04/2021 16:52, Roger Pau Monne wrote:
> Introduce a helper to update the MSR policy using an array of
> xen_msr_entry_t entries. Note the MSRs present in the input
> xen_msr_entry_t array will replace any existing entries on the
> policy.
>
> No user of the interface introduced on this patch.
On 30/04/2021 16:52, Roger Pau Monne wrote:
> Introduce a helper to update the CPUID policy using an array of
> xen_cpuid_leaf_t entries. Note the leaves present in the input
> xen_cpuid_leaf_t array will replace any existing leaves on the policy.
>
> No user of the interface introduced on this pat
Also constify cmdtable_len and make use of ARRAY_SIZE, which is
available in "xen-tools/libs.h".
The entries in cmd_table don't need to be modified once xl is running.
Signed-off-by: Anthony PERARD
Reviewed-by: Julien Grall
---
Notes:
v2:
- use ARRAY_SIZE()
- rework commit message
On 04.05.2021 15:33, Luca Fancellu wrote:
>
>
>> On 4 May 2021, at 14:28, Jan Beulich wrote:
>>
>> On 04.05.2021 15:09, Luca Fancellu wrote:
On 4 May 2021, at 12:48, Jan Beulich wrote:
On 04.05.2021 11:46, Luca Fancellu wrote:
> @@ -451,11 +466,6 @@ DEFINE_XEN_GUEST_HANDLE(gnttab_
flight 161768 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/161768/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-libvirt 15 migrate-support-checkfail never pass
test-armhf-armhf-xl 1
On Wed, Apr 28, 2021 at 01:54:39PM +0100, Julien Grall wrote:
> > -int cmdtable_len = sizeof(cmd_table)/sizeof(struct cmd_spec);
> > +const int cmdtable_len = sizeof(cmd_table)/sizeof(struct cmd_spec);
>
> NIT: This can be replaced with ARRAY_SIZE().
I've thought of using it but the macro isn't a
On Tue, Mar 02, 2021 at 08:46:12PM -0500, Nick Rosbrook wrote:
> At a Xen Summit design session for the golang bindings (see [1]), we
> agreed that it would be beneficial to expand the libxl IDL with function
> support. In addition to benefiting libxl itself, this would allow other
> language bindi
On 04/05/2021 14:47, Roger Pau Monné wrote:
> On Tue, May 04, 2021 at 12:59:43PM +0100, Andrew Cooper wrote:
>> On 30/04/2021 16:52, Roger Pau Monne wrote:
>>> @@ -822,3 +825,28 @@ int xc_cpu_policy_serialise(xc_interface *xch, const
>>> xc_cpu_policy_t p,
>>> errno = 0;
>>> return 0;
>>
On Tue, Mar 02, 2021 at 08:46:17PM -0500, Nick Rosbrook wrote:
> diff --git a/tools/libs/light/libxl_types.idl
> b/tools/libs/light/libxl_types.idl
> index 5b85a7419f..550af7a1c7 100644
> --- a/tools/libs/light/libxl_types.idl
> +++ b/tools/libs/light/libxl_types.idl
> @@ -666,6 +668,24 @@ libxl_d
On Mon, May 03, 2021 at 01:09:41PM +0200, Jan Beulich wrote:
> On 30.04.2021 17:52, Roger Pau Monne wrote:
> > @@ -1086,3 +1075,42 @@ int xc_cpu_policy_calc_compatible(xc_interface *xch,
> >
> > return rc;
> > }
> > +
> > +int xc_cpu_policy_make_compatible(xc_interface *xch, xc_cpu_policy_t
On Tue, Mar 02, 2021 at 08:46:18PM -0500, Nick Rosbrook wrote:
> +def libxl_func_define_device_add(func):
> +s = ''
> +
> +return_type = func.return_type.typename
> +if isinstance(func.return_type, idl.Enumeration):
> +return_type = idl.integer.typename
> +
> +params = ', '.
On Tue, Mar 02, 2021 at 08:46:13PM -0500, Nick Rosbrook wrote:
> No functional change, just remove the extra whitespace from gentypes.py.
>
> Signed-off-by: Nick Rosbrook
Acked-by: Anthony PERARD
Thanks,
--
Anthony PERARD
sysconfig files are not mandatory.
Adjust xen-init-dom0.service to handle a missing sysconfig file by
prepending a dash to the to-be-sourced filename.
Signed-off-by: Olaf Hering
---
tools/hotplug/Linux/systemd/xen-init-dom0.service.in | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff -
On 04/05/2021 13:56, Jan Beulich wrote:
> On 03.05.2021 17:39, Andrew Cooper wrote:
>> If max leaf is greater than 0xd but xsave not available to the guest, then
>> the
>> current XSAVE size should not be filled in. This is a latent bug for now as
>> the guest max leaf is 0xd, but will become pro
On Fri, Apr 30, 2021 at 05:52:11PM +0200, Roger Pau Monne wrote:
> Move the logic from xc_cpu_policy_apply_cpuid into libxl, now that the
> xc_cpu_policy_* helpers allow modifying a cpu policy. By moving such
> parsing into libxl directly we can get rid of xc_xend_cpuid, as libxl
> will now impleme
On Fri, Apr 30, 2021 at 05:52:10PM +0200, Roger Pau Monne wrote:
> With the addition of the xc_cpu_policy_* now libxl can have better
> control over the cpu policy, this allows removing the
> xc_cpuid_apply_policy function and instead coding the required bits by
> libxl in libxl__cpuid_legacy direc
On Fri, Apr 30, 2021 at 05:51:59PM +0200, Roger Pau Monne wrote:
> Also change libxl__cpuid_legacy to propagate the error from
> xc_cpuid_apply_policy into callers.
>
> Signed-off-by: Roger Pau Monné
> Reviewed-by: Jan Beulich
> ---
> Changes since v2:
> - Use 'r' for xc_cpuid_apply_policy retu
sysconfig files are not mandatory.
Adjust xenconsoled.service to handle a missing sysconfig file by
prepending a dash to the to-be-sourced filename.
Signed-off-by: Olaf Hering
---
tools/hotplug/Linux/systemd/xenconsoled.service.in | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git
On 04/05/2021 13:43, Jan Beulich wrote:
> On 03.05.2021 17:39, Andrew Cooper wrote:
>> Make use of the new xstate_uncompressed_size() helper rather than maintaining
>> the running calculation while accumulating feature components.
>>
>> The rest of the CPUID data can come direct from the raw cpuid
--log does not take a file, it specifies what is supposed to be logged.
Signed-off-by: Olaf Hering
---
tools/hotplug/NetBSD/rc.d/xencommons.in | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/tools/hotplug/NetBSD/rc.d/xencommons.in
b/tools/hotplug/NetBSD/rc.d/xencommons.in
in
--log does not take a file, it specifies what is supposed to be logged.
Signed-off-by: Olaf Hering
---
tools/hotplug/FreeBSD/rc.d/xencommons.in | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/tools/hotplug/FreeBSD/rc.d/xencommons.in
b/tools/hotplug/FreeBSD/rc.d/xencommons.in
On Tue, May 04, 2021 at 12:59:43PM +0100, Andrew Cooper wrote:
> On 30/04/2021 16:52, Roger Pau Monne wrote:
> > @@ -822,3 +825,28 @@ int xc_cpu_policy_serialise(xc_interface *xch, const
> > xc_cpu_policy_t p,
> > errno = 0;
> > return 0;
> > }
> > +
> > +int xc_cpu_policy_get_cpuid(xc_
flight 161700 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/161700/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-qemuu-rhel6hvm-intel 7 xen-install fail REGR. vs. 152332
test-amd64-i386-xl-
Jason Andryuk, le mar. 04 mai 2021 08:48:42 -0400, a ecrit:
> GetRandom passthrough currently fails when using vtpmmgr with a hardware
> TPM 2.0.
> vtpmmgr (8): INFO[VTPM]: Passthrough: TPM_GetRandom
> vtpm (12): vtpm_cmd.c:120: Error: TPM_GetRandom() failed with error code (30)
>
> When running o
> On 4 May 2021, at 14:28, Jan Beulich wrote:
>
> On 04.05.2021 15:09, Luca Fancellu wrote:
>>> On 4 May 2021, at 12:48, Jan Beulich wrote:
>>> On 04.05.2021 11:46, Luca Fancellu wrote:
@@ -451,11 +466,6 @@ DEFINE_XEN_GUEST_HANDLE(gnttab_transfer_t);
* bytes to be copied.
*/
>>
This serie introduce doxygen in the sphinx html docs generation.
One benefit is to keep most of the documentation in the source
files of xen so that it's more maintainable, on the other hand
there are some limitation of doxygen that should be addressed
modifying the current codebase (for example do
Modification to include/public/grant_table.h:
1) Add doxygen tags to:
- Create Grant tables section
- include variables in the generated documentation
- Used @keepindent/@endkeepindent to enclose comment
section that are indented using spaces, to keep
the indentation.
2) Add .rst file for
Create a skeleton for the documentation about hypercalls
Signed-off-by: Luca Fancellu
---
.gitignore | 1 +
docs/Makefile | 4
docs/hypercall-interfaces/arm32.rst| 4
docs/hypercall-interfaces/arm64.rst| 32 +++
On 04.05.2021 15:09, Luca Fancellu wrote:
>> On 4 May 2021, at 12:48, Jan Beulich wrote:
>> On 04.05.2021 11:46, Luca Fancellu wrote:
>>> @@ -451,11 +466,6 @@ DEFINE_XEN_GUEST_HANDLE(gnttab_transfer_t);
>>> * bytes to be copied.
>>> */
>>>
>>> -#define _GNTCOPY_source_gref (0)
>>> -#define
Jason Andryuk, le mar. 04 mai 2021 08:48:41 -0400, a ecrit:
> vtpmmgr uses the default, weak app_shutdown, which immediately calls the
> shutdown hypercall. This short circuits the vtpmmgr clean up logic. We
> need to perform the clean up to actually Flush our key out of the tpm.
>
> Setting do_
Jason Andryuk, le mar. 04 mai 2021 08:48:40 -0400, a ecrit:
> We're only flushing 2 transients, but there are 3 handles. Use <= to also
> flush the third handle.
>
> The number of transient handles/keys is hardware dependent, so this
> should query for the limit. And assignment of handles is ass
Jason Andryuk, le mar. 04 mai 2021 08:48:39 -0400, a ecrit:
> Remove our key so it isn't left in the TPM for someone to come along
> after vtpmmgr shutsdown.
>
> Signed-off-by: Jason Andryuk
Reviewed-by: Samuel Thibault
> ---
> stubdom/vtpmmgr/init.c | 8
> 1 file changed, 8 insertio
Jason Andryuk, le mar. 04 mai 2021 08:48:38 -0400, a ecrit:
> Reposition vtpmmgr_shutdown so it can call flush_tpm2 without a forward
> declaration.
>
> Signed-off-by: Jason Andryuk
Reviewed-by: Samuel Thibault
> ---
> stubdom/vtpmmgr/init.c | 28 ++--
> 1 file changed
Jason Andryuk, le mar. 04 mai 2021 08:48:37 -0400, a ecrit:
> Bypass taking ownership of the TPM2 if an srk_handle is specified.
>
> This srk_handle must be usable with Null auth for the time being.
>
> Signed-off-by: Jason Andryuk
> ---
> docs/man/xen-vtpmmgr.7.pod | 7 +++
> stubdom/vtpm
> On 4 May 2021, at 12:48, Jan Beulich wrote:
>
> On 04.05.2021 11:46, Luca Fancellu wrote:
>> @@ -451,11 +466,6 @@ DEFINE_XEN_GUEST_HANDLE(gnttab_transfer_t);
>> * bytes to be copied.
>> */
>>
>> -#define _GNTCOPY_source_gref (0)
>> -#define GNTCOPY_source_gref (1<<_GNTCOPY_sour
Jason Andryuk, le mar. 04 mai 2021 08:48:36 -0400, a ecrit:
> vtpmmgr was changed to print size_t with the %z modifier, but newlib
> isn't compiled with %z support. So you get output like:
>
> root seal: zu; sector of 13: zu
> root: zu v=zu
> itree: 36; sector of 112: zu
> group: zu v=zu id=zu md
Jason Andryuk, le mar. 04 mai 2021 08:48:35 -0400, a ecrit:
> tpm_get_error_name returns "Unknown Error Code" when an error string
> is not defined. In that case, we should print the Error Code so it can
> be looked up offline. tpm_get_error_name returns a const string, so
> just have the two cal
Hi All-
For better collaboration with the Xen Project Community on content and PR
ideas, we are reviving the PR email alias.
The list should be used for:
-
New blog ideas
-
Volunteering for a developer profile (details below)
-
To discuss anything new or newsworthy that can
On 03.05.2021 17:39, Andrew Cooper wrote:
> If max leaf is greater than 0xd but xsave not available to the guest, then the
> current XSAVE size should not be filled in. This is a latent bug for now as
> the guest max leaf is 0xd, but will become problematic in the future.
>
> The comment concerni
GetRandom passthrough currently fails when using vtpmmgr with a hardware
TPM 2.0.
vtpmmgr (8): INFO[VTPM]: Passthrough: TPM_GetRandom
vtpm (12): vtpm_cmd.c:120: Error: TPM_GetRandom() failed with error code (30)
When running on TPM 2.0 hardware, vtpmmgr needs to convert the TPM 1.2
TPM_ORD_GetRand
vtpmmgr uses the default, weak app_shutdown, which immediately calls the
shutdown hypercall. This short circuits the vtpmmgr clean up logic. We
need to perform the clean up to actually Flush our key out of the tpm.
Setting do_shutdown is one step in that direction, but vtpmmgr will most
likely b
We're only flushing 2 transients, but there are 3 handles. Use <= to also
flush the third handle.
The number of transient handles/keys is hardware dependent, so this
should query for the limit. And assignment of handles is assumed to be
sequential from the minimum. That may not be guaranteed, b
Remove our key so it isn't left in the TPM for someone to come along
after vtpmmgr shutsdown.
Signed-off-by: Jason Andryuk
---
stubdom/vtpmmgr/init.c | 8
1 file changed, 8 insertions(+)
diff --git a/stubdom/vtpmmgr/init.c b/stubdom/vtpmmgr/init.c
index 569b0dd1dc..d9fefa9be6 100644
--
Reposition vtpmmgr_shutdown so it can call flush_tpm2 without a forward
declaration.
Signed-off-by: Jason Andryuk
---
stubdom/vtpmmgr/init.c | 28 ++--
1 file changed, 14 insertions(+), 14 deletions(-)
diff --git a/stubdom/vtpmmgr/init.c b/stubdom/vtpmmgr/init.c
index c0
Bypass taking ownership of the TPM2 if an srk_handle is specified.
This srk_handle must be usable with Null auth for the time being.
Signed-off-by: Jason Andryuk
---
docs/man/xen-vtpmmgr.7.pod | 7 +++
stubdom/vtpmmgr/init.c | 11 ++-
2 files changed, 17 insertions(+), 1 deleti
vtpmmgr was changed to print size_t with the %z modifier, but newlib
isn't compiled with %z support. So you get output like:
root seal: zu; sector of 13: zu
root: zu v=zu
itree: 36; sector of 112: zu
group: zu v=zu id=zu md=zu
group seal: zu; 5 in parent: zu; sector of 13: zu
vtpm: zu+zu; sector
tpm_get_error_name returns "Unknown Error Code" when an error string
is not defined. In that case, we should print the Error Code so it can
be looked up offline. tpm_get_error_name returns a const string, so
just have the two callers always print the error code so it is always
available.
Signed-
The vtpmmgr TPM 2.0 support is incomplete. Add a warning about that to
the documentation so others don't have to work through discovering it is
broken.
Signed-off-by: Jason Andryuk
---
docs/man/xen-vtpmmgr.7.pod | 11 +++
1 file changed, 11 insertions(+)
diff --git a/docs/man/xen-vtpmm
vtpmmgr TPM 2.0 support is incomplete. There is no code to save the
tpm2 keys generated by the vtpmmgr, so it's impossible to restore vtpm
state with tpm2. The vtpmmgr also issues TPM 1.2 commands to the TPM
2.0 hardware which naturally fails. Dag reported this [1][2], and I
independently re-dis
On 04.05.2021 14:22, Andrew Cooper wrote:
> On 04/05/2021 13:20, Jan Beulich wrote:
>> On 03.05.2021 17:39, Andrew Cooper wrote:
>>> @@ -568,16 +568,38 @@ static unsigned int hw_uncompressed_size(uint64_t
>>> xcr0)
>>> return size;
>>> }
>>>
>>> -/* Fastpath for common xstate size requests
On 03.05.2021 17:39, Andrew Cooper wrote:
> Make use of the new xstate_uncompressed_size() helper rather than maintaining
> the running calculation while accumulating feature components.
>
> The rest of the CPUID data can come direct from the raw cpuid policy. All
> per-component data forms an AB
On 04/05/2021 13:20, Jan Beulich wrote:
> On 03.05.2021 17:39, Andrew Cooper wrote:
>> @@ -568,16 +568,38 @@ static unsigned int hw_uncompressed_size(uint64_t xcr0)
>> return size;
>> }
>>
>> -/* Fastpath for common xstate size requests, avoiding reloads of xcr0. */
>> -unsigned int xstate_
On 03.05.2021 17:39, Andrew Cooper wrote:
> @@ -568,16 +568,38 @@ static unsigned int hw_uncompressed_size(uint64_t xcr0)
> return size;
> }
>
> -/* Fastpath for common xstate size requests, avoiding reloads of xcr0. */
> -unsigned int xstate_ctxt_size(u64 xcr0)
> +unsigned int xstate_uncom
On 04/05/2021 13:08, Jan Beulich wrote:
> On 03.05.2021 20:17, Andrew Cooper wrote:
>> On 03/05/2021 16:39, Andrew Cooper wrote:
>>> We're soon going to need a compressed helper of the same form.
>>>
>>> The size of the uncompressed image is a strictly a property of the highest
>>> user state. Thi
On 04.05.2021 13:56, Roger Pau Monné wrote:
> On Mon, May 03, 2021 at 12:43:08PM +0200, Jan Beulich wrote:
>> On 30.04.2021 17:52, Roger Pau Monne wrote:
>>> +/* Only level featuresets so far. */
>>
>> I have to admit that I don't think I see all the implications from
>> this implementation restric
On 03.05.2021 20:17, Andrew Cooper wrote:
> On 03/05/2021 16:39, Andrew Cooper wrote:
>> We're soon going to need a compressed helper of the same form.
>>
>> The size of the uncompressed image is a strictly a property of the highest
>> user state. This can be calculated trivially with xstate_offse
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Xen Security Advisory CVE-2021-28689 / XSA-370
version 2
x86: Speculative vulnerabilities with bare (non-shim) 32-bit PV guests
UPDATES IN VERSION 2
Note that the patch is docs-onl
On 30/04/2021 16:52, Roger Pau Monne wrote:
> @@ -822,3 +825,28 @@ int xc_cpu_policy_serialise(xc_interface *xch, const
> xc_cpu_policy_t p,
> errno = 0;
> return 0;
> }
> +
> +int xc_cpu_policy_get_cpuid(xc_interface *xch, const xc_cpu_policy_t policy,
> +ui
On Tue, May 04, 2021 at 01:40:11PM +0200, Jan Beulich wrote:
> On 04.05.2021 12:56, Roger Pau Monné wrote:
> > On Mon, May 03, 2021 at 12:41:29PM +0200, Jan Beulich wrote:
> >> On 30.04.2021 17:52, Roger Pau Monne wrote:
> >>> --- a/tools/libs/guest/xg_cpuid_x86.c
> >>> +++ b/tools/libs/guest/xg_cp
On Mon, May 03, 2021 at 12:43:08PM +0200, Jan Beulich wrote:
> On 30.04.2021 17:52, Roger Pau Monne wrote:
> > Introduce a helper to obtain a compatible cpu policy based on two
> > input cpu policies. Currently this is done by and'ing all CPUID
> > feature leaves and MSR entries, except for MSR_ARC
On 03.05.2021 17:39, Andrew Cooper wrote:
> The latter is a more descriptive name, as it explicitly highlights the query
> from hardware.
>
> Simplify the internal logic using cpuid_count_ebx(), and drop the curr/max
> assertion as this property is guaranteed by the x86 ISA.
>
> Signed-off-by: An
On 03.05.2021 17:39, Andrew Cooper wrote:
> XSETBV is an expensive instruction as, amongst other things, it involves
> reconfiguring the instruction decode at the frontend of the pipeline.
>
> We have several paths which reconfigure %xcr0 in quick succession (the context
> switch path has 5, inclu
On 04.05.2021 11:46, Luca Fancellu wrote:
> @@ -451,11 +466,6 @@ DEFINE_XEN_GUEST_HANDLE(gnttab_transfer_t);
> * bytes to be copied.
> */
>
> -#define _GNTCOPY_source_gref (0)
> -#define GNTCOPY_source_gref (1<<_GNTCOPY_source_gref)
> -#define _GNTCOPY_dest_gref(1)
> -#defi
On 20.04.2021 16:07, Roger Pau Monne wrote:
> There's no caller anymore that cares about the injected vector, so
> drop the returned vector from the function.
>
> No functional change indented.
>
> Signed-off-by: Roger Pau Monné
Acked-by: Jan Beulich
On 20.04.2021 16:07, Roger Pau Monne wrote:
> There are no callers anymore passing a get_vector function pointer to
> hvm_isa_irq_assert, so drop the parameter.
>
> No functional change expected.
>
> Signed-off-by: Roger Pau Monné
Acked-by: Jan Beulich
On 04.05.2021 12:56, Roger Pau Monné wrote:
> On Mon, May 03, 2021 at 12:41:29PM +0200, Jan Beulich wrote:
>> On 30.04.2021 17:52, Roger Pau Monne wrote:
>>> --- a/tools/libs/guest/xg_cpuid_x86.c
>>> +++ b/tools/libs/guest/xg_cpuid_x86.c
>>> @@ -850,3 +850,45 @@ int xc_cpu_policy_get_cpuid(xc_inter
flight 161758 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/161758/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-libvirt 15 migrate-support-checkfail never pass
test-armhf-armhf-xl 1
On Tue, May 4, 2021 at 4:03 AM Jan Beulich wrote:
>
> On 03.05.2021 21:28, Jason Andryuk wrote:
> > Add xc_set_cpufreq_hwp to allow calling xen_systctl_pm_op
> > SET_CPUFREQ_HWP.
> >
> > Signed-off-by: Jason Andryuk
> >
> > ---
> > Am I allowed to do set_hwp = *set_hwp struct assignment?
>
> I'm
On 20.04.2021 16:07, Roger Pau Monne wrote:
> @@ -295,188 +248,153 @@ static void pt_irq_fired(struct vcpu *v, struct
> periodic_time *pt)
> list_del(&pt->list);
> pt->on_list = false;
> pt->pending_intr_nr = 0;
> +
> +return;
> }
> -else if ( mode_i
On Mon, May 03, 2021 at 12:41:29PM +0200, Jan Beulich wrote:
> On 30.04.2021 17:52, Roger Pau Monne wrote:
> > Introduce an interface that returns a specific MSR entry from a cpu
> > policy in xen_msr_entry_t format. Provide a helper to perform a binary
> > search against an array of MSR entries.
>
flight 161631 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/161631/
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
1 - 100 of 114 matches
Mail list logo
