flight 161848 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/161848/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-libvirt 6 libvirt-buildfail REGR. vs. 151777
build-armhf-libvirt
branch xen-unstable
xenbranch xen-unstable
job test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm
testid debian-hvm-install
Tree: libvirt git://xenbits.xen.org/libvirt.git
Tree: libvirt_keycodemapdb https://gitlab.com/keycodemap/keycodemapdb.git
Tree: linux git://xenbits.xen.org/linux-pvops.git
Tre
On Fri, Apr 23, 2021 at 08:04:57AM +0100, Luca Fancellu wrote:
> > On 23 Apr 2021, at 08:00, Juergen Gross wrote:
> > On 23.04.21 08:55, Luca Fancellu wrote:
> >>> On 23 Apr 2021, at 06:40, Juergen Gross wrote:
> >>>
> >>> Commit d3eeb1d77c5d0af ("xen/gntdev: use mmu_interval_notifier_insert")
>
Hi all,
On 07/05/2021 22:00, osstest service owner wrote:
flight 161829 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/161829/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
[...]
test-arm64-arm64-examine
flight 161832 linux-5.4 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/161832/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-xl-qemuu-win7-amd64 19 guest-stopfail like 161600
test-amd64-i386-xl-qemut-win7-amd64 19
flight 161841 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/161841/
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
flight 161829 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/161829/
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-
Jan,
I mulled over your feedback and I think I can now see your reservations
with this series.
I'm wondering if the long-term goal of using the xen mb1/mb2 binary as the
basis for creating a EFI loadable mb1/mb2 payload is actually the wrong
approach.
After all, I do not see a feasible way to ma
flight 161826 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/161826/
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
On 5/6/21 9:59 AM, Jason Andryuk wrote:
> Reposition vtpmmgr_shutdown so it can call flush_tpm2 without a forward
> declaration.
>
> Signed-off-by: Jason Andryuk
> Reviewed-by: Samuel Thibault
> ---
Reviewed-by: Daniel P. Smith
> stubdom/vtpmmgr/init.c | 28 ++--
> 1
> On 6 May 2021, at 17:12, Julien Grall wrote:
>
> From: Julien Grall
>
> ASAN reported one issue when Live Updating Xenstored:
>
> =
> ==873==ERROR: AddressSanitizer: stack-buffer-overflow on address
> 0x7ffc194f53e0 at pc 0x
On 5/4/21 8:48 AM, Jason Andryuk wrote:
> 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
On 5/4/21 8:48 AM, Jason Andryuk wrote:
> 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 th
On 5/4/21 8:48 AM, 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
> ---
Reviewed-by: Daniel P. Smith
> docs/man/xen-vtpmmgr.7.p
On 07.05.2021 16:59, Xia, Hongyan wrote:
> On Fri, 2021-05-07 at 14:15 +0200, Jan Beulich wrote:
>> On 07.05.2021 13:44, Julien Grall wrote:
> [...]
>>>
>>> It is a known convenient place. It may be difficult to find a
>>> similar
>>> spot on host that have been long-running.
>>
>> I'm not convinc
Signed-off-by: Tamas K Lengyel
---
tools/misc/Makefile | 2 +-
tools/misc/xen-vmtrace.c | 12 +---
2 files changed, 10 insertions(+), 4 deletions(-)
diff --git a/tools/misc/Makefile b/tools/misc/Makefile
index 2b683819d4..c32c42d546 100644
--- a/tools/misc/Makefile
+++ b/tools/misc
On 5/7/21 5:20 AM, Jan Beulich wrote:
> In SILO mode restrictions for inter-domain communication should apply
> here along the lines of those for evtchn and gnttab.
>
> Signed-off-by: Jan Beulich
Reviewed-by: Daniel P. Smith
> ---
> Really I was first thinking about the shim: Shouldn't that pr
On Fri, 2021-05-07 at 14:15 +0200, Jan Beulich wrote:
> On 07.05.2021 13:44, Julien Grall wrote:
[...]
> >
> > It is a known convenient place. It may be difficult to find a
> > similar
> > spot on host that have been long-running.
>
> I'm not convinced: If it was placed in the kexec area at a 2M
flight 161825 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/161825/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-xl-qemut-win7-amd64 19 guest-stopfail like 161811
test-armhf-armhf-libvirt 16 save
flight 161831 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/161831/
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 07.05.2021 13:44, Julien Grall wrote:
> On 07/05/2021 10:52, Jan Beulich wrote:
>> On 06.05.2021 12:42, Julien Grall wrote:
>>> +## Trigger
>>> +
>>> +Live update is built on top of the kexec interface to prepare the command
>>> line,
>>> +load xen#2 and trigger the operation. A new kexec type
Hi Jan,
On 07/05/2021 10:52, Jan Beulich wrote:
On 06.05.2021 12:42, Julien Grall wrote:
+## High-level overview
+
+Xen has a framework to bring a new image of the Xen hypervisor in memory using
+kexec. The existing framework does not meet the baseline functionality for
+Live Update, since kex
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 directly.
Remove xc_cpuid_apply_policy.
Signed-off-by: Roger Pau Monné
Revi
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 implement it's own private type for storing CPUID
information, which currently m
Rename xc_cpuid_xend_policy to xc_cpu_policy_apply_cpuid and make it
public. Modify the function internally to use the new xc_cpu_policy_*
set of functions. Also don't apply the passed policy to a domain
directly, and instead modify the provided xc_cpu_policy_t. The caller
will be responsible of ap
Pull out the code from xc_cpuid_apply_policy that applies a featureset
to a cpu policy and place it on it's own standalone function that's
part of the public interface.
No functional change intended.
Signed-off-by: Roger Pau Monné
---
tools/include/xenguest.h| 5 ++
tools/libs/guest/xg
This logic is pulled out from xc_cpuid_apply_policy and placed into a
separate helper. Note the legacy part of the introduced function, as
long term Xen will require a proper topology setter function capable
of expressing a more diverse set of topologies.
No functional change intended.
Signed-off
Older Xen versions used to expose some CPUID bits which are no longer
exposed by default. In order to keep a compatible behavior with
guests migrated from versions of Xen that don't encode the CPUID data
on the migration stream introduce a function that sets the same bits
as older Xen versions.
Th
Introduce an interface that returns a specific MSR entry from a cpu
policy in xen_msr_entry_t format.
This is useful to callers can peek data from the opaque
xc_cpu_policy_t type.
No caller of the interface introduced on this patch.
Signed-off-by: Roger Pau Monné
---
Changes since v3:
- Use x8
Use such helper in order to replace the code in
x86_msr_copy_from_buffer. Note the introduced helper should not be
directly called and instead x86_msr_get_entry should be used that will
properly deal with const and non-const inputs.
Note this requires making the raw fields uint64_t so that it can
Introduce an interface that returns a specific leaf/subleaf from a cpu
policy in xen_cpuid_leaf_t format.
This is useful to callers can peek data from the opaque
xc_cpu_policy_t type.
No caller of the interface introduced on this patch.
Note that callers of find_leaf need to be slightly adjusted
Introduce a helper based on the current Xen guest_cpuid code in order
to fetch a cpuid leaf from a policy. The newly introduced function in
cpuid.c should not be directly called and instead the provided
x86_cpuid_get_leaf macro should be used that will properly deal with
const and non-const inputs.
Hello,
The following series introduces a new CPUID/MSR interface for the
xenguest library. Such interface handles both CPUID and MSRs using the
same opaque object, and provides some helpers for the user to peek or
modify such data without exposing the backing type. This is useful for
future develo
On 07.05.2021 12:26, Roger Pau Monné wrote:
> On Thu, May 06, 2021 at 01:47:52PM +0100, George Dunlap wrote:
>> --- a/xen/arch/x86/Kconfig
>> +++ b/xen/arch/x86/Kconfig
>> @@ -55,7 +55,7 @@ config PV
>> config PV32
>> bool "Support for 32bit PV guests"
>> depends on PV
>> -default y
On Thu, May 06, 2021 at 01:47:52PM +0100, George Dunlap wrote:
> The support status of 32-bit guests doesn't seem particularly useful.
>
> With it changed to fully unsupported outside of PV-shim, adjust the PV32
> Kconfig default accordingly.
>
> Reported-by: Jann Horn
> Signed-off-by: George Du
On Fri, May 07, 2021 at 11:17:26AM +0200, Jan Beulich wrote:
> On 07.05.2021 11:08, Roger Pau Monné wrote:
> > On Fri, May 07, 2021 at 10:34:24AM +0200, Jan Beulich wrote:
> >> On 07.05.2021 10:21, Roger Pau Monné wrote:
> >>> On Fri, May 07, 2021 at 08:22:38AM +0200, Jan Beulich wrote:
> In t
Hi Hongyan,
On 07/05/2021 10:18, Hongyan Xia wrote:
On Thu, 2021-05-06 at 11:42 +0100, Julien Grall wrote:
From: Julien Grall
Administrators often require updating the Xen hypervisor to address
security vulnerabilities, introduce new features, or fix software
defects.
Currently, we offer th
flight 161821 xen-4.12-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/161821/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-qcow219 guest-localmigrate/x10 fail REGR. vs. 159418
Tests which ar
On 06.05.2021 12:42, Julien Grall wrote:
> +## High-level overview
> +
> +Xen has a framework to bring a new image of the Xen hypervisor in memory
> using
> +kexec. The existing framework does not meet the baseline functionality for
> +Live Update, since kexec results in a restart for the hypervi
Jan Beulich writes ("Re: [xen-4.12-testing test] 161776: regressions - FAIL"):
> I did consider this as an option, but I don't think it's this simple.
> Neither 4.11 and older nor 4.13 and newer exhibit such behavior. In
> fact in 4.12 we appear to see pushes blocked now because there was a
> succe
In SILO mode restrictions for inter-domain communication should apply
here along the lines of those for evtchn and gnttab.
Signed-off-by: Jan Beulich
---
Really I was first thinking about the shim: Shouldn't that proxy argo
requests just like it does for gnttab ones? It only then occurred to me
t
On Thu, 2021-05-06 at 11:42 +0100, Julien Grall wrote:
> From: Julien Grall
>
> Administrators often require updating the Xen hypervisor to address
> security vulnerabilities, introduce new features, or fix software
> defects.
> Currently, we offer the following methods to perform the update:
>
On 07.05.2021 11:08, Roger Pau Monné wrote:
> On Fri, May 07, 2021 at 10:34:24AM +0200, Jan Beulich wrote:
>> On 07.05.2021 10:21, Roger Pau Monné wrote:
>>> On Fri, May 07, 2021 at 08:22:38AM +0200, Jan Beulich wrote:
In this case compat headers don't get generated (and aren't needed).
T
On Fri, May 07, 2021 at 10:34:24AM +0200, Jan Beulich wrote:
> On 07.05.2021 10:21, Roger Pau Monné wrote:
> > On Fri, May 07, 2021 at 08:22:38AM +0200, Jan Beulich wrote:
> >> In this case compat headers don't get generated (and aren't needed).
> >> The changes made by 527922008bce ("x86: slim dow
This is a partial revert of 540d911c2813 ("x86/CPUID: shrink
max_{,sub}leaf fields according to actual leaf contents"). Andrew points
out that XXX.
Reported-by: Andrew Cooper
Signed-off-by: Jan Beulich
---
Obviously the XXX wants filling in. So far I did not really understand
what bad consequenc
On 07.05.2021 10:21, Roger Pau Monné wrote:
> On Fri, May 07, 2021 at 08:22:38AM +0200, Jan Beulich wrote:
>> In this case compat headers don't get generated (and aren't needed).
>> The changes made by 527922008bce ("x86: slim down hypercall handling
>> when !PV32") also weren't quite sufficient fo
On 07.05.2021 10:24, Hongyan Xia wrote:
> On Thu, 2021-05-06 at 11:42 +0100, Julien Grall wrote:
>> @@ -150,6 +155,8 @@ typedef struct xen_kexec_load_v1 {
>> #define KEXEC_RANGE_MA_EFI_MEMMAP 5 /* machine address and size of
>> * of the EFI Memory Map */
>> #
On 26.04.2021 11:54, Jan Beulich wrote:
> The original commit wasn't quite sufficient: Emptying DEPS is helpful
> only when nothing will get added to it subsequently. xen/Rules.mk will,
> after including the local Makefile, amend DEPS by dependencies for
> objects living in sub-directories though.
On 29.04.2021 11:21, Jan Beulich wrote:
> On 16.04.2021 16:21, Andrew Cooper wrote:
>> On 16/04/2021 14:20, Jan Beulich wrote:
>>> For Intel CPUs we record L3 cache size, hence we should also do so for
>>> AMD and alike.
>>>
>>> While making these additions, also make sure (throughout the function)
On Thu, 2021-05-06 at 11:42 +0100, Julien Grall wrote:
> From: Julien Grall
>
> Unfortunately, the code to support Live Update has already been
> merged in
> Kexec and shipped since 2.0.21. Reserve the IDs used by Kexec before
> they
> end up to be re-used for a different purpose.
>
> This patch
On 29.04.2021 11:24, Jan Beulich wrote:
> On 19.04.2021 17:51, Jan Beulich wrote:
>> On 19.04.2021 17:41, Andrew Cooper wrote:
>>> On 19/04/2021 16:30, Jan Beulich wrote:
All of the sudden, besides .text and .rodata and alike, an always
present .note.gnu.property section has appeared. Thi
On Fri, May 07, 2021 at 08:22:38AM +0200, Jan Beulich wrote:
> In this case compat headers don't get generated (and aren't needed).
> The changes made by 527922008bce ("x86: slim down hypercall handling
> when !PV32") also weren't quite sufficient for this case.
>
> Try to limit #ifdef-ary by intr
On 06.05.2021 18:27, Ian Jackson wrote:
> osstest service owner writes ("[xen-4.12-testing test] 161776: regressions -
> FAIL"):
>> flight 161776 xen-4.12-testing real [real]
>> flight 161806 xen-4.12-testing real-retest [real]
>> http://logs.test-lab.xenproject.org/osstest/logs/161776/
>> http://
flight 161827 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/161827/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-libvirt 6 libvirt-buildfail REGR. vs. 151777
build-armhf-libvirt
On 06/05/2021 11:42, Julien Grall wrote:
From: Julien Grall
Unfortunately, the code to support Live Update has already been merged in
Kexec and shipped since 2.0.21. Reserve the IDs used by Kexec before they
end up to be re-used for a different purpose.
This patch reserves two IDs:
* KEXE
On 05.05.2021 12:49, Andrew Cooper wrote:
> On 04/05/2021 09:42, Jan Beulich wrote:
>> This array can be large when many grant frames are permitted; avoid
>> allocating it when it's not going to be used anyway, by doing this only
>> in gnttab_populate_status_frames(). While the delaying of the resp
On Tue, May 04, 2021 at 06:47:12PM +0100, Andrew Cooper wrote:
> 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/FreeB
57 matches
Mail list logo
