From: Raphael Ning
Unlike xen_kexec_load(), xen_kexec_unload() and xen_kexec_status()
fail to distinguish between normal kexec and Xen Live Update image
types.
Fix that by introducing a new helper function that maps internal
flags to KEXEC_TYPE_*, and using it throughout kexec-xen.c.
flight 160353 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/160353/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-xl-qemut-debianhvm-amd64 7 xen-install fail REGR. vs. 152332
branch xen-unstable
xenbranch xen-unstable
job test-amd64-i386-freebsd10-i386
testid guest-saverestore
Tree: linux git://xenbits.xen.org/linux-pvops.git
Tree: linuxfirmware git://xenbits.xen.org/osstest/linux-firmware.git
Tree: ovmf git://xenbits.xen.org/osstest/ovmf.git
Tree: qemu
flight 160348 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/160348/
Failures :-/ but no regressions.
Regressions which are regarded as allowable (not blocking):
test-armhf-armhf-xl-rtds18 guest-start/debian.repeat fail REGR. vs. 160296
Tests which did not
flight 160352 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/160352/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 0ecdcb6142037dd1cdd08660a2349960bcf0270a
baseline version:
ovmf
On Thu, Mar 18, 2021 at 8:33 AM Daniel P. Smith
wrote:
>
> On 3/16/21 12:09 AM, Daniel P. Smith wrote:
> > All,
> >
> > We have posted[1][2] the design documents for hyperlaunch and would
> > invite attendance at a working group call to discuss two agenda items.
> > The first item is a review of
On 23/03/2021 19:26, Julien Grall wrote:
On 23/03/2021 17:06, Luca Fancellu wrote:
Hi all,
Hi,
Please avoid top posting when answering to a comment. This makes more
difficult to follow.
I have an update, changing the lock introduced by the serie from
spinlock_t to raw_spinlock_t,
flight 160344 xen-4.12-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/160344/
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
flight 160366 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/160366/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-libvirt 15 migrate-support-checkfail never pass
test-arm64-arm64-xl-xsm
On 23/03/2021 17:06, Luca Fancellu wrote:
Hi all,
Hi,
Please avoid top posting when answering to a comment. This makes more
difficult to follow.
I have an update, changing the lock introduced by the serie from spinlock_t to
raw_spinlock_t, changing the lock/unlock function to use the
flight 160350 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/160350/
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 Thu, Mar 18, 2021 at 9:43 AM Roger Pau Monné wrote:
>
> Just took a quick look at it.
>
> On Mon, Mar 15, 2021 at 11:18:13PM -0400, Daniel P. Smith wrote:
> > +
> > +---+---++---+-+-+
> > + | **Xen Dom0** | **Linux** |
On Tue, Mar 23, 2021 at 8:59 AM Michael Young
wrote:
>
>
> On Tue, 23 Mar 2021, Ian Jackson wrote:
>
> > Jan Beulich writes ("Re: [PATCH] xen: Create EFI_VENDOR directory"):
> >> On 23.03.2021 13:34, Jason Andryuk wrote:
> > ...
> >>> On Fedora, RPMs drop EFI binaries directly into
On Tue, Mar 23, 2021 at 6:36 AM Jan Beulich wrote:
> On 23.03.2021 13:34, Jason Andryuk wrote:
> > On Tue, Mar 23, 2021 at 3:23 AM Jan Beulich wrote:
> >>
> >> On 22.03.2021 18:08, Andrew Cooper wrote:
> >>> On 22/03/2021 15:15, Jan Beulich wrote:
> On 22.03.2021 15:59, Andrew Cooper
Jan Beulich writes ("Re: [ANNOUNCE] Xen 4.15 - release status, branching
tomorrow"):
> On 23.03.2021 17:53, Ian Jackson wrote:
> >> One option of course is, like was just done for 4.13.3, to revert.
> >> Iirc Andrew had some thoughts towards making the new piece of code
> >> conditional upon the
Hi all,
I have an update, changing the lock introduced by the serie from spinlock_t to
raw_spinlock_t, changing the lock/unlock function to use the raw_* version and
keeping the BUG_ON(…) (now we can because raw_* implementation disable
interrupts on preempt_rt) the kernel is booting
On 23.03.2021 17:53, Ian Jackson wrote:
> Jan Beulich writes ("Re: [ANNOUNCE] Xen 4.15 - release status, branching
> tomorrow"):
>> On 23.03.2021 16:17, Ian Jackson wrote:
>>> I think it may be time to reconcile ourselves to not fixing this,
>>> and deciding on a suitable plan B. Do we need
Jan Beulich writes ("Re: [ANNOUNCE] Xen 4.15 - release status, branching
tomorrow"):
> On 23.03.2021 16:17, Ian Jackson wrote:
> > I think it may be time to reconcile ourselves to not fixing this,
> > and deciding on a suitable plan B. Do we need to put something in
> > the release notes,
On 23.03.2021 16:17, Ian Jackson wrote:
> I have reviewed my list of blockers and the conversation that followed
> and there are just three areas that are still of concern to me:
>
> * io-apic issue on Ryzen 1800X
>
>Related Qubes issue tracking this:
>
On Tue, 23 Mar 2021, Ian Jackson wrote:
Jan Beulich writes ("Re: [PATCH] xen: Create EFI_VENDOR directory"):
On 23.03.2021 13:34, Jason Andryuk wrote:
...
On Fedora, RPMs drop EFI binaries directly into /boot/efi/EFI/fedora/.
grub, shim, fwupdate and xen are all packaged that way. It
Hi Jason,
Thanks for your hints, unfortunately seems not an init problem because in the
same init configuration I tried the 5.10.23 (preempt_rt) without the Juergen
patch but with the BUG_ON removed and it boots without problem. So seems that
applying the serie does something (on a preempt_rt
(dropping Frédéric Pierret of Qubes, who was CC'd becausd of the Ryzen
issue.)
Roger Pau Monné writes ("Re: [ANNOUNCE] Xen 4.15 - release status, branching
tomorrow"):
> So there's also the series from Andrew to allow Solaris to boot
> without resorting to use the 'msr_relaxed' option:
>
>
On 23.03.2021 14:41, Ian Jackson wrote:
> Jan Beulich writes ("Re: [PATCH] xen: Create EFI_VENDOR directory"):
>> On 23.03.2021 13:34, Jason Andryuk wrote:
> ...
>>> On Fedora, RPMs drop EFI binaries directly into /boot/efi/EFI/fedora/.
>>> grub, shim, fwupdate and xen are all packaged that way.
On Tue, Mar 23, 2021 at 03:17:38PM +, Ian Jackson wrote:
> I think things are looking in reasonable shape.
>
> I intend to branch off the 4.15 stable branch tomorrow. I will then
> turn off debug on that branch. There will be a commit moratorium in
> force for much of the afternoon while
I think things are looking in reasonable shape.
I intend to branch off the 4.15 stable branch tomorrow. I will then
turn off debug on that branch. There will be a commit moratorium in
force for much of the afternoon while the branching is done -
commmitters please check your mail or irc.
Any
flight 160328 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/160328/
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
Jan Beulich writes ("Re: [PATCH] xen: Create EFI_VENDOR directory"):
> On 23.03.2021 13:34, Jason Andryuk wrote:
...
> > On Fedora, RPMs drop EFI binaries directly into /boot/efi/EFI/fedora/.
> > grub, shim, fwupdate and xen are all packaged that way. It seems
> > reasonable to have those
Jan Beulich writes ("Re: [PATCH 0/4][4.15?] VT-d: mostly S3 related
corrections"):
> Thanks Kevin. Ian - what are your thoughts here towards 4.15?
I looked at these four patches.
In general I am not sure of the implications. There are two important
sets of implications: (i) upside: what is the
On 23.03.2021 13:34, Jason Andryuk wrote:
> On Tue, Mar 23, 2021 at 3:23 AM Jan Beulich wrote:
>>
>> On 22.03.2021 18:08, Andrew Cooper wrote:
>>> On 22/03/2021 15:15, Jan Beulich wrote:
On 22.03.2021 15:59, Andrew Cooper wrote:
> On 22/03/2021 14:52, Jan Beulich wrote:
>> On
Jan Beulich writes ("[PATCH 1/4][4.15?] VT-d: correct off-by-1 in
number-of-IOMMUs check"):
> Otherwise, if we really run on a system with this many IOMMUs,
> entering/leaving S3 would overrun iommu_state[].
Release-Acked-by: Ian Jackson
Wei Liu writes ("Re: [PATCH v2 for-4.14] tools: Fix pkg-config file for
libxenstore"):
> On Mon, Mar 22, 2021 at 04:38:47PM +, Andrew Cooper wrote:
> > There are no dependenices on evtchn, ctrl or gnttab.
> >
> > Fixes: 1b008e99 ("tools: provide pkg-config file for libxenstore")
> >
On 23.03.2021 09:12, Tian, Kevin wrote:
>> From: Jan Beulich
>> Sent: Thursday, March 18, 2021 6:12 PM
>>
>> None of these are regressions afaict, so considering how late we are
>> in the 4.15 process, I can see reasons to not take any of these. All
>> of them are backporting candidates though,
On Mon, Mar 22, 2021 at 04:38:47PM +, Andrew Cooper wrote:
> There are no dependenices on evtchn, ctrl or gnttab.
>
> Fixes: 1b008e99 ("tools: provide pkg-config file for libxenstore")
> Signed-off-by: Andrew Cooper
Acked-by: Wei Liu
On Mon, Mar 22, 2021 at 3:09 PM Luca Fancellu wrote:
>
> Hi Juergen,
>
> Yes you are right it was my mistake, as you said to remove the BUG_ON(…) this
> serie
> (https://patchwork.kernel.org/project/xen-devel/cover/20210306161833.4552-1-jgr...@suse.com/)
> is needed, since I’m using yocto I’m
On Tue, Mar 23, 2021 at 3:23 AM Jan Beulich wrote:
>
> On 22.03.2021 18:08, Andrew Cooper wrote:
> > On 22/03/2021 15:15, Jan Beulich wrote:
> >> On 22.03.2021 15:59, Andrew Cooper wrote:
> >>> On 22/03/2021 14:52, Jan Beulich wrote:
> On 22.03.2021 14:33, Jason Andryuk wrote:
> > make
On 23.03.2021 12:29, Roger Pau Monne wrote:
> epte_get_entry_emt will only be called for HVM domains, so the
> is_hvm_domain check is unnecessary. It's a remnant of PVHv1.
>
> Shouldn't result in any functional change.
>
> Signed-off-by: Roger Pau Monné
Reviewed-by: Jan Beulich
epte_get_entry_emt will only be called for HVM domains, so the
is_hvm_domain check is unnecessary. It's a remnant of PVHv1.
Shouldn't result in any functional change.
Signed-off-by: Roger Pau Monné
---
xen/arch/x86/hvm/mtrr.c | 6 ++
1 file changed, 2 insertions(+), 4 deletions(-)
diff
flight 160326 xen-4.13-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/160326/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-xl-qemuu-win7-amd64 19 guest-stopfail like 160154
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 patch.
Signed-off-by: Roger Pau Monné
---
Move the logic from xc_cpu_policy_apply_cpuid into libxl, now that the
xc_cpu_policy_* helpers allow modifying a cpu policy. Having xenguest
parsing CPUID data in xend format was a layering violation, and by
moving such parsing into libxl directly we can get rid of
xc_xend_cpuid, as libxl will now
With the introduction of xc_cpu_policy_get_{system,domain} and
xc_cpu_policy_serialise the current users of
xc_get_{system,domain}_cpu_policy can be switched to the new
interface.
Note that xc_get_{system,domain}_cpu_policy is removed from the public
interface and the functions are made static,
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.
Signed-off-by: Roger Pau Monné
---
To use the new cpu policy interface xc_cpu_policy_set_domain. Note
that xc_set_domain_cpu_policy is removed from the interface and the
function is made static to xg_cpuid_x86.c for it's internal callers.
Signed-off-by: Roger Pau Monné
---
tools/include/xenctrl.h | 5 -
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é
---
This logic is pulled out from xc_cpuid_apply_policy and placed into a
separate helper.
No functional change intended.
Signed-off-by: Roger Pau Monné
---
tools/include/xenctrl.h | 4 +
tools/libs/guest/xg_cpuid_x86.c | 181 +---
2 files changed, 102
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/xenctrl.h | 5 ++
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
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.
Introduce a helper to obtain a compatible cpu policy based on two
input cpu policies. Currently this is done by and'ing all CPUID leaves
and MSR entries, except for MSR_ARCH_CAPABILITIES which has the RSBA
bit or'ed.
The _AC macro is pulled from libxl_internal.h into xen-tools/libs.h
since it's
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é
---
tools/include/xenctrl.h | 4
tools/libs/guest/Makefile
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é
---
tools/include/xenctrl.h
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.
Signed-off-by: Roger Pau Monné
---
Such helper is very similar to the existing xc_set_domain_cpu_policy
interface, but takes an opaque xc_cpu_policy_t instead of arrays of
CPUID leaves and MSRs.
No callers of the interface introduced in this patch.
Signed-off-by: Roger Pau Monné
---
tools/include/xenctrl.h | 2 ++
Such helper allow converting a cpu policy into an array of
xen_cpuid_leaf_t and xen_msr_entry_t elements, which matches the
current interface of the CPUID/MSR functions. This is required in
order for the user to be able to parse the CPUID/MSR data.
No user of the interface introduced in this
Preparatory change to introduce a new set of xc_cpu_policy_* functions
that will replace the current CPUID/MSR helpers.
No functional change intended.
Signed-off-by: Roger Pau Monné
---
tools/include/xenctrl.h | 2 +-
tools/libs/guest/xg_cpuid_x86.c | 6 +++---
Such helper is based on the existing functions to fetch a CPUID and
MSR policies, but uses the xc_cpu_policy_t type to return the data to
the caller.
No user of the interface introduced on the patch.
Signed-off-by: Roger Pau Monné
---
tools/include/xenctrl.h | 2 ++
Such helper is based on the existing functions to fetch a CPUID and
MSR policies, but uses the xc_cpu_policy_t type to return the data to
the caller.
Note some helper functions are introduced, those are split from
xc_cpu_policy_get_system because they will be used by other functions
also.
No
Introduce an opaque type that is used to store the CPUID and MSRs
policies of a domain. Such type uses the existing cpu_policy structure
to store the data, but doesn't expose the type to the users of the
xenguest library.
Introduce an allocation (init) and freeing function (destroy) to
manage the
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
Also change libxl__cpuid_legacy to propagate the error from
xc_cpuid_apply_policy into callers.
Signed-off-by: Roger Pau Monné
---
tools/libs/light/libxl_cpuid.c| 15 +++
tools/libs/light/libxl_create.c | 5 +++--
tools/libs/light/libxl_dom.c | 2 +-
> From: Jan Beulich
> Sent: Thursday, March 18, 2021 6:12 PM
>
> None of these are regressions afaict, so considering how late we are
> in the 4.15 process, I can see reasons to not take any of these. All
> of them are backporting candidates though, imo.
>
> 1: correct off-by-1 in
On 22.03.2021 18:08, Andrew Cooper wrote:
> On 22/03/2021 15:15, Jan Beulich wrote:
>> On 22.03.2021 15:59, Andrew Cooper wrote:
>>> On 22/03/2021 14:52, Jan Beulich wrote:
On 22.03.2021 14:33, Jason Andryuk wrote:
> make install-xen fails when EFI_VENDOR is set (=fedora) with:
>
On 17.03.21 12:04, Roger Pau Monne wrote:
This partially reverts commit 882213990d32fd224340a4533f6318dd152be4b2.
There's no need to special case XEN_UNPOPULATED_ALLOC anymore in order
to correctly size the p2m. The generic memory hotplug option has
already been tied together with the Xen
63 matches
Mail list logo
