On 28.02.20 20:06, Andrew Cooper wrote:
On 28/02/2020 17:13, Juergen Gross wrote:
@@ -700,6 +688,32 @@ int microcode_update(XEN_GUEST_HANDLE_PARAM(const_void)
buf, unsigned long len)
return ret;
}
+int microcode_update(XEN_GUEST_HANDLE_PARAM(const_void) buf, unsigned long len)
+{
+
flight 147710 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/147710/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-freebsd10-i386 11 guest-startfail REGR. vs. 144861
flight 147718 linux-4.14 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/147718/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-armhf-armhf-examine 8 reboot fail REGR. vs. 142849
Hello everyone,
Please, find here The CfP for the first edition of the RT-Cloud
workshop:
https://www.ecrts.org/rt-cloud-2020/
It's an academic research event, affiliated with one of the most
important academic conferences on real-time systems and real-time
scheduling (ECRTS,
flight 147706 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/147706/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-xl-shadow12 guest-start fail REGR. vs. 133580
It turns out that PVH dom0 construction doesn't work so well on a
2-socket Rome system...
(XEN) NX (Execute Disable) protection active
(XEN) *** Building a PVH Dom0 ***
(XEN) Watchdog timer detects that CPU0 is stuck!
(XEN) [ Xen-4.14-unstable x86_64 debug=y Not tainted ]
(XEN)
On 28/02/2020 12:27, Jan Beulich wrote:
> In fact it's VT-d specific, but we don't have a way yet to build code
> for just one vendor. Provide a #define for all other cases.
>
> Signed-off-by: Jan Beulich
iommu_snoop has no specific interaction with HVM.
It is for any cacheability games the
On 28/02/2020 12:26, Jan Beulich wrote:
> Provide a #define for other cases; it didn't seem worthwhile to me to
> introduce an IOMMU_INTREMAP Kconfig option at this point.
>
> Signed-off-by: Jan Beulich
>
> --- a/docs/misc/xen-command-line.pandoc
> +++ b/docs/misc/xen-command-line.pandoc
> @@
flight 147688 linux-4.19 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/147688/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-qemuu-nested-intel 17 debian-hvm-install/l1/l2 fail REGR. vs.
142932
> diff --git a/xen/arch/x86/mm/mem_sharing.c b/xen/arch/x86/mm/mem_sharing.c
> index 3835bc928f..c14a724c6d 100644
> --- a/xen/arch/x86/mm/mem_sharing.c
> +++ b/xen/arch/x86/mm/mem_sharing.c
> @@ -842,7 +842,7 @@ static int nominate_page(struct domain *d, gfn_t gfn,
>
> /* Skip xen heap pages
On 28/02/2020 18:57, Julien Grall wrote:
> From: Julien Grall
>
> The name of the variable 'led' is confusing and only used in one place a
> line after. So remove it.
>
> Signed-off-by: Julien Grall
I agree. Acked-by: Andrew Cooper
___
Xen-devel
On 28/02/2020 17:13, Juergen Gross wrote:
> @@ -700,6 +688,32 @@ int microcode_update(XEN_GUEST_HANDLE_PARAM(const_void)
> buf, unsigned long len)
> return ret;
> }
>
> +int microcode_update(XEN_GUEST_HANDLE_PARAM(const_void) buf, unsigned long
> len)
> +{
> +int ret;
> +struct
Please ignore this version as I forgot to CC the maintainers on it.
Cheers,
On 28/02/2020 18:57, Julien Grall wrote:
From: Julien Grall
The name of the variable 'led' is confusing and only used in one place a
line after. So remove it.
Signed-off-by: Julien Grall
---
From: Julien Grall
The name of the variable 'led' is confusing and only used in one place a
line after. So remove it.
Signed-off-by: Julien Grall
---
xen/common/grant_table.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/xen/common/grant_table.c
From: Julien Grall
The name of the variable 'led' is confusing and only used in one place a
line after. So remove it.
Signed-off-by: Julien Grall
---
xen/common/grant_table.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/xen/common/grant_table.c
On 24/02/2020 17:39, Ian Jackson wrote:
> Andrew Cooper writes ("[PATCH v2 10/17] tools/libxl: Plumb a restore boolean
> down into libxl__build_pre()"):
>> To fix CPUID handling, libxl__build_pre() is going to have to distinguish
>> between a brand new VM vs one which is being
The following series implements VM forking for Intel HVM guests to allow for
the fast creation of identical VMs without the assosciated high startup costs
of booting or restoring the VM from a savefile.
JIRA issue: https://xenproject.atlassian.net/browse/XEN-89
The fork operation is implemented
flight 147730 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/147730/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-libvirt 13 migrate-support-checkfail never pass
test-arm64-arm64-xl-xsm
VM forking is the process of creating a domain with an empty memory space and a
parent domain specified from which to populate the memory when necessary. For
the new domain to be functional the VM state is copied over as part of the fork
operation (HVM params, hap allocation, etc).
Signed-off-by:
Implement hypercall that allows a fork to shed all memory that got allocated
for it during its execution and re-load its vCPU context from the parent VM.
This allows the forked VM to reset into the same state the parent VM is in a
faster way then creating a new fork would be. Measurements show
Add necessary bits to implement "xl fork-vm" commands. The command allows the
user to specify how to launch the device model allowing for a late-launch model
in which the user can execute the fork without the device model and decide to
only later launch it.
Signed-off-by: Tamas K Lengyel
---
flight 147703 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/147703/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-libvirt 6 libvirt-buildfail REGR. vs. 146182
build-i386-libvirt
flight 147683 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/147683/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-qemut-rhel6hvm-amd 12 guest-start/redhat.repeat fail REGR. vs.
147600
Jürgen Groß writes:
> Friendly ping...
Ooops. I pick it up first thing tomorrow morning
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Ping again...
> -Original Message-
> From: Durrant, Paul
> Sent: 20 February 2020 12:54
> To: Durrant, Paul ; xen-devel@lists.xenproject.org
> Cc: Andrew Cooper ; George Dunlap
> ; Ian Jackson ;
> Jan Beulich ; Julien Grall ; Konrad
> Rzeszutek Wilk ; Stefano Stabellini
> ; Wei Liu
>
On Thu, Feb 20, 2020 at 02:31:03PM +0100, Paweł Marczewski wrote:
> If we skip the bootloader, the TTY path will be set for xenconsoled.
> However, there is no guarantee that this will happen by the time we
> want to call the console_available callback, so we have to wait.
>
> Signed-off-by:
On Fri, Feb 28, 2020 at 06:00:44PM +0100, Jan Beulich wrote:
> On 19.02.2020 18:43, Roger Pau Monne wrote:
> > Use Xen's L0 HVMOP_flush_tlbs hypercall in order to perform flushes.
> > This greatly increases the performance of TLB flushes when running
> > with a high amount of vCPUs as a Xen guest,
With core scheduling active it is mandatory for stop_machine_run() to
be called in idle context only (so either during boot or in a tasklet),
as otherwise a scheduling deadlock would occur: stop_machine_run()
does a cpu rendezvous by activating a tasklet on all other cpus. In
case
On 28.02.2020 17:57, Roger Pau Monné wrote:
> On Fri, Feb 28, 2020 at 05:44:57PM +0100, Jan Beulich wrote:
>> On 28.02.2020 17:31, Roger Pau Monné wrote:
>>> On Fri, Feb 28, 2020 at 02:58:42PM +0100, Jan Beulich wrote:
On 19.02.2020 18:43, Roger Pau Monne wrote:
> @@ -705,20 +701,22 @@
On 19.02.2020 18:43, Roger Pau Monne wrote:
> Use Xen's L0 HVMOP_flush_tlbs hypercall in order to perform flushes.
> This greatly increases the performance of TLB flushes when running
> with a high amount of vCPUs as a Xen guest, and is specially important
> when running in shim mode.
>
> The
On Fri, Feb 28, 2020 at 05:44:57PM +0100, Jan Beulich wrote:
> On 28.02.2020 17:31, Roger Pau Monné wrote:
> > On Fri, Feb 28, 2020 at 02:58:42PM +0100, Jan Beulich wrote:
> >> On 19.02.2020 18:43, Roger Pau Monne wrote:
> >>> --- a/xen/arch/x86/mm/hap/hap.c
> >>> +++ b/xen/arch/x86/mm/hap/hap.c
>
On Fri, Feb 28, 2020 at 05:29:32PM +0100, Jan Beulich wrote:
> On 19.02.2020 18:43, Roger Pau Monne wrote:
> > --- a/xen/arch/x86/guest/hyperv/hyperv.c
> > +++ b/xen/arch/x86/guest/hyperv/hyperv.c
> > @@ -199,7 +199,7 @@ static void __init e820_fixup(struct e820map *e820)
> >
On Fri, Feb 28, 2020 at 05:14:05PM +0100, Jan Beulich wrote:
> On 19.02.2020 18:43, Roger Pau Monne wrote:
> > Introduce a specific flag to request a HVM guest TLB flush, which is
> > an ASID/VPID tickle that forces a linear TLB flush for all HVM guests.
>
> Here and below, what do you mean by
Problem: xen_swiotlb_map_sg_attrs() maps a set of buffers described in
scatterlist.
It calls xen_dma_map_page() and sets sglist.dma_address to the address
calculated by
xen_phys_to_bus(). Let's call it dma_address_1.
xen_dma_map_page() maps the area and gets dma address different from
On 28.02.2020 17:31, Roger Pau Monné wrote:
> On Fri, Feb 28, 2020 at 02:58:42PM +0100, Jan Beulich wrote:
>> On 19.02.2020 18:43, Roger Pau Monne wrote:
>>> --- a/xen/arch/x86/mm/hap/hap.c
>>> +++ b/xen/arch/x86/mm/hap/hap.c
>>> @@ -669,32 +669,28 @@ static void hap_update_cr3(struct vcpu *v, int
On 28.02.2020 17:19, Roger Pau Monné wrote:
> On Fri, Feb 28, 2020 at 03:50:31PM +0100, Jan Beulich wrote:
>> On 19.02.2020 18:43, Roger Pau Monne wrote:
>>> Add shadow and hap implementation specific helpers to perform guest
>>> TLB flushes. Note that the code for both is exactly the same at the
On Fri, Feb 28, 2020 at 02:58:42PM +0100, Jan Beulich wrote:
> On 19.02.2020 18:43, Roger Pau Monne wrote:
> > --- a/xen/arch/x86/mm/hap/hap.c
> > +++ b/xen/arch/x86/mm/hap/hap.c
> > @@ -669,32 +669,28 @@ static void hap_update_cr3(struct vcpu *v, int
> > do_locking, bool noflush)
> >
On 19.02.2020 18:43, Roger Pau Monne wrote:
> --- a/xen/arch/x86/guest/hyperv/hyperv.c
> +++ b/xen/arch/x86/guest/hyperv/hyperv.c
> @@ -199,7 +199,7 @@ static void __init e820_fixup(struct e820map *e820)
> panic("Unable to reserve Hyper-V hypercall range\n");
> }
>
> -static const
On 19.02.2020 18:43, Roger Pau Monne wrote:
> The TLB clock is helpful when running Xen on bare metal because when
> doing a TLB flush each CPU is IPI'ed and can keep a timestamp of the
> last flush.
>
> This is not the case however when Xen is running virtualized, and the
> underlying hypervisor
On Fri, Feb 28, 2020 at 04:47:57PM +0100, Jan Beulich wrote:
> On 28.02.2020 16:27, Roger Pau Monné wrote:
> > On Fri, Feb 28, 2020 at 02:29:09PM +0100, Jan Beulich wrote:
> >> On 19.02.2020 18:43, Roger Pau Monne wrote:
> >>> Current implementation of hvm_asid_flush_vcpu is not safe to use
> >>>
On Fri, Feb 28, 2020 at 03:50:31PM +0100, Jan Beulich wrote:
> On 19.02.2020 18:43, Roger Pau Monne wrote:
> > Add shadow and hap implementation specific helpers to perform guest
> > TLB flushes. Note that the code for both is exactly the same at the
> > moment, and is copied from
On 19.02.2020 18:43, Roger Pau Monne wrote:
> Introduce a specific flag to request a HVM guest TLB flush, which is
> an ASID/VPID tickle that forces a linear TLB flush for all HVM guests.
Here and below, what do you mean by "linear"? I guess you mean
TLBs holding translations from guest linear to
On 28.02.2020 16:27, Roger Pau Monné wrote:
> On Fri, Feb 28, 2020 at 02:29:09PM +0100, Jan Beulich wrote:
>> On 19.02.2020 18:43, Roger Pau Monne wrote:
>>> Current implementation of hvm_asid_flush_vcpu is not safe to use
>>> unless the target vCPU is either paused or the currently running one,
Friendly ping...
On 18.02.20 16:47, Juergen Gross wrote:
Commit 111e7b15cf10f6 ("x86/ioperm: Extend IOPL config to control
ioperm() as well") reworked the iopl syscall to use I/O bitmaps.
Unfortunately this broke Xen PV domains using that syscall as there
is currently no I/O bitmap support in
Friendly ping...
On 21.02.20 11:38, Juergen Gross wrote:
Commit 2ae27137b2db89 ("x86: mm: convert dump_pagetables to use
walk_page_range") broke Xen PV guests as the hypervisor reserved hole
in the memory map was not taken into account.
Fix that by starting the kernel range only at
On Fri, Feb 28, 2020 at 02:29:09PM +0100, Jan Beulich wrote:
> On 19.02.2020 18:43, Roger Pau Monne wrote:
> > Current implementation of hvm_asid_flush_vcpu is not safe to use
> > unless the target vCPU is either paused or the currently running one,
> > as it modifies the generation without any
On Fri, Feb 28, 2020 at 01:39:59PM +0100, Jan Beulich wrote:
> On 28.02.2020 13:31, Roger Pau Monné wrote:
> > On Fri, Feb 28, 2020 at 01:12:03PM +0100, Jan Beulich wrote:
> >> --- a/xen/arch/x86/genapic/x2apic.c
> >> +++ b/xen/arch/x86/genapic/x2apic.c
> >> @@ -236,12 +236,21 @@ const struct
On 28.02.2020 15:48, Andrew Cooper wrote:
> On 28/02/2020 12:12, Jan Beulich wrote:
>> The wider cluster mode APIC IDs aren't generally representable. Convert
>> the iommu_intremap variable into a tristate, allowing the AMD IOMMU
>> driver to signal this special restriction to the
flight 147686 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/147686/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-qemuu-ovmf-amd64 10 debian-hvm-install fail REGR. vs.
145767
On 24/02/2020 17:32, Ian Jackson wrote:
> Andrew Cooper writes ("[PATCH v2 07/17] libxc/restore: STATIC_DATA_END
> inference for v2 compatibility"):
>> A v3 stream can compatibly read a v2 stream by inferring the position of the
>> STATIC_DATA_END record.
>>
>> v2 compatibility is only needed for
On 19.02.2020 18:43, Roger Pau Monne wrote:
> Add shadow and hap implementation specific helpers to perform guest
> TLB flushes. Note that the code for both is exactly the same at the
> moment, and is copied from hvm_flush_vcpu_tlb. This will be changed by
> further patches that will add
On 28/02/2020 12:12, Jan Beulich wrote:
> The wider cluster mode APIC IDs aren't generally representable. Convert
> the iommu_intremap variable into a tristate, allowing the AMD IOMMU
> driver to signal this special restriction to the apic_x2apic_probe().
> (Note: assignments to the variable get
On Fri, Feb 28, 2020 at 02:13:45PM +0100, Jan Beulich wrote:
> On 28.02.2020 13:41, Roger Pau Monné wrote:
> > On Fri, Feb 28, 2020 at 01:10:59PM +0100, Jan Beulich wrote:
> >> We should neither cause IOMMU initialization as a whole to fail in this
> >> case (we should still be able to bring up
On 19.02.2020 18:43, Roger Pau Monne wrote:
> --- a/xen/arch/x86/mm/hap/hap.c
> +++ b/xen/arch/x86/mm/hap/hap.c
> @@ -669,32 +669,28 @@ static void hap_update_cr3(struct vcpu *v, int
> do_locking, bool noflush)
> hvm_update_guest_cr3(v, noflush);
> }
>
> +/*
> + * NB: doesn't actually
There does not seem to be any justification for refusing to create the
domain's p2m table simply because it may have assigned pages. Particularly
it prevents the prior allocation of PGC_extra pages.
Signed-off-by: Paul Durrant
---
Cc: Jan Beulich
Cc: Andrew Cooper
Cc: George Dunlap
Cc: Wei
Currently shared_info is a shared xenheap page but shared xenheap pages
complicate future plans for live-update of Xen so it is desirable to,
where possible, not use them [1]. This patch therefore converts shared_info
into a PGC_extra domheap page. This does entail freeing shared_info during
Patches #2 and #3 have been split out of the previous version of patch #6
(which was patch #2 of the previous series). Patch #4 is not entirely
related but is useful to have in place before patch #5. Patch #5 is also
new.
Paul Durrant (6):
domain: introduce alloc/free_shared_info() helpers...
... to cover xenheap and PGC_extra pages.
PGC_extra pages are intended to hold data structures that are associated
with a domain and my be mapped by that domain. They should not be treated
as 'normal' guest pages (i.e. RAM or page tables). Hence, in many cases
where code currently tests
... now that it is safe to assign them.
This avoids relying on libxl (or whatever toolstack is in use) setting
max_pages up with sufficient 'slop' to allow all necessary ioreq server
pages to be allocated.
Signed-off-by: Paul Durrant
---
Cc: Paul Durrant
Cc: Jan Beulich
Cc: Andrew Cooper
Cc:
The walk of page_list in dom0_construct_pv() should ignore PGC_extra pages
as they are only created for special purposes and, if mapped, will be mapped
explicitly for whatever purpose is relevant.
Signed-off-by: Paul Durrant
---
Cc: Jan Beulich
Cc: Andrew Cooper
Cc: Wei Liu
Cc: "Roger Pau
... and save the MFN.
This patch modifies the 'shared_info' field of struct domain to be
a structure comprising an MFN and a virtual address. Allocations are
still done from xenheap, so the virtual address still equates to
virt_to_mfn() called on the MFN but subsequent patch will change this.
On 19.02.2020 18:43, Roger Pau Monne wrote:
> Current implementation of hvm_asid_flush_vcpu is not safe to use
> unless the target vCPU is either paused or the currently running one,
> as it modifies the generation without any locking.
Indeed, but the issue you're taking care of is highly
On 28.02.2020 13:41, Roger Pau Monné wrote:
> On Fri, Feb 28, 2020 at 01:10:59PM +0100, Jan Beulich wrote:
>> We should neither cause IOMMU initialization as a whole to fail in this
>> case (we should still be able to bring up the system in non-x2APIC or
>> x2APIC physical mode), nor should the
On 28.02.2020 13:41, Roger Pau Monné wrote:
> On Fri, Feb 28, 2020 at 01:10:59PM +0100, Jan Beulich wrote:
>> We should neither cause IOMMU initialization as a whole to fail in this
>> case (we should still be able to bring up the system in non-x2APIC or
>> x2APIC physical mode), nor should the
On 28.02.2020 13:07, Roger Pau Monne wrote:
> Current usage of the per-CPU scratch cpumask is dangerous since
> there's no way to figure out if the mask is already being used except
> for manual code inspection of all the callers and possible call paths.
>
> This is unsafe and not reliable, so
On Fri, Feb 28, 2020 at 01:10:59PM +0100, Jan Beulich wrote:
> We should neither cause IOMMU initialization as a whole to fail in this
> case (we should still be able to bring up the system in non-x2APIC or
> x2APIC physical mode), nor should the remainder of the function be
> skipped (as the main
On 28.02.2020 13:31, Roger Pau Monné wrote:
> On Fri, Feb 28, 2020 at 01:12:03PM +0100, Jan Beulich wrote:
>> --- a/xen/arch/x86/genapic/x2apic.c
>> +++ b/xen/arch/x86/genapic/x2apic.c
>> @@ -236,12 +236,21 @@ const struct genapic *__init apic_x2apic
>> x2apic_phys = !iommu_intremap ||
>>
On 28/02/2020 12:10, Jan Beulich wrote:
> We should neither cause IOMMU initialization as a whole to fail in this
> case (we should still be able to bring up the system in non-x2APIC or
> x2APIC physical mode), nor should the remainder of the function be
> skipped (as the main part of it won't get
On Fri, Feb 28, 2020 at 01:12:03PM +0100, Jan Beulich wrote:
> The wider cluster mode APIC IDs aren't generally representable. Convert
> the iommu_intremap variable into a tristate, allowing the AMD IOMMU
> driver to signal this special restriction to the apic_x2apic_probe().
> (Note: assignments
In fact it's VT-d specific, but we don't have a way yet to build code
for just one vendor.
Signed-off-by: Jan Beulich
--- a/xen/drivers/passthrough/iommu.c
+++ b/xen/drivers/passthrough/iommu.c
@@ -33,7 +33,6 @@ bool_t __read_mostly force_iommu;
bool_t __read_mostly iommu_verbose;
bool
In fact it's VT-d specific, but we don't have a way yet to build code
for just one vendor.
Signed-off-by: Jan Beulich
--- a/xen/drivers/passthrough/iommu.c
+++ b/xen/drivers/passthrough/iommu.c
@@ -32,7 +32,6 @@ bool_t __read_mostly iommu_enabled;
bool_t __read_mostly force_iommu;
bool_t
Provide a #define for other cases; it didn't seem worthwhile to me to
introduce an IOMMU_INTREMAP Kconfig option at this point.
Signed-off-by: Jan Beulich
--- a/docs/misc/xen-command-line.pandoc
+++ b/docs/misc/xen-command-line.pandoc
@@ -1299,6 +1299,8 @@ boolean (e.g. `iommu=no`) can override
A number of the command line controlled variables are x86-
or even x86-HVM-specific. Don't have those variables elsewhere
in the first place (in some cases replace them by a #define),
and as a result also don't silently accept such "iommu="
sub-options which in fact have no effect.
1:
On 2/27/20 4:31 AM, Jürgen Groß wrote:
> On 26.02.20 22:26, Gustavo A. R. Silva wrote:
>> The current codebase makes use of the zero-length array language
>> extension to the C90 standard, but the preferred mechanism to declare
>> variable-length types such as these ones is a flexible array
>>
The wider cluster mode APIC IDs aren't generally representable. Convert
the iommu_intremap variable into a tristate, allowing the AMD IOMMU
driver to signal this special restriction to the apic_x2apic_probe().
(Note: assignments to the variable get adjusted, while existing
consumers - all assuming
We should neither cause IOMMU initialization as a whole to fail in this
case (we should still be able to bring up the system in non-x2APIC or
x2APIC physical mode), nor should the remainder of the function be
skipped (as the main part of it won't get entered a 2nd time) in such an
event. It is
On 28.02.2020 13:07, Roger Pau Monne wrote:
> Some callers of send_IPI_mask pass the scratch cpumask as the mask
> parameter of send_IPI_mask, so the scratch cpumask cannot be used by
> the function. The following trace has been obtained with a debug patch
> and shows one of those callers:
>
>
For AMD the connection between IOMMU and x2APIC is less strong,
hence even if unlikely to occur we would better deal correctly
with XT being unavailable (for whatever reasons) in particular
when x2APIC is already enabled on a system.
1: correct handling when XT's prereq features are unavailable
Some callers of send_IPI_mask pass the scratch cpumask as the mask
parameter of send_IPI_mask, so the scratch cpumask cannot be used by
the function. The following trace has been obtained with a debug patch
and shows one of those callers:
(XEN) scratch CPU mask already in use by
Hello,
Following series contain yet one more bugfix that removes the usage of
the scratch cpumask in send_IPI_mask and the introduction of accessors
to get/put the per-CPU scratch cpumask in order to prevent such issues
form happening in the future.
Thanks, Roger.
Roger Pau Monne (2):
Current usage of the per-CPU scratch cpumask is dangerous since
there's no way to figure out if the mask is already being used except
for manual code inspection of all the callers and possible call paths.
This is unsafe and not reliable, so introduce a minimal get/put
infrastructure to prevent
On 28.02.2020 12:41, Roger Pau Monné wrote:
> On Fri, Feb 28, 2020 at 12:15:21PM +0100, Jan Beulich wrote:
>> On 28.02.2020 11:31, Roger Pau Monné wrote:
>>> On Fri, Feb 28, 2020 at 11:16:55AM +0100, Jan Beulich wrote:
On 28.02.2020 10:33, Roger Pau Monne wrote:
> +/*
> + *
flight 147670 linux-5.4 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/147670/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-qemuu-nested-intel 17 debian-hvm-install/l1/l2 fail REGR. vs.
146121
On Thu, 27 Feb 2020 at 12:16, Anthony PERARD wrote:
>
> The following changes since commit db736e0437aa6fd7c1b7e4599c17f9619ab6b837:
>
> Merge remote-tracking branch 'remotes/bonzini/tags/for-upstream' into
> staging (2020-02-25 13:31:16 +)
>
> are available in the Git repository at:
>
>
On 28.02.2020 11:31, Roger Pau Monné wrote:
> On Fri, Feb 28, 2020 at 11:16:55AM +0100, Jan Beulich wrote:
>> On 28.02.2020 10:33, Roger Pau Monne wrote:
>>> +/*
>>> + * Due to reentrancy scratch cpumask cannot be used in IRQ, #MC or #NMI
>>> + * context.
>>> + */
>>> +
> -Original Message-
> From: Julien Grall
> Sent: 28 February 2020 10:26
> To: Durrant, Paul ; xen-devel@lists.xenproject.org
> Cc: Anthony PERARD ; Ian Jackson
> ; Wei Liu
> Subject: Re: [Xen-devel] [PATCH 2/3] libxl: make creation of xenstore
> suspend event channel node optional
>
>
On Fri, Feb 28, 2020 at 11:16:55AM +0100, Jan Beulich wrote:
> On 28.02.2020 10:33, Roger Pau Monne wrote:
> > Current usage of the per-CPU scratch cpumask is dangerous since
> > there's no way to figure out if the mask is already being used except
> > for manual code inspection of all the callers
Hi Paul,
On 28/02/2020 09:28, Durrant, Paul wrote:
-Original Message-
From: Julien Grall
Sent: 27 February 2020 22:52
To: Durrant, Paul ; xen-devel@lists.xenproject.org
Cc: Anthony PERARD ; Ian Jackson
; Wei Liu
Subject: Re: [Xen-devel] [PATCH 2/3] libxl: make creation of xenstore
On Fri, Feb 28, 2020 at 11:08:43AM +0100, Jan Beulich wrote:
> On 28.02.2020 10:33, Roger Pau Monne wrote:
> > --- a/xen/arch/x86/smp.c
> > +++ b/xen/arch/x86/smp.c
> > @@ -59,6 +59,8 @@ static void send_IPI_shortcut(unsigned int shortcut, int
> > vector,
> > apic_write(APIC_ICR, cfg);
> >
On 28.02.2020 10:33, Roger Pau Monne wrote:
> Current usage of the per-CPU scratch cpumask is dangerous since
> there's no way to figure out if the mask is already being used except
> for manual code inspection of all the callers and possible call paths.
>
> This is unsafe and not reliable, so
On 28.02.2020 10:33, Roger Pau Monne wrote:
> --- a/xen/arch/x86/smp.c
> +++ b/xen/arch/x86/smp.c
> @@ -59,6 +59,8 @@ static void send_IPI_shortcut(unsigned int shortcut, int
> vector,
> apic_write(APIC_ICR, cfg);
> }
>
> +DECLARE_PER_CPU(cpumask_var_t, send_ipi_cpumask);
This needs to
> -Original Message-
> From: Julien Grall
> Sent: 27 February 2020 22:52
> To: Durrant, Paul ; xen-devel@lists.xenproject.org
> Cc: Anthony PERARD ; Ian Jackson
> ; Wei Liu
> Subject: Re: [Xen-devel] [PATCH 2/3] libxl: make creation of xenstore
> suspend event channel node optional
>
>
Hi Jan,
On 28/02/2020 09:19, Jan Beulich wrote:
On 28.02.2020 10:09, Julien Grall wrote:
Hi Jan,
On 28/02/2020 08:41, Jan Beulich wrote:
On 27.02.2020 19:46, Andrew Cooper wrote:
Each function takes an unsigned count, and loops based on a signed i. This
causes problems when between 2 and 4
Current usage of the per-CPU scratch cpumask is dangerous since
there's no way to figure out if the mask is already being used except
for manual code inspection of all the callers and possible call paths.
This is unsafe and not reliable, so introduce a minimal get/put
infrastructure to prevent
Hello,
Following series contain yet one more bugfix that removes the usage of
the scratch cpumask in send_IPI_mask and the introduction of accessors
to get/put the per-CPU scratch cpumask in order to prevent such issues
form happening in the future.
Thanks, Roger.
Roger Pau Monne (2):
Some callers of send_IPI_mask pass the scratch cpumask as the mask
parameter of send_IPI_mask, so the scratch cpumask cannot be used by
the function. The following trace has been obtained with a debug patch
and shows one of those callers:
(XEN) scratch CPU mask already in use by
On 28.02.2020 10:18, Jürgen Groß wrote:
> On 28.02.20 10:15, Jan Beulich wrote:
>> On 28.02.2020 09:58, Jürgen Groß wrote:
>>> On 28.02.20 09:27, Jan Beulich wrote:
On 28.02.2020 08:19, Juergen Gross wrote:
> With core scheduling active it is mandatory for stop_machine_run() to
> be
On 28.02.20 10:15, Jan Beulich wrote:
On 28.02.2020 09:58, Jürgen Groß wrote:
On 28.02.20 09:27, Jan Beulich wrote:
On 28.02.2020 08:19, Juergen Gross wrote:
With core scheduling active it is mandatory for stop_machine_run() to
be called in idle context only (so either during boot or in a
On 28.02.2020 10:09, Julien Grall wrote:
> Hi Jan,
>
> On 28/02/2020 08:41, Jan Beulich wrote:
>> On 27.02.2020 19:46, Andrew Cooper wrote:
>>> Each function takes an unsigned count, and loops based on a signed i. This
>>> causes problems when between 2 and 4 billion operations are requested.
>>
On 28.02.2020 09:58, Jürgen Groß wrote:
> On 28.02.20 09:27, Jan Beulich wrote:
>> On 28.02.2020 08:19, Juergen Gross wrote:
>>> With core scheduling active it is mandatory for stop_machine_run() to
>>> be called in idle context only (so either during boot or in a tasklet),
>>> as otherwise a
1 - 100 of 108 matches
Mail list logo
