Linus,
Please git pull the following tag:
git://git.kernel.org/pub/scm/linux/kernel/git/xen/tip.git
for-linus-5.10b-rc1-tag
xen: branch for v5.10-rc1
It contains:
- 2 small cleanup patches
- A fix for avoiding error messages when initializing MCA banks in a
Xen dom0
- A small series for
flight 155790 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/155790/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-arm64-arm64-xl-xsm 8 xen-boot fail REGR. vs. 155584
Tests which
flight 155777 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/155777/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-xl-qemuu-ws16-amd64 7 xen-install fail REGR. vs. 152332
flight 155786 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/155786/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-arm64-arm64-xl-xsm 8 xen-boot fail REGR. vs. 155584
Tests which
On Tue, Oct 13, 2020 at 06:06:26PM -0700, Stefano Stabellini wrote:
> On Mon, 12 Oct 2020, Elliott Mitchell wrote:
> > I'm on different hardware, but some folks have setup Tianocore for it.
> > According to Documentation/arm64/acpi_object_usage.rst,
> > "Required: DSDT, FADT, GTDT, MADT, MCFG,
On Mon, 12 Oct 2020, Elliott Mitchell wrote:
> On Mon, Oct 12, 2020 at 12:02:14PM -0700, Stefano Stabellini wrote:
> > On Sat, 10 Oct 2020, Julien Grall wrote:
> > > Therefore, I think the code should not try to find the STAO. Instead, it
> > > should check whether the SPCR table is present.
> >
On 13/10/2020 16:54, Jan Beulich wrote:
> On 13.10.2020 17:47, Igor Druzhinin wrote:
>> On 13/10/2020 16:35, Jan Beulich wrote:
>>> On 13.10.2020 14:59, Igor Druzhinin wrote:
On 13/10/2020 13:51, Jan Beulich wrote:
> As a consequence I think we will also want to adjust Xen itself to
>
flight 155770 seabios real [real]
http://logs.test-lab.xenproject.org/osstest/logs/155770/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-xl-qemuu-win7-amd64 19 guest-stopfail like 155136
test-amd64-amd64-xl-qemuu-ws16-amd64 19
flight 155782 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/155782/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-arm64-arm64-xl-xsm 8 xen-boot fail REGR. vs. 155584
Tests which
flight 155769 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/155769/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-qemuu-freebsd11-amd64 13 guest-startfail REGR. vs. 152631
On Tue, Oct 13, 2020 at 12:25:44PM +0100, Christoph Hellwig wrote:
> > - kaddr = kmap(pp);
> > + kaddr = kmap_thread(pp);
> > memcpy(kaddr, vip->vii_immed.vi_immed + offset, PAGE_SIZE);
> > - kunmap(pp);
> > + kunmap_thread(pp);
>
> You only Cced me on this particular patch, which
On Tue, Oct 13, 2020 at 09:01:49PM +0100, Al Viro wrote:
> On Tue, Oct 13, 2020 at 08:36:43PM +0100, Matthew Wilcox wrote:
>
> > static inline void copy_to_highpage(struct page *to, void *vfrom, unsigned
> > int size)
> > {
> > char *vto = kmap_atomic(to);
> >
> > memcpy(vto, vfrom,
On Tue, Oct 13, 2020 at 08:36:43PM +0100, Matthew Wilcox wrote:
> On Tue, Oct 13, 2020 at 11:44:29AM -0700, Dan Williams wrote:
> > On Fri, Oct 9, 2020 at 12:52 PM wrote:
> > >
> > > From: Ira Weiny
> > >
> > > The kmap() calls in this FS are localized to a single thread. To avoid
> > > the
On Tue, Oct 13, 2020 at 08:36:43PM +0100, Matthew Wilcox wrote:
> static inline void copy_to_highpage(struct page *to, void *vfrom, unsigned
> int size)
> {
> char *vto = kmap_atomic(to);
>
> memcpy(vto, vfrom, size);
> kunmap_atomic(vto);
> }
>
> in linux/highmem.h ?
You
On Tue, Oct 13, 2020 at 12:37 PM Matthew Wilcox wrote:
>
> On Tue, Oct 13, 2020 at 11:44:29AM -0700, Dan Williams wrote:
> > On Fri, Oct 9, 2020 at 12:52 PM wrote:
> > >
> > > From: Ira Weiny
> > >
> > > The kmap() calls in this FS are localized to a single thread. To avoid
> > > the over head
On Tue, Oct 13, 2020 at 11:44:29AM -0700, Dan Williams wrote:
> On Fri, Oct 9, 2020 at 12:52 PM wrote:
> >
> > From: Ira Weiny
> >
> > The kmap() calls in this FS are localized to a single thread. To avoid
> > the over head of global PKRS updates use the new kmap_thread() call.
> >
> > Cc:
flight 155779 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/155779/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-arm64-arm64-xl-xsm 8 xen-boot fail REGR. vs. 155584
Tests which
xen-save-devices-state doesn't currently generate a vmdesc, so restore
always triggers "Expected vmdescription section, but got 0". This is
not a problem when restore comes from a file. However, when QEMU runs
in a linux stubdom and comes over a console, EOF is not received. This
causes a delay
On Fri, Oct 9, 2020 at 12:52 PM wrote:
>
> From: Ira Weiny
>
> The kmap() calls in this FS are localized to a single thread. To avoid
> the over head of global PKRS updates use the new kmap_thread() call.
>
> Cc: Nicolas Pitre
> Signed-off-by: Ira Weiny
> ---
> fs/cramfs/inode.c | 10
On Fri, 9 Oct 2020, ira.we...@intel.com wrote:
> From: Ira Weiny
>
> The kmap() calls in this FS are localized to a single thread. To avoid
> the over head of global PKRS updates use the new kmap_thread() call.
>
> Cc: Nicolas Pitre
> Signed-off-by: Ira Weiny
Acked-by: Nicolas Pitre
>
flight 155765 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/155765/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 9380177354387f03c8ff9eadb7ae94aa453b9469
baseline version:
ovmf
flight 155759 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/155759/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
test-amd64-amd64-libvirt-vhd 16 guest-saverestore fail in 155712 pass in 155759
test-amd64-amd64-pair 26
On 13/10/20 16:05, Jason Andryuk wrote:
> Xen was left behind when CpusAccel became mandatory and fails the assert
> in qemu_init_vcpu(). It relied on the same dummy cpu threads as qtest.
> Move the qtest cpu functions to a common location and reuse them for
> Xen.
>
> v2:
> New patch "accel:
flight 155778 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/155778/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-arm64-arm64-xl-xsm 8 xen-boot fail REGR. vs. 155584
Tests which
On 09.10.2020 17:09, Andrew Cooper wrote:
> At the time of XSA-170, the x86 instruction emulator really was broken, and
> would allow arbitrary non-canonical values to be loaded into %rip. This was
> fixed after the embargo by c/s 81d3a0b26c1 "x86emul: limit-check branch
> targets".
>
> However,
On 13.10.2020 17:47, Igor Druzhinin wrote:
> On 13/10/2020 16:35, Jan Beulich wrote:
>> On 13.10.2020 14:59, Igor Druzhinin wrote:
>>> On 13/10/2020 13:51, Jan Beulich wrote:
As a consequence I think we will also want to adjust Xen itself to
automatically disable ACPI when it ends up
On 12.10.2020 15:49, Andrew Cooper wrote:
> All interrupts and exceptions pass a struct cpu_user_regs up into C. This
> contains the legacy vm86 fields from 32bit days, which are beyond the
> hardware-pushed frame.
>
> Accessing these fields is generally illegal, as they are logically out of
>
On 13/10/2020 16:35, Jan Beulich wrote:
> On 13.10.2020 14:59, Igor Druzhinin wrote:
>> On 13/10/2020 13:51, Jan Beulich wrote:
>>> As a consequence I think we will also want to adjust Xen itself to
>>> automatically disable ACPI when it ends up consuming E801 data. Or
>>> alternatively we should
On 13.10.2020 16:47, Roger Pau Monné wrote:
> On Fri, Oct 02, 2020 at 05:25:34PM +0200, Jan Beulich wrote:
>> On 30.09.2020 12:41, Roger Pau Monne wrote:
>>> @@ -119,7 +126,8 @@ void vmsi_deliver_pirq(struct domain *d, const struct
>>> hvm_pirq_dpci *pirq_dpci)
>>>
>>>
On 13.10.2020 16:30, Roger Pau Monné wrote:
> On Fri, Oct 02, 2020 at 11:39:50AM +0200, Jan Beulich wrote:
>> On 30.09.2020 12:41, Roger Pau Monne wrote:
>>> Add a new vlapic_set_irq_callback helper in order to inject a vector
>>> and set a callback to be executed when the guest performs the end
On 13.10.2020 14:59, Igor Druzhinin wrote:
> On 13/10/2020 13:51, Jan Beulich wrote:
>> As a consequence I think we will also want to adjust Xen itself to
>> automatically disable ACPI when it ends up consuming E801 data. Or
>> alternatively we should consider dropping all E801-related code (as
>>
On 13.10.2020 16:13, Jürgen Groß wrote:
> On 13.10.20 16:02, Jan Beulich wrote:
>> On 12.10.2020 11:27, Juergen Gross wrote:
>>> Currently the lock for a single event channel needs to be taken with
>>> interrupts off, which causes deadlocks in some cases.
>>>
>>> Rework the per event channel lock
On 12.10.2020 11:27, Juergen Gross wrote:
> @@ -798,9 +786,11 @@ void send_guest_vcpu_virq(struct vcpu *v, uint32_t virq)
>
> d = v->domain;
> chn = evtchn_from_port(d, port);
> -spin_lock(>lock);
> -evtchn_port_set_pending(d, v->vcpu_id, chn);
> -spin_unlock(>lock);
> +
> On 13 Oct 2020, at 15:04, Jan Beulich wrote:
>
> On 07.10.2020 16:57, Bertrand Marquis wrote:
>> Modify Makefiles using $(XEN_ROOT)/xen to use $(BASEDIR) instead.
>>
>> This is removing the dependency to xen subdirectory preventing using a
>> wrong configuration file when xen subdirectory
On Fri, Oct 02, 2020 at 05:25:34PM +0200, Jan Beulich wrote:
> On 30.09.2020 12:41, Roger Pau Monne wrote:
> > Remove the unconditional call to hvm_dpci_msi_eoi in vlapic_handle_EOI
> > and instead use the newly introduced EOI callback mechanism in order
> > to register a callback for MSI vectors
On 13.10.2020 15:23, Andrew Cooper wrote:
> On 13/10/2020 14:16, Jan Beulich wrote:
>> On 05.10.2020 14:23, Andrew Cooper wrote:
>>> --- a/xen/arch/x86/smpboot.c
>>> +++ b/xen/arch/x86/smpboot.c
>>> @@ -971,16 +971,16 @@ static void cpu_smpboot_free(unsigned int cpu, bool
>>> remove)
>>> if
On Fri, Oct 02, 2020 at 11:39:50AM +0200, Jan Beulich wrote:
> On 30.09.2020 12:41, Roger Pau Monne wrote:
> > Add a new vlapic_set_irq_callback helper in order to inject a vector
> > and set a callback to be executed when the guest performs the end of
> > interrupt acknowledgment.
>
> On v1 I
On 13.10.2020 16:20, Jürgen Groß wrote:
> On 13.10.20 15:58, Jan Beulich wrote:
>> On 12.10.2020 11:27, Juergen Gross wrote:
>>> The queue for a fifo event is depending on the vcpu_id and the
>>> priority of the event. When sending an event it might happen the
>>> event needs to change queues and
On 13.10.20 15:58, Jan Beulich wrote:
On 12.10.2020 11:27, Juergen Gross wrote:
The queue for a fifo event is depending on the vcpu_id and the
priority of the event. When sending an event it might happen the
event needs to change queues and the old queue needs to be kept for
keeping the links
On 13.10.20 16:02, Jan Beulich wrote:
On 12.10.2020 11:27, Juergen Gross wrote:
Currently the lock for a single event channel needs to be taken with
interrupts off, which causes deadlocks in some cases.
Rework the per event channel lock to be non-blocking for the case of
sending an event and
On 13.10.2020 16:08, Roger Pau Monné wrote:
> On Fri, Oct 02, 2020 at 10:48:07AM +0200, Jan Beulich wrote:
>> On 30.09.2020 12:40, Roger Pau Monne wrote:
>>> --- a/xen/arch/x86/hvm/vlapic.c
>>> +++ b/xen/arch/x86/hvm/vlapic.c
>>> @@ -459,13 +459,10 @@ void vlapic_EOI_set(struct vlapic *vlapic)
>>>
On 10/13/20 4:05 PM, Jason Andryuk wrote:
> Xen was broken by commit 1583a3898853 ("cpus: extract out qtest-specific
> code to accel/qtest"). Xen relied on qemu_init_vcpu() calling
> qemu_dummy_start_vcpu() in the default case, but that was replaced by
> g_assert_not_reached().
>
> Add a minimal
On 12.10.2020 16:25, Andrew Cooper wrote:
> Obtaining the microcode revision on Intel CPUs is complicated for backwards
> compatibility reasons. Update apply_microcode() to use a slightly more
> efficient CPUID invocation, now that the documentation has been updated to
> confirm that any CPUID
On Fri, Oct 02, 2020 at 10:48:07AM +0200, Jan Beulich wrote:
> On 30.09.2020 12:40, Roger Pau Monne wrote:
> > --- a/xen/arch/x86/hvm/vlapic.c
> > +++ b/xen/arch/x86/hvm/vlapic.c
> > @@ -459,13 +459,10 @@ void vlapic_EOI_set(struct vlapic *vlapic)
> >
> > void vlapic_handle_EOI(struct vlapic
Xen was broken by commit 1583a3898853 ("cpus: extract out qtest-specific
code to accel/qtest"). Xen relied on qemu_init_vcpu() calling
qemu_dummy_start_vcpu() in the default case, but that was replaced by
g_assert_not_reached().
Add a minimal "CpusAccel" for Xen using the dummy-cpus
Xen was left behind when CpusAccel became mandatory and fails the assert
in qemu_init_vcpu(). It relied on the same dummy cpu threads as qtest.
Move the qtest cpu functions to a common location and reuse them for
Xen.
v2:
New patch "accel: Remove _WIN32 ifdef from qtest-cpus.c"
Use
On 07.10.2020 16:57, Bertrand Marquis wrote:
> Modify Makefiles using $(XEN_ROOT)/xen to use $(BASEDIR) instead.
>
> This is removing the dependency to xen subdirectory preventing using a
> wrong configuration file when xen subdirectory is duplicated for
> compilation tests.
>
> BASEDIR is set
On 07.10.2020 12:20, Roger Pau Monne wrote:
> Windows 8 will attempt to read MSR_IA32_THERM_STATUS and panic if a
> #GP fault is injected as a result:
>
> vmx.c:3035:d8v0 RDMSR 0x019c unimplemented
> d8v0 VIRIDIAN CRASH: 3b c096 f8061de31651 f4088a613720 0
>
> So handle the MSR
On 12.10.2020 11:27, Juergen Gross wrote:
> Currently the lock for a single event channel needs to be taken with
> interrupts off, which causes deadlocks in some cases.
>
> Rework the per event channel lock to be non-blocking for the case of
> sending an event and removing the need for disabling
On 12.10.2020 11:27, Juergen Gross wrote:
> The queue for a fifo event is depending on the vcpu_id and the
> priority of the event. When sending an event it might happen the
> event needs to change queues and the old queue needs to be kept for
> keeping the links between queue elements intact. For
On 06.10.2020 18:23, Roger Pau Monne wrote:
> Currently a PV hardware domain can also be given control over the CPU
> frequency, and such guest is allowed to write to MSR_IA32_PERF_CTL.
> However since commit 322ec7c89f6 the default behavior has been changed
> to reject accesses to not explicitly
On 07.10.2020 18:41, Roger Pau Monné wrote:
> On Wed, Oct 07, 2020 at 01:06:08PM +0100, Andrew Cooper wrote:
>> On 06/10/2020 17:23, Roger Pau Monne wrote:
>>> Currently a PV hardware domain can also be given control over the CPU
>>> frequency, and such guest is allowed to write to
On 13.10.2020 14:00, Andrew Cooper wrote:
> On 28/09/2020 13:31, Jan Beulich wrote:
>> --- a/xen/Makefile
>> +++ b/xen/Makefile
>> @@ -145,7 +145,15 @@ t2 = $(call as-insn,$(CC) -I$(BASEDIR)/i
>> # https://bugs.llvm.org/show_bug.cgi?id=36110
>> t3 = $(call as-insn,$(CC),".macro
On Sun, Oct 11, 2020 at 06:11:39PM -0700, Elliott Mitchell wrote:
> Unexpectedly the environment variable which needs to be passed is
> $LDSHARED and not $LD. Otherwise Python may find the build `ld` instead
> of the host `ld`.
>
> Replace $(LDFLAGS) with $(SHLIB_LDFLAGS) as Python needs shared
On 13.10.2020 13:40, Andrew Cooper wrote:
> (Interestingly, zero length
> alternatives do appear to compile, and this is clearly a bug.)
Why? The replacement code may be intended to be all NOPs.
Jan
On 13/10/2020 14:16, Jan Beulich wrote:
> On 05.10.2020 14:23, Andrew Cooper wrote:
>> --- a/xen/arch/x86/smpboot.c
>> +++ b/xen/arch/x86/smpboot.c
>> @@ -971,16 +971,16 @@ static void cpu_smpboot_free(unsigned int cpu, bool
>> remove)
>> if ( IS_ENABLED(CONFIG_PV32) )
>>
On 05.10.2020 14:23, Andrew Cooper wrote:
> --- a/xen/arch/x86/smpboot.c
> +++ b/xen/arch/x86/smpboot.c
> @@ -971,16 +971,16 @@ static void cpu_smpboot_free(unsigned int cpu, bool
> remove)
> if ( IS_ENABLED(CONFIG_PV32) )
> FREE_XENHEAP_PAGE(per_cpu(compat_gdt, cpu));
>
> +if
flight 155774 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/155774/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-arm64-arm64-xl-xsm 8 xen-boot fail REGR. vs. 155584
Tests which
On 13/10/2020 13:51, Jan Beulich wrote:
> On 13.10.2020 12:50, Igor Druzhinin wrote:
>> ACPI specification contains statements describing memory marked with regular
>> "ACPI data" type as reclaimable by the guest. Although the guest shouldn't
>> really do it if it wants kexec or similar
On 10.10.2020 09:45, Roger Pau Monné wrote:
> On Thu, Oct 08, 2020 at 04:36:47PM +0100, Andrew Cooper wrote:
>> On 08/10/2020 16:15, Roger Pau Monné wrote:
>>> On Wed, Sep 16, 2020 at 03:08:40PM +0200, Jan Beulich wrote:
+void shadow_vram_put_mfn(mfn_t mfn, unsigned int l1f,
+
On 28/09/2020 13:32, Jan Beulich wrote:
> There's no point having every replacement variant to also specify the
> INT3 - just have it once in the base macro. When patching, NOPs will get
> inserted, which are fine to speculate through (until reaching the INT3).
>
> Signed-off-by: Jan Beulich
>
On 13.10.2020 12:50, Igor Druzhinin wrote:
> ACPI specification contains statements describing memory marked with regular
> "ACPI data" type as reclaimable by the guest. Although the guest shouldn't
> really do it if it wants kexec or similar functionality to work, there
> could still be
flight 155758 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/155758/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-xl-qemuu-ws16-amd64 7 xen-install fail REGR. vs. 152332
On 12.10.2020 20:09, George Dunlap wrote:
>> On Oct 7, 2020, at 11:19 AM, Anastasiia Lukianenko
>> wrote:
>> So I want to know if the community is ready to add new formatting
>> options and edit old ones. Below I will give examples of what
>> corrections the checker is currently making (the
On 09.10.2020 16:43, Trammell Hudson wrote:
> Any further thoughts on this patch series? Three out of four of
> them have been reviewed or acked by at least one reviewer, with
> only the last one currently unreviewed.
"unreviewed" isn't correct. I did review it, but I'm opposed to
parts of the
On 28/09/2020 13:31, Jan Beulich wrote:
> Under certain conditions CPUs can speculate into the instruction stream
> past a RET instruction. Guard against this just like 3b7dab93f240
> ("x86/spec-ctrl: Protect against CALL/JMP straight-line speculation")
> did - by inserting an "INT $3" insn. It's
On 05.10.2020 12:39, Andrew Cooper wrote:
> On 24/09/2020 14:10, Paul Durrant wrote:
>> +static int load_shared_info(struct domain *d, struct domain_context *c)
>> +{
>> +struct domain_shared_info_context ctxt;
>> +size_t hdr_size = offsetof(typeof(ctxt), buffer);
>> +unsigned int i;
On 05.10.2020 10:03, Paul Durrant wrote:
>> From: Andrew Cooper
>> Sent: 02 October 2020 22:20
>>
>> On 24/09/2020 14:10, Paul Durrant wrote:
>>> +int domain_save_end(struct domain_context *c)
>>> +{
>>> +struct domain *d = c->domain;
>>> +size_t len = ROUNDUP(c->len, DOMAIN_SAVE_ALIGN) -
On 28/09/2020 13:37, Jan Beulich wrote:
> On 28.09.2020 14:30, Jan Beulich wrote:
>> Commit b586a81b7a90 ("x86/CET: Fix build following c/s 43b98e7190") had
>> to introduce a number of #ifdef-s to make the build work with older tool
>> chains. Introduce an assembler macro covering for tool chains
> - kaddr = kmap(pp);
> + kaddr = kmap_thread(pp);
> memcpy(kaddr, vip->vii_immed.vi_immed + offset, PAGE_SIZE);
> - kunmap(pp);
> + kunmap_thread(pp);
You only Cced me on this particular patch, which means I have absolutely
no idea what kmap_thread and kunmap_thread
On 13.10.2020 13:20, Andrew Cooper wrote:
> On 28/09/2020 13:30, Jan Beulich wrote:
>> Commit b586a81b7a90 ("x86/CET: Fix build following c/s 43b98e7190") had
>> to introduce a number of #ifdef-s to make the build work with older tool
>> chains. Introduce an assembler macro covering for tool
On 13.10.2020 13:04, Andrew Cooper wrote:
> On 28/09/2020 13:29, Jan Beulich wrote:
>> --- a/xen/arch/x86/arch.mk
>> +++ b/xen/arch/x86/arch.mk
>> @@ -20,6 +20,7 @@ $(call as-option-add,CFLAGS,CC,"rdrand %
>> $(call as-option-add,CFLAGS,CC,"rdfsbase %rax",-DHAVE_AS_FSGSBASE)
>> $(call
On 28/09/2020 13:30, Jan Beulich wrote:
> Commit b586a81b7a90 ("x86/CET: Fix build following c/s 43b98e7190") had
> to introduce a number of #ifdef-s to make the build work with older tool
> chains. Introduce an assembler macro covering for tool chains not
> knowing of CET-SS, allowing some
On 28/09/2020 13:29, Jan Beulich wrote:
> --- a/xen/arch/x86/arch.mk
> +++ b/xen/arch/x86/arch.mk
> @@ -20,6 +20,7 @@ $(call as-option-add,CFLAGS,CC,"rdrand %
> $(call as-option-add,CFLAGS,CC,"rdfsbase %rax",-DHAVE_AS_FSGSBASE)
> $(call as-option-add,CFLAGS,CC,"xsaveopt
ACPI specification contains statements describing memory marked with regular
"ACPI data" type as reclaimable by the guest. Although the guest shouldn't
really do it if it wants kexec or similar functionality to work, there
could still be ambiguities in treating these regions as potentially regular
flight 155768 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/155768/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-arm64-arm64-xl-xsm 8 xen-boot fail REGR. vs. 155584
Tests which
On 08.10.2020 18:28, Roger Pau Monné wrote:
> On Mon, Sep 28, 2020 at 02:31:49PM +0200, Jan Beulich wrote:
>> Under certain conditions CPUs can speculate into the instruction stream
>> past a RET instruction. Guard against this just like 3b7dab93f240
>> ("x86/spec-ctrl: Protect against CALL/JMP
On 08.10.2020 16:52, Roger Pau Monné wrote:
> On Wed, Sep 16, 2020 at 03:08:00PM +0200, Jan Beulich wrote:
>> This combination doesn't really make sense (and there likely are more);
>> in particular even if the code built with both options set, HVM guests
>> wouldn't work (and I think one wouldn't
On 08.10.2020 17:15, Roger Pau Monné wrote:
> On Wed, Sep 16, 2020 at 03:08:40PM +0200, Jan Beulich wrote:
>> +void shadow_vram_put_mfn(mfn_t mfn, unsigned int l1f,
>> + mfn_t sl1mfn, const void *sl1e,
>> + const struct domain *d)
>> +{
>> +
> -Original Message-
> From: Jan Beulich
> Sent: 13 October 2020 10:38
> To: p...@xen.org
> Cc: 'Don Slutz' ; xen-de...@lists.xen.org; 'Boris
> Ostrovsky'
> ; 'Ian Jackson' ; 'Jun
> Nakajima'
> ; 'Kevin Tian' ; 'Stefano
> Stabellini'
> ; 'Tim Deegan' ; 'Andrew Cooper'
> ;
> 'Konrad
On 06.10.2020 10:13, Paul Durrant wrote:
>
>
>> -Original Message-
>> From: Jan Beulich
>> Sent: 01 October 2020 15:42
>> To: Don Slutz
>> Cc: xen-de...@lists.xen.org; Boris Ostrovsky ;
>> Ian Jackson
>> ; Jun Nakajima ; Kevin Tian
>> ;
>> Stefano Stabellini ; Tim Deegan ;
>> Andrew
On Wed, Oct 07, 2020 at 06:59:18PM +0100, Ian Jackson wrote:
> From: Ian Jackson
>
> This was for distinguishing the old-style Xenolinux kernels from pvops
> kernels.
>
> We have not actually tested any non-pvops kernels for a very very long
> time. Delete this now because the runvar is
On 10/12/20 10:16 PM, Claudio Fontana wrote:
On 10/12/20 10:07 PM, Jason Andryuk wrote:
Xen was left behind when CpusAccel became mandatory and fails the assert
in qemu_init_vcpu(). It relied on the same dummy cpu threads as qtest.
Move the qtest cpu functions to a common location and reuse
flight 155754 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/155754/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-qemuu-freebsd11-amd64 13 guest-startfail REGR. vs. 152631
flight 155762 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/155762/
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-i386-libvirt
flight 155763 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/155763/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-arm64-arm64-xl-xsm 8 xen-boot fail REGR. vs. 155584
Tests which
flight 155757 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/155757/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 5d1af380d3e4bd840fa324db33ca4f739136e654
baseline version:
ovmf
87 matches
Mail list logo
