flight 160576 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/160576/
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
flight 160559 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/160559/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-xl-qemut-win7-amd64 19 guest-stopfail like 160537
test-armhf-armhf-libvirt 16 save
Got you Stefano,
Appreciate for your reply.
On Tue, Mar 30, 2021 at 8:46 AM Stefano Garzarella
wrote:
> Hi John,
>
> On Mon, Mar 29, 2021 at 09:46:49PM +0300, John Simpson wrote:
> >Hello,
> >
> >Kindly ask you to have a look at this bug.
> >Thank you for your replies.
>
> It's already fixed in
Thank you for the patch. We observed similar issues.
However, would you mind sharing more details on the test setup? We
tested the hypervisor after injecting XSA-336. There were regressions
in some benchmarks but far from being enough to raise a serious alarm.
In particular, we benchmarked CPU, di
Thank you for the patch. We observed similar issues.
However, would you mind sharing more details on the test setup? We
tested the hypervisor after injecting XSA-336. There were regressions
in some benchmarks but far from being enough to raise a serious alarm.
In particular, we benchmarked CPU, di
[Dropping some irrelevant cc’s]
> On Mar 30, 2021, at 1:46 PM, Stefano Garzarella wrote:
>
> Hi John,
>
> On Mon, Mar 29, 2021 at 09:46:49PM +0300, John Simpson wrote:
>> Hello,
>>
>> Kindly ask you to have a look at this bug.
>> Thank you for your replies.
>
> It's already fixed in QEMU upst
flight 160582 xen-unstable-coverity real [real]
http://logs.test-lab.xenproject.org/osstest/logs/160582/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
xen 90629587e16e2efdb61da77f25c25fba3c4a5fd7
baseline version:
xen e680
Hello,
The following series introduces EOI callbacks and switches a number of
subsystems to use them. The first one is vmsi and dpci, which are quite
straight forward to switch since they used to open code hooks in the EOI
handlers.
Finally HVM virtual timers are also switched to a different mode
EOIs are always executed in guest vCPU context, so there's no reason to
pass a vCPU parameter around as can be fetched from current.
While there make the vector parameter of both callbacks unsigned int.
No functional change intended.
Suggested-by: Paul Durrant
Signed-off-by: Roger Pau Monné
Re
EOIs are always executed in guest vCPU context, so there's no reason to
pass a domain parameter around as can be fetched from current->domain.
No functional change intended.
Signed-off-by: Roger Pau Monné
Reviewed-by: Paul Durrant
---
Changes since v1:
- New in this version.
---
xen/arch/x86/
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.
Such functionality will be used to migrate the current ad hoc handling
done in vlapic_handle_EOI for the vectors that require some log
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 injected from passed through
devices.
This avoids having multiple callback functions open-coded in
vlapic_handle_EOI, a
Switch the emulated IO-APIC code to use the local APIC EOI callback
mechanism. This allows to remove the last hardcoded callback from
vlapic_handle_EOI. Removing the hardcoded vIO-APIC callback also
allows to getting rid of setting the EOI exit bitmap based on the
triggering mode, as now all users
Such callbacks will be executed once a EOI is performed by the guest,
regardless of whether the interrupts are injected from the vIO-APIC or
the vPIC, as ISA IRQs are translated to GSIs and then the
corresponding callback is executed at EOI.
The vIO-APIC infrastructure for handling EOIs is build o
This is code movement in order to simply further changes.
No functional change intended.
Signed-off-by: Roger Pau Monné
Acked-by: Jan Beulich
---
Changes since v2:
- Drop one of the leading underscores from __hvm_dpci_eoi.
Changes since v1:
- New in this version.
---
xen/drivers/passthrough
Switch the dpci GSI EOI callback hooks to use the newly introduced
generic callback functionality, and remove the custom dpci calls found
on the vPIC and vIO-APIC implementations.
Signed-off-by: Roger Pau Monné
---
Changes since v2:
- Avoid leaking the allocated callback on error paths of
pt_
No longer add vPT timers to lists on specific vCPUs, since there's no
need anymore to check if timer interrupts have been injected on return
to HVM guest.
Such change allows to get rid of virtual timers vCPU migration, and
also cleanup some of the virtual timers fields that are no longer
required.
Currently vPT relies on timers being assigned to a vCPU and performing
checks on every return to HVM guest in order to check if an interrupt
from a vPT timer assigned to the vCPU is currently being injected.
This model doesn't work properly since the interrupt destination vCPU
of a vPT timer can b
Introduce a per virtual timer lock that replaces the existing per-vCPU
and per-domain vPT locks. Since virtual timers are no longer assigned
or migrated between vCPUs the locking can be simplified to a
in-structure spinlock that protects all the fields.
This requires introducing a helper to initia
Hi all,
PLEASE NOTE THE MODIFIED DATE.
The proposed agenda is in
https://cryptpad.fr/pad/#/2/pad/edit/K1fb4GrUF3lH9zQrIkl8+HTh/ and you can edit
to add items. Alternatively, you can reply to this mail directly.
Agenda items appreciated a few days before the call: please put your name
besides
On Tue, Mar 30, 2021 at 05:37:02PM +0200, Jan Beulich wrote:
> On 23.03.2021 10:58, Roger Pau Monne wrote:
> > 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 interf
On 31/03/2021 11:32, Roger Pau Monne wrote:
> @@ -1620,9 +1666,22 @@ int vlapic_init(struct vcpu *v)
>
> clear_page(vlapic->regs);
>
> +vlapic->callbacks = xmalloc_array(typeof(*vlapic->callbacks),
> + X86_NR_VECTORS - 16);
> +if ( !vlapic->call
flight 160563 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/160563/
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
On Tue, Mar 30, 2021 at 06:02:45PM +0200, Jan Beulich wrote:
> On 23.03.2021 10:58, Roger Pau Monne wrote:
> > --- a/tools/libs/guest/xg_cpuid_x86.c
> > +++ b/tools/libs/guest/xg_cpuid_x86.c
> > @@ -1098,3 +1098,20 @@ int xc_cpu_policy_update_msrs(xc_interface *xch,
> > xc_cpu_policy_t policy,
> >
On Tue, Mar 30, 2021 at 05:56:35PM +0200, Jan Beulich wrote:
> On 23.03.2021 10:58, Roger Pau Monne wrote:
> > --- a/tools/libs/guest/xg_cpuid_x86.c
> > +++ b/tools/libs/guest/xg_cpuid_x86.c
> > @@ -966,3 +966,70 @@ int xc_cpu_policy_get_msr(xc_interface *xch, const
> > xc_cpu_policy_t policy,
> >
On Wed, Mar 31, 2021 at 12:47:54PM +0100, Andrew Cooper wrote:
> On 31/03/2021 11:32, Roger Pau Monne wrote:
> > @@ -1620,9 +1666,22 @@ int vlapic_init(struct vcpu *v)
> >
> > clear_page(vlapic->regs);
> >
> > +vlapic->callbacks = xmalloc_array(typeof(*vlapic->callbacks),
> > +
vlapic_init()'s caller calls vlapic_destroy() on error. Therefore, the error
path from __map_domain_page_global() failing would doubly free
vlapic->regs_page.
Rework vlapic_destroy() to be properly idempotent, introducing the necessary
UNMAP_DOMAIN_PAGE_GLOBAL() and FREE_DOMHEAP_PAGE() wrappers.
On Wed, Mar 31, 2021 at 02:31:25PM +0100, Andrew Cooper wrote:
> vlapic_init()'s caller calls vlapic_destroy() on error. Therefore, the error
> path from __map_domain_page_global() failing would doubly free
> vlapic->regs_page.
>
> Rework vlapic_destroy() to be properly idempotent, introducing th
George Dunlap writes ("Re: [PATCH] CHANGELOG.md: Make PV shim smaller by
factoring out HVM-specific shadow code"):
> I don’t understand why the two of you are downplaying your work so much.
> Yes, these are all only incremental improvements; but they are improvements;
> and the cumulative effec
On 31.03.2021 15:49, Roger Pau Monné wrote:
> On Wed, Mar 31, 2021 at 02:31:25PM +0100, Andrew Cooper wrote:
>> @@ -1645,8 +1642,8 @@ void vlapic_destroy(struct vcpu *v)
>> tasklet_kill(&vlapic->init_sipi.tasklet);
>> TRACE_0D(TRC_HVM_EMUL_LAPIC_STOP_TIMER);
>> destroy_periodic_time(
On 31.03.2021 15:52, Ian Jackson wrote:
> George Dunlap writes ("Re: [PATCH] CHANGELOG.md: Make PV shim smaller by
> factoring out HVM-specific shadow code"):
>> I don’t understand why the two of you are downplaying your work so much.
>> Yes, these are all only incremental improvements; but they
On 31/03/2021 14:49, Roger Pau Monné wrote:
> On Wed, Mar 31, 2021 at 02:31:25PM +0100, Andrew Cooper wrote:
>> vlapic_init()'s caller calls vlapic_destroy() on error. Therefore, the error
>> path from __map_domain_page_global() failing would doubly free
>> vlapic->regs_page.
>>
>> Rework vlapic_d
On Wed, Mar 31, 2021 at 02:56:27PM +0100, Andrew Cooper wrote:
> On 31/03/2021 14:49, Roger Pau Monné wrote:
> > On Wed, Mar 31, 2021 at 02:31:25PM +0100, Andrew Cooper wrote:
> >> vlapic_init()'s caller calls vlapic_destroy() on error. Therefore, the
> >> error
> >> path from __map_domain_page_g
> On Mar 31, 2021, at 2:54 PM, Jan Beulich wrote:
>
> On 31.03.2021 15:52, Ian Jackson wrote:
>> George Dunlap writes ("Re: [PATCH] CHANGELOG.md: Make PV shim smaller by
>> factoring out HVM-specific shadow code"):
>>> I don’t understand why the two of you are downplaying your work so much.
>
On 3/31/21 5:53 AM, Hongyan Xia wrote:
> Thank you for the patch. We observed similar issues.
>
> However, would you mind sharing more details on the test setup? We
> tested the hypervisor after injecting XSA-336. There were regressions
> in some benchmarks but far from being enough to raise a se
On 31.03.2021 15:31, Andrew Cooper wrote:
> vlapic_init()'s caller calls vlapic_destroy() on error. Therefore, the error
> path from __map_domain_page_global() failing would doubly free
> vlapic->regs_page.
I'm having difficulty seeing this. What I find at present is
rc = vlapic_init(v);
On 31.03.2021 16:00, George Dunlap wrote:
>
>
>> On Mar 31, 2021, at 2:54 PM, Jan Beulich wrote:
>>
>> On 31.03.2021 15:52, Ian Jackson wrote:
>>> George Dunlap writes ("Re: [PATCH] CHANGELOG.md: Make PV shim smaller by
>>> factoring out HVM-specific shadow code"):
I don’t understand why t
> On Mar 31, 2021, at 3:06 PM, Jan Beulich wrote:
>
> On 31.03.2021 16:00, George Dunlap wrote:
>>
>>
>>> On Mar 31, 2021, at 2:54 PM, Jan Beulich wrote:
>>>
>>> On 31.03.2021 15:52, Ian Jackson wrote:
George Dunlap writes ("Re: [PATCH] CHANGELOG.md: Make PV shim smaller by
facto
Unfortunately aa50f45332f1 ("xen: fix for_each_cpu when NR_CPUS=1") has
caused quite a bit of fallout with gcc10, e.g. (there are at least two
more similar ones, and I didn't bother trying to find them all):
In file included from .../xen/include/xen/config.h:13,
from :
core_parkin
On 31.03.2021 16:30, George Dunlap wrote:
>
>
>> On Mar 31, 2021, at 3:06 PM, Jan Beulich wrote:
>>
>> On 31.03.2021 16:00, George Dunlap wrote:
>>>
>>>
On Mar 31, 2021, at 2:54 PM, Jan Beulich wrote:
On 31.03.2021 15:52, Ian Jackson wrote:
> George Dunlap writes ("Re: [PATCH
On 31.03.2021 14:40, Roger Pau Monné wrote:
> On Tue, Mar 30, 2021 at 06:02:45PM +0200, Jan Beulich wrote:
>> On 23.03.2021 10:58, Roger Pau Monne wrote:
>>> --- a/tools/libs/guest/xg_cpuid_x86.c
>>> +++ b/tools/libs/guest/xg_cpuid_x86.c
>>> @@ -1098,3 +1098,20 @@ int xc_cpu_policy_update_msrs(xc_i
On 23.03.2021 10:58, 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 leaves
> and MSR entries, except for MSR_ARCH_CAPABILITIES which has the RSBA
> bit or'ed.
I'm afraid this is too simpli
On 23.03.2021 10:58, Roger Pau Monne wrote:
> --- a/tools/libs/guest/xg_cpuid_x86.c
> +++ b/tools/libs/guest/xg_cpuid_x86.c
> @@ -436,6 +436,7 @@ int xc_cpuid_apply_policy(xc_interface *xch, uint32_t
> domid, bool restore,
> unsigned int i, nr_leaves, nr_msrs;
> xen_cpuid_leaf_t *leaves
On 31.03.2021 12:32, Roger Pau Monne wrote:
> EOIs are always executed in guest vCPU context, so there's no reason to
> pass a vCPU parameter around as can be fetched from current.
>
> While there make the vector parameter of both callbacks unsigned int.
>
> No functional change intended.
>
> Su
On 31.03.2021 12:32, Roger Pau Monne wrote:
> EOIs are always executed in guest vCPU context, so there's no reason to
> pass a domain parameter around as can be fetched from current->domain.
>
> No functional change intended.
>
> Signed-off-by: Roger Pau Monné
> Reviewed-by: Paul Durrant
> ---
On 31/03/2021 17:02, Jan Beulich wrote:
> On 31.03.2021 12:32, Roger Pau Monne wrote:
>> EOIs are always executed in guest vCPU context, so there's no reason to
>> pass a vCPU parameter around as can be fetched from current.
>>
>> While there make the vector parameter of both callbacks unsigned int
flight 160568 xen-4.12-testing real [real]
flight 160621 xen-4.12-testing real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/160568/
http://logs.test-lab.xenproject.org/osstest/logs/160621/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could
On Wed, 2021-03-31 at 16:52 +0200, Jan Beulich wrote:
> Unfortunately aa50f45332f1 ("xen: fix for_each_cpu when NR_CPUS=1")
> has
> caused quite a bit of fallout with gcc10, e.g. (there are at least
> two
> more similar ones, and I didn't bother trying to find them all):
>
Oh, wow... Sorry about t
flight 160578 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/160578/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 62bad17dcae18f55cb3bdc19909543dfdf928a2b
baseline version:
ovmf 98ff7e3c6373d3e0590f9
On 23/03/2021 09:58, Roger Pau Monne wrote:
> @@ -462,8 +464,13 @@ void libxl__cpuid_legacy(libxl_ctx *ctx, uint32_t domid,
> bool restore,
> itsc = (libxl_defbool_val(info->disable_migrate) ||
> info->tsc_mode == LIBXL_TSC_MODE_ALWAYS_EMULATE);
>
> -xc_cpuid_apply_policy(c
flight 160573 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/160573/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-xl-xsm7 xen-install fail REGR. vs. 152332
test-amd64-i386-xl-
On 23/03/2021 09:58, Roger Pau Monne wrote:
> 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é
Acked-by: Andrew Cooper
On 23/03/2021 09:58, Roger Pau Monne wrote:
> 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 allocati
# Xen Secure Boot and Lockdown
This document summarizes the Xen Secure Boot and Lockdown WG meeting that
occurred on Mon, March 29, 2021.
We identified a list of requirements for locking down a Xen system that
(at least) requires the following:
## Verified Boot Chain
Various projects are underw
flight 160581 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/160581/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-xl-qemut-win7-amd64 19 guest-stopfail like 160559
test-armhf-armhf-libvirt 16 save
Hi Andrew!
first of all -- thanks for pointing me in the right direction. So after
reading relevant sources: comments inline.
On Tue, Mar 30, 2021 at 12:08 PM Andrew Cooper
wrote:
> On 30/03/2021 19:28, Roman Shaposhnik wrote:
> > Hi!
> >
> > seems like I've run into an issue with multiboot2 an
flight 160619 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/160619/
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
On 31.03.2021 18:55, Dario Faggioli wrote:
> On Wed, 2021-03-31 at 16:52 +0200, Jan Beulich wrote:
>> Unfortunately aa50f45332f1 ("xen: fix for_each_cpu when NR_CPUS=1")
>> has
>> caused quite a bit of fallout with gcc10, e.g. (there are at least
>> two
>> more similar ones, and I didn't bother try
58 matches
Mail list logo
