On 21.10.2020 17:39, Andrew Cooper wrote:
> On 21/10/2020 14:56, Jan Beulich wrote:
>> On 21.10.2020 15:07, Andrew Cooper wrote:
>>> @@ -4037,6 +4037,9 @@ long do_mmu_update(
>>> break;
>>> rc = mod_l2_entry(va, l2e_from_intpte(req.val), mfn,
>>>
On 21.10.2020 17:23, Roger Pau Monné wrote:
> On Tue, Oct 20, 2020 at 03:51:18PM +0200, Jan Beulich wrote:
>> The set of systems affected by XSA-345 would have been smaller is we had
>> this in place already: When the processor is capable of dealing with
>> mismatched cacheability, there's no extra
On 21.10.2020 17:46, Roger Pau Monné wrote:
> On Tue, Oct 20, 2020 at 04:08:13PM +0200, Jan Beulich wrote:
>> There's no global lock around the updating of this global piece of data.
>> Make use of cmpxchgptr() to avoid two entities racing with their
>> updates.
>>
>> While touching the functionali
xen_debug_interrupt() is specific to 2-level event handling. So don't
register it with fifo event handling being active.
Signed-off-by: Juergen Gross
---
arch/x86/xen/smp.c | 19 +++
arch/x86/xen/xen-ops.h | 2 ++
drivers/xen/events/events_base.c | 6 +++
The struct irq_info of Xen's event handling is used only for two
evtchn_ops functions outside of events_base.c. Those two functions
can easily be switched to avoid that usage.
This allows to make struct irq_info and its related access functions
private to events_base.c.
Signed-off-by: Juergen Gro
On 22.10.2020 00:12, Elliott Mitchell wrote:
> --- a/xen/arch/arm/acpi/domain_build.c
> +++ b/xen/arch/arm/acpi/domain_build.c
> @@ -42,17 +42,18 @@ static int __init acpi_iomem_deny_access(struct domain *d)
> status = acpi_get_table(ACPI_SIG_SPCR, 0,
> (struct acp
Do some cleanups in Xen event handling code.
Juergen Gross (5):
xen: remove no longer used functions
xen/events: make struct irq_info private to events_base.c
xen/events: only register debug interrupt for 2-level events
xen/events: unmask a fifo event channel only if it was masked
Docume
Unmasking an event channel with fifo events channels being used can
require a hypercall to be made, so try to avoid that by checking
whether the event channel was really masked.
Suggested-by: Jan Beulich
Signed-off-by: Juergen Gross
---
drivers/xen/events/events_fifo.c | 3 +++
1 file changed,
The kernel boot parameter xen.fifo_events isn't listed in
Documentation/admin-guide/kernel-parameters.txt. Add it.
Signed-off-by: Juergen Gross
---
Documentation/admin-guide/kernel-parameters.txt | 7 +++
1 file changed, 7 insertions(+)
diff --git a/Documentation/admin-guide/kernel-paramete
With the switch to the lateeoi model for interdomain event channels
some functions are no longer in use. Remove them.
Suggested-by: Jan Beulich
Signed-off-by: Juergen Gross
---
drivers/xen/events/events_base.c | 21 -
include/xen/events.h | 8
2 files c
On 22.10.2020 07:58, osstest service owner wrote:
> flight 156050 xen-unstable real [real]
> flight 156084 xen-unstable real-retest [real]
> http://logs.test-lab.xenproject.org/osstest/logs/156050/
> http://logs.test-lab.xenproject.org/osstest/logs/156084/
>
> Regressions :-(
>
> Tests which did
On 22.10.2020 09:46, Jan Beulich wrote:
> On 22.10.2020 07:58, osstest service owner wrote:
>> flight 156050 xen-unstable real [real]
>> flight 156084 xen-unstable real-retest [real]
>> http://logs.test-lab.xenproject.org/osstest/logs/156050/
>> http://logs.test-lab.xenproject.org/osstest/logs/1560
On 22.10.2020 09:42, Juergen Gross wrote:
> --- a/drivers/xen/events/events_base.c
> +++ b/drivers/xen/events/events_base.c
> @@ -2050,7 +2050,7 @@ void xen_setup_callback_vector(void) {}
> static inline void xen_alloc_callback_vector(void) {}
> #endif
>
> -static bool fifo_events = true;
> +bo
On 22.10.2020 09:42, Juergen Gross wrote:
> --- a/drivers/xen/events/events_fifo.c
> +++ b/drivers/xen/events/events_fifo.c
> @@ -236,6 +236,9 @@ static bool clear_masked_cond(volatile event_word_t *word)
>
> w = *word;
>
> + if (!(w & (1 << EVTCHN_FIFO_MASKED)))
> + retur
On 22.10.2020 09:42, Juergen Gross wrote:
> Do some cleanups in Xen event handling code.
>
> Juergen Gross (5):
> xen: remove no longer used functions
> xen/events: make struct irq_info private to events_base.c
> xen/events: only register debug interrupt for 2-level events
> xen/events: un
On Tue, Oct 20, 2020 at 02:20:46PM +0200, Thomas Zimmermann wrote:
> At least sparc64 requires I/O-specific access to framebuffers. This
> patch updates the fbdev console accordingly.
>
> For drivers with direct access to the framebuffer memory, the callback
> functions in struct fb_ops test for t
On Thu, Oct 22, 2020 at 09:33:27AM +0200, Jan Beulich wrote:
> On 21.10.2020 17:46, Roger Pau Monné wrote:
> > On Tue, Oct 20, 2020 at 04:08:13PM +0200, Jan Beulich wrote:
> >> There's no global lock around the updating of this global piece of data.
> >> Make use of cmpxchgptr() to avoid two entiti
On 22.10.2020 03:23, Daniel P. Smith wrote:
> On 10/21/20 10:34 AM, Hongyan Xia wrote:
>> Also, should idle domain be restricted? IMO the idle domain is Xen
>> itself which mostly bootstraps the system and performs limited work
>> when switched to, and is not something a user (either dom0 or domU)
On 22.10.2020 10:11, Roger Pau Monné wrote:
> On Thu, Oct 22, 2020 at 09:33:27AM +0200, Jan Beulich wrote:
>> On 21.10.2020 17:46, Roger Pau Monné wrote:
>>> On Tue, Oct 20, 2020 at 04:08:13PM +0200, Jan Beulich wrote:
@@ -80,8 +81,9 @@ static uint8_t get_xen_consumer(xen_even
On 22.10.20 09:54, Jan Beulich wrote:
On 22.10.2020 09:42, Juergen Gross wrote:
--- a/drivers/xen/events/events_base.c
+++ b/drivers/xen/events/events_base.c
@@ -2050,7 +2050,7 @@ void xen_setup_callback_vector(void) {}
static inline void xen_alloc_callback_vector(void) {}
#endif
-static
On 22.10.20 09:55, Jan Beulich wrote:
On 22.10.2020 09:42, Juergen Gross wrote:
--- a/drivers/xen/events/events_fifo.c
+++ b/drivers/xen/events/events_fifo.c
@@ -236,6 +236,9 @@ static bool clear_masked_cond(volatile event_word_t *word)
w = *word;
+ if (!(w & (1 << EVTCHN_FIFO_MASKED)))
On Thu, Oct 22, 2020 at 10:15:45AM +0200, Jan Beulich wrote:
> On 22.10.2020 10:11, Roger Pau Monné wrote:
> > On Thu, Oct 22, 2020 at 09:33:27AM +0200, Jan Beulich wrote:
> >> On 21.10.2020 17:46, Roger Pau Monné wrote:
> >>> On Tue, Oct 20, 2020 at 04:08:13PM +0200, Jan Beulich wrote:
> @@ -
On 21/10/2020 12:25, Rahul Singh wrote:
Hello Julien,
Hi Rahul,
On 20 Oct 2020, at 6:03 pm, Julien Grall wrote:
Hi Rahul,
Thank you for the contribution. Lets make sure this attempt to SMMUv3 support
in Xen will be more successful than the other one :).
Yes sure.
I haven't reviewed
Hi
On 22.10.20 10:05, Daniel Vetter wrote:
> On Tue, Oct 20, 2020 at 02:20:46PM +0200, Thomas Zimmermann wrote:
>> At least sparc64 requires I/O-specific access to framebuffers. This
>> patch updates the fbdev console accordingly.
>>
>> For drivers with direct access to the framebuffer memory, the
On Tue, Oct 20, 2020 at 02:20:44PM +0200, Thomas Zimmermann wrote:
> Kernel DRM clients now store their framebuffer address in an instance
> of struct dma_buf_map. Depending on the buffer's location, the address
> refers to system or I/O memory.
>
> Callers of drm_client_buffer_vmap() receive a co
On Thu, Oct 22, 2020 at 10:37:56AM +0200, Thomas Zimmermann wrote:
> Hi
>
> On 22.10.20 10:05, Daniel Vetter wrote:
> > On Tue, Oct 20, 2020 at 02:20:46PM +0200, Thomas Zimmermann wrote:
> >> At least sparc64 requires I/O-specific access to framebuffers. This
> >> patch updates the fbdev console a
On 22.10.2020 10:29, Roger Pau Monné wrote:
> On Thu, Oct 22, 2020 at 10:15:45AM +0200, Jan Beulich wrote:
>> On 22.10.2020 10:11, Roger Pau Monné wrote:
>>> On Thu, Oct 22, 2020 at 09:33:27AM +0200, Jan Beulich wrote:
On 21.10.2020 17:46, Roger Pau Monné wrote:
> On Tue, Oct 20, 2020 at 0
Hi,
On 22/10/2020 02:43, Elliott Mitchell wrote:
Linux requires UEFI support to be enabled on ARM64 devices. While many
ARM64 devices lack ACPI, the writing seems to be on the wall of UEFI/ACPI
potentially taking over. Some common devices may need ACPI table
support.
Presently I think it is w
Hi
On 22.10.20 10:49, Daniel Vetter wrote:
> On Tue, Oct 20, 2020 at 02:20:44PM +0200, Thomas Zimmermann wrote:
>> Kernel DRM clients now store their framebuffer address in an instance
>> of struct dma_buf_map. Depending on the buffer's location, the address
>> refers to system or I/O memory.
>>
>
On Tue, Oct 20, 2020 at 04:08:13PM +0200, Jan Beulich wrote:
> There's no global lock around the updating of this global piece of data.
> Make use of cmpxchgptr() to avoid two entities racing with their
> updates.
>
> While touching the functionality, mark xen_consumers[] read-mostly (or
> else th
On 09.10.20 16:42, Juergen Gross wrote:
When running in lazy TLB mode the currently active page tables might
be the ones of a previous process, e.g. when running a kernel thread.
This can be problematic in case kernel code is being modified via
text_poke() in a kernel thread, and on another proc
On Thu, Oct 22, 2020 at 10:56:15AM +0200, Jan Beulich wrote:
> On 22.10.2020 10:29, Roger Pau Monné wrote:
> > On Thu, Oct 22, 2020 at 10:15:45AM +0200, Jan Beulich wrote:
> >> On 22.10.2020 10:11, Roger Pau Monné wrote:
> >>> On Thu, Oct 22, 2020 at 09:33:27AM +0200, Jan Beulich wrote:
> On 2
Unmasking an event channel with fifo events channels being used can
require a hypercall to be made, so try to avoid that by checking
whether the event channel was really masked.
Suggested-by: Jan Beulich
Signed-off-by: Juergen Gross
Reviewed-by: Jan Beulich
---
V2:
- move test for already unmas
xen_debug_interrupt() is specific to 2-level event handling. So don't
register it with fifo event handling being active.
Signed-off-by: Juergen Gross
Reviewed-by: Jan Beulich
---
V2:
- rename fifo_events variable to xen_fifo_events (Jan Beulich)
---
arch/x86/xen/smp.c | 19 +++
Do some cleanups in Xen event handling code.
Changes in V2:
- addressed comments
Juergen Gross (5):
xen: remove no longer used functions
xen/events: make struct irq_info private to events_base.c
xen/events: only register debug interrupt for 2-level events
xen/events: unmask a fifo event c
The struct irq_info of Xen's event handling is used only for two
evtchn_ops functions outside of events_base.c. Those two functions
can easily be switched to avoid that usage.
This allows to make struct irq_info and its related access functions
private to events_base.c.
Signed-off-by: Juergen Gro
With the switch to the lateeoi model for interdomain event channels
some functions are no longer in use. Remove them.
Suggested-by: Jan Beulich
Signed-off-by: Juergen Gross
Reviewed-by: Jan Beulich
---
drivers/xen/events/events_base.c | 21 -
include/xen/events.h
The kernel boot parameter xen.fifo_events isn't listed in
Documentation/admin-guide/kernel-parameters.txt. Add it.
Signed-off-by: Juergen Gross
Reviewed-by: Jan Beulich
---
Documentation/admin-guide/kernel-parameters.txt | 7 +++
1 file changed, 7 insertions(+)
diff --git a/Documentation/a
flight 156054 xen-4.13-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/156054/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-xl-qemuu-win7-amd64 19 guest-stopfail like 155377
test-amd64-i386-xl-qemuu-win7-am
On Thu, Oct 22, 2020 at 11:18 AM Thomas Zimmermann wrote:
>
> Hi
>
> On 22.10.20 10:49, Daniel Vetter wrote:
> > On Tue, Oct 20, 2020 at 02:20:44PM +0200, Thomas Zimmermann wrote:
> >> Kernel DRM clients now store their framebuffer address in an instance
> >> of struct dma_buf_map. Depending on th
On Tue, Oct 20, 2020 at 04:09:16PM +0200, Jan Beulich wrote:
> The function isn't about an "event" in general, but about a vIRQ. The
> function also failed to honor global vIRQ-s, instead assuming the caller
> would pass vCPU 0 in such a case.
>
> While at it also adjust the
> - types the function
On 22.10.2020 11:49, Juergen Gross wrote:
> @@ -2080,10 +2080,12 @@ void __init xen_init_IRQ(void)
> int ret = -EINVAL;
> evtchn_port_t evtchn;
>
> - if (fifo_events)
> + if (xen_fifo_events)
> ret = xen_evtchn_fifo_init();
> - if (ret < 0)
> + if (ret <
On Thu, Oct 22, 2020 at 11:24:39AM +0200, Jürgen Groß wrote:
> On 09.10.20 16:42, Juergen Gross wrote:
> > When running in lazy TLB mode the currently active page tables might
> > be the ones of a previous process, e.g. when running a kernel thread.
> >
> > This can be problematic in case kernel c
On 22.10.20 12:45, Peter Zijlstra wrote:
On Thu, Oct 22, 2020 at 11:24:39AM +0200, Jürgen Groß wrote:
On 09.10.20 16:42, Juergen Gross wrote:
When running in lazy TLB mode the currently active page tables might
be the ones of a previous process, e.g. when running a kernel thread.
This can be p
On Tue, Oct 20, 2020 at 04:09:41PM +0200, Jan Beulich wrote:
> Some lock wants to be held to make sure the port doesn't change state,
> but there's no point holding the per-domain event lock here. Switch to
> using the finer grained per-channel lock instead.
While true that's a fine grained lock,
(also replying to others in this thread.)
On Wed, 2020-10-21 at 12:21 -0400, Jason Andryuk wrote:
> On Wed, Oct 21, 2020 at 10:35 AM Hongyan Xia wrote:
> >
> > Hi,
>
> ...
> >
> > The first question came up during ongoing work in LiveUpdate. After
> > an
> > LU, the next Xen needs to restore a
On 21/10/2020 15:34, Hongyan Xia wrote:
> The first question came up during ongoing work in LiveUpdate. After an
> LU, the next Xen needs to restore all domains. To do that, some
> hypercalls need to be issued from the idle domain context and
> apparently XSM does not like it.
There is no such thi
On Thu, 22 Oct 2020 04:13:53 -0400 Jan Beulich wrote
> On 22.10.2020 03:23, Daniel P. Smith wrote:
> > On 10/21/20 10:34 AM, Hongyan Xia wrote:
> >> Also, should idle domain be restricted? IMO the idle domain is Xen
> >> itself which mostly bootstraps the system and performs lim
On 22.10.20 12:35, Jan Beulich wrote:
On 22.10.2020 11:49, Juergen Gross wrote:
@@ -2080,10 +2080,12 @@ void __init xen_init_IRQ(void)
int ret = -EINVAL;
evtchn_port_t evtchn;
- if (fifo_events)
+ if (xen_fifo_events)
ret = xen_evtchn_fifo_init();
-
On 22.10.2020 15:09, Jürgen Groß wrote:
> On 22.10.20 12:35, Jan Beulich wrote:
>> On 22.10.2020 11:49, Juergen Gross wrote:
>>> @@ -2080,10 +2080,12 @@ void __init xen_init_IRQ(void)
>>> int ret = -EINVAL;
>>> evtchn_port_t evtchn;
>>>
>>> - if (fifo_events)
>>> + if (xen_fifo_event
On 22.10.2020 13:17, Roger Pau Monné wrote:
> On Tue, Oct 20, 2020 at 04:09:41PM +0200, Jan Beulich wrote:
>> Some lock wants to be held to make sure the port doesn't change state,
>> but there's no point holding the per-domain event lock here. Switch to
>> using the finer grained per-channel lock
The use of simd_packed_int together with no further update to op_bytes
has lead to wrong signaling of #GP(0) for PINSRW without a 16-byte
aligned memory operand. Use simd_none instead and override it after
general decoding with simd_other, like is done for the B/D/Q siblings.
While benign, for con
Running them on a system (or emulator) with AMX support requires this
to be quite a bit larger than 8k, to avoid triggering the assert() in
emul_test_init(). Bump all the way up to 16k right away.
Signed-off-by: Jan Beulich
---
Intel's Software Development Emulator properly reports XSAVE-related
On 22/10/2020 14:39, Jan Beulich wrote:
> Running them on a system (or emulator) with AMX support requires this
> to be quite a bit larger than 8k, to avoid triggering the assert() in
> emul_test_init(). Bump all the way up to 16k right away.
>
> Signed-off-by: Jan Beulich
Acked-by: Andrew Cooper
flight 156082 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/156082/
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 156065 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/156065/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 26442d11e620a9e81c019a24a4ff38441c64ba10
baseline version:
ovmf f82b827c92f77eac8debd
When the host crashes it would sometimes be nice to have additional
debug data available which could be produced via debug keys, but
halting the server for manual intervention might be impossible due to
the need to reboot/kexec rather sooner than later.
Add support for automatic debug key actions
flight 156063 xen-4.14-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/156063/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
test-amd64-i386-qemut-rhel6hvm-intel 14 guest-start/redhat.repeat fail in
156031 pass in 156063
test-amd64
flight 156081 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/156081/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-xsm 6 xen-buildfail REGR. vs. 152631
build-amd64
flight 156085 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/156085/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-xsm 6 xen-buildfail REGR. vs. 156013
build-arm64
On Tue, Oct 13, 2020 at 1:16 PM Paolo Bonzini wrote:
>
> 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 loc
On 22/10/20 17:17, Jason Andryuk wrote:
> On Tue, Oct 13, 2020 at 1:16 PM Paolo Bonzini wrote:
>>
>> 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.
>>>
On Tue, Oct 20, 2020 at 04:10:09PM +0200, Jan Beulich wrote:
> The per-vCPU virq_lock, which is being held anyway, together with there
> not being any call to evtchn_port_set_pending() when v->virq_to_evtchn[]
> is zero, provide sufficient guarantees.
This is also fine because closing the event ch
On 30.09.2020 12:41, Roger Pau Monne wrote:
> --- a/xen/arch/x86/hvm/vlapic.c
> +++ b/xen/arch/x86/hvm/vlapic.c
> @@ -189,7 +189,7 @@ void vlapic_set_irq_callback(struct vlapic *vlapic,
> uint8_t vec, uint8_t trig,
>
> if ( hvm_funcs.update_eoi_exit_bitmap )
> alternative_vcall(hvm
On 22.10.2020 18:00, Roger Pau Monné wrote:
> On Tue, Oct 20, 2020 at 04:10:09PM +0200, Jan Beulich wrote:
>> The per-vCPU virq_lock, which is being held anyway, together with there
>> not being any call to evtchn_port_set_pending() when v->virq_to_evtchn[]
>> is zero, provide sufficient guarantees
flight 156094 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/156094/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-xsm 6 xen-buildfail REGR. vs. 152631
build-amd64
No-one uses this return value yet, so NFC.
Signed-off-by: Ian Jackson
---
pdu-msw | 1 +
1 file changed, 1 insertion(+)
diff --git a/pdu-msw b/pdu-msw
index 196b6c45..2d4ec967 100755
--- a/pdu-msw
+++ b/pdu-msw
@@ -119,6 +119,7 @@ sub get () {
sub show () {
my $mean = get();
printf "
This avoids running the runvar computation loop outside flights.
This is good amongst other things because that loop prints warnings
about undef $flight and $job.
Signed-off-by: Ian Jackson
---
Osstest/JobDB/Executive.pm | 33 ++---
1 file changed, 18 insertions(+), 1
Many of these are fixes to host sharing.
I'm still doing a formal dev test but I expect to push these soon.
Ian Jackson (16):
share in jobdb: Break out $checkconstraints and move call
share in jobdb: Move out-of-flight special case higher up
PDU/IPMI: Retransmit, don't just wait
PDU/MSW:
This must happen after we introduce our new row or it is not
effective!
Signed-off-by: Ian Jackson
---
Osstest/JobDB/Executive.pm | 8 ++--
1 file changed, 6 insertions(+), 2 deletions(-)
diff --git a/Osstest/JobDB/Executive.pm b/Osstest/JobDB/Executive.pm
index f69ce277..071f31f1 100644
--
Nothing in our tree uses this but having it here is useful docs for
the protocol so I shan't just delete it.
Signed-off-by: Ian Jackson
---
pdu-msw | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/pdu-msw b/pdu-msw
index 03b0f342..196b6c45 100755
--- a/pdu-msw
+++ b/pdu-msw
@@
If you don't know this, it's very confusing.
Signed-off-by: Ian Jackson
---
pdu-msw | 1 +
1 file changed, 1 insertion(+)
diff --git a/pdu-msw b/pdu-msw
index d2691567..04b03a22 100755
--- a/pdu-msw
+++ b/pdu-msw
@@ -133,4 +133,5 @@ if (!defined $action) {
print "was: "; show();
set()
The main effect of this is that the transcript will actually show the
new PDU state. Previously we would call show(), but APC PDUs would
normally not change immediately, so the transcript would show the old
state.
This also guards against an unresponsive PDU or a packet getting lost.
I don't thin
We have a system for which
ipmitool -H sabro0m -U root -P -I lanplus power on
seems to work but doesn't take effect the first time.
Retransit each retry.
Signed-off-by: Ian Jackson
---
Osstest/PDU/ipmi.pm | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/Osstest/P
This is going to be useful in a moment.
Signed-off-by: Ian Jackson
---
pdu-msw | 7 ++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/pdu-msw b/pdu-msw
index 04b03a22..58c33952 100755
--- a/pdu-msw
+++ b/pdu-msw
@@ -106,13 +106,18 @@ my @map= (undef, qw(
d
This is going to be useful in a moment.
Signed-off-by: Ian Jackson
---
pdu-msw | 11 ---
1 file changed, 8 insertions(+), 3 deletions(-)
diff --git a/pdu-msw b/pdu-msw
index 58c33952..03b0f342 100755
--- a/pdu-msw
+++ b/pdu-msw
@@ -121,13 +121,17 @@ sub show () {
printf "pdu-msw $d
flight 156091 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/156091/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 24cf72726564eac7ba9abb24f3d05795164d0a70
baseline version:
ovmf 26442d11e620a9e81c019
On Thu, 2020-10-22 at 13:51 +0100, Andrew Cooper wrote:
> On 21/10/2020 15:34, Hongyan Xia wrote:
> > The first question came up during ongoing work in LiveUpdate. After
> > an
> > LU, the next Xen needs to restore all domains. To do that, some
> > hypercalls need to be issued from the idle domain
This changes the way the disk name is constructed but not to any
overall effect.
Signed-off-by: Ian Jackson
---
Osstest/TestSupport.pm | 9 +++--
ts-debian-install | 2 +-
2 files changed, 8 insertions(+), 3 deletions(-)
diff --git a/Osstest/TestSupport.pm b/Osstest/TestSupport.pm
inde
When a ts script is run by hand, for adhoc testing, there is no
OSSTEST_TESTID variable in the environment and the script does not
know it's own step number. Such adhoc runs are not tracked as steps
in the steps table.
For host lifecycle purposes, treat these as ad-hoc out-of-flight uses,
based o
This seems like a sensible rule.
This also prevents the following bizarre behaviour: when a flight has
a handful of jobs that cannot be run at all (eg because it's a
commissioning flight for only hosts of a particular arch), those jobs
can complete quite quickly. Even with a high X value because
When processing an item from the host lifecycle table into the runvar,
we don't want to do all the processing of flight and job. Instead, we
should simply put the ? into the runvar.
Previously this would produce ?: which the flight reporting
code would choke on.
Signed-off-by: Ian Jackson
---
subtask can be NULL. If so, do not include it.
This change fixes a warning and a minor cosmetic defect.
Signed-off-by: Ian Jackson
---
Osstest/Executive.pm | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/Osstest/Executive.pm b/Osstest/Executive.pm
index e3ab1dc3..d95d848d 1
This means that a subsequent test which reuses the same host will not
use the same LVs. This is a good idea because reusing the same LV
names in a subsequent job means relying on the "ad hoc run" cleanup
code. This is a bad idea because that code is rarely tested.
And because, depending on the s
If host allocation failed, or our dependency jobs failed, then we
won't have allocated a host. The host runvar will not be set.
In this case, we want to do nothing.
But we forgot to pass $noneok to selecthost.
Signed-off-by: Ian Jackson
---
ts-host-reuse | 2 +-
1 file changed, 1 insertion(+),
On Thu, Oct 22, 2020 at 09:42:17AM +0200, Jan Beulich wrote:
> On 22.10.2020 00:12, Elliott Mitchell wrote:
> > --- a/xen/arch/arm/acpi/domain_build.c
> > +++ b/xen/arch/arm/acpi/domain_build.c
> > @@ -42,17 +42,18 @@ static int __init acpi_iomem_deny_access(struct domain
> > *d)
> > status =
flight 156079 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/156079/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-arm64-arm64-xl-credit1 broken
test-amd64-i386-xl-qemuu-ws16-amd64 7 xen
Hi Elliott,
On 22/10/2020 18:13, Elliott Mitchell wrote:
On Thu, Oct 22, 2020 at 09:42:17AM +0200, Jan Beulich wrote:
On 22.10.2020 00:12, Elliott Mitchell wrote:
--- a/xen/arch/arm/acpi/domain_build.c
+++ b/xen/arch/arm/acpi/domain_build.c
@@ -42,17 +42,18 @@ static int __init acpi_iomem_deny
flight 156100 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/156100/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-xsm 6 xen-buildfail REGR. vs. 152631
build-amd64
Hi,
Thank you for the patch. FIY I tweak a bit the commit title before
committing.
The title is now: "xen/arm: acpi: Don't fail it SPCR table is absent".
Cheers,
On 21/10/2020 23:12, Elliott Mitchell wrote:
Absence of a SPCR table likely means the console is a framebuffer. In
such case acp
On Thu, Oct 22, 2020 at 07:38:26PM +0100, Julien Grall wrote:
> I don't think we are very consistent here... I would not add them
> myself, but I don't particularly mind them (I know some editors will add
> them automatically).
>
> I will keep them while committing. For the patch:
I would tend
On Thu, 22 Oct 2020, Julien Grall wrote:
> On 22/10/2020 02:43, Elliott Mitchell wrote:
> > Linux requires UEFI support to be enabled on ARM64 devices. While many
> > ARM64 devices lack ACPI, the writing seems to be on the wall of UEFI/ACPI
> > potentially taking over. Some common devices may nee
flight 156108 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/156108/
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 1
On Thu, Oct 22, 2020 at 02:17:13PM -0700, Stefano Stabellini wrote:
> On Thu, 22 Oct 2020, Julien Grall wrote:
> > On 22/10/2020 02:43, Elliott Mitchell wrote:
> > > Linux requires UEFI support to be enabled on ARM64 devices. While many
> > > ARM64 devices lack ACPI, the writing seems to be on the
Hello,
when using DRAKVUF against a Windows 7 x64 DomU, the whole machine hangs after
a few minutes.
The chance for a hang seems to be correlated with number of PCPUs, in this case
we have 14 PCPUs and hang is very easily reproducible, while on other machines
with 2-4 PCPUs it's very rare (but
On Thu, 22 Oct 2020, Julien Grall wrote:
> > > On 20/10/2020 16:25, Rahul Singh wrote:
> > > > Add support for ARM architected SMMUv3 implementations. It is based on
> > > > the Linux SMMUv3 driver.
> > > > Major differences between the Linux driver are as follows:
> > > > 1. Only Stage-2 translati
flight 156109 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/156109/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-xsm 6 xen-buildfail REGR. vs. 152631
build-amd64
flight 156102 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/156102/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 264eccb5dfc345c2e004883f00e62959f818fafd
baseline version:
ovmf 24cf72726564eac7ba9ab
flight 156110 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/156110/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-xsm 6 xen-buildfail REGR. vs. 152631
build-amd64
Linux requires UEFI support to be enabled on ARM64 devices. While many
ARM64 devices lack ACPI, the writing seems to be on the wall of UEFI/ACPI
potentially taking over. Some common devices may require ACPI table
support to boot.
For devices which can boot in either mode, continue defaulting to
1 - 100 of 107 matches
Mail list logo
