flight 147035 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/147035/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-libvirt 6 libvirt-buildfail REGR. vs. 146882
Tests which
flight 146987 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/146987/
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
test-amd64-i386-xl-qemu
flight 146995 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/146995/
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 146981 linux-4.14 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/146981/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-armhf-armhf-xl-multivcpu 7 xen-bootfail REGR. vs. 142849
test-armhf-armhf-xl-
On 13.02.20 19:38, Andrew Cooper wrote:
On 13/02/2020 12:54, Juergen Gross wrote:
Keyhandlers dumping hypervisor information to the console often need
to take locks while accessing data. In order to not block in case of
system inconsistencies it is convenient to use trylock variants when
obtaini
flight 147030 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/147030/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-libvirt 6 libvirt-buildfail REGR. vs. 146882
Tests which
flight 146978 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/146978/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-freebsd10-i386 14 guest-saverestore fail REGR. vs. 144861
test-amd64-i386-f
flight 147027 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/147027/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-libvirt 6 libvirt-buildfail REGR. vs. 146882
Tests which
flight 146972 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/146972/
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
test-amd64-amd64-xl
On Thu, 13 Feb 2020, Julien Grall wrote:
> All the arch headers (i.e under asm-arm) are included using "asm/*.h".
>
> To stay consistent, remove the only instance where "asm-arm/*.h" is
> used.
>
> Take the opportunity to move the inclusion with the rest of the asm/
> include.
>
> Signed-off-by:
flight 147025 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/147025/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-libvirt 6 libvirt-buildfail REGR. vs. 146882
Tests which
On Thu, 13 Feb 2020, Andrei Cherechesu wrote:
> Hello,
>
> I used the Xen from Stefano's tree and made the updates to the partial
> dtb that he specified.
>
> > This is mostly likely because Linux is trying to access a region
> > that is not mapped in stage-2. You can rebuild Xen with debug enabl
Hi,
On 13/02/2020 18:27, Andrei Cherechesu wrote:
-Original Message-
From: Julien Grall
Sent: Thursday, February 13, 2020 00:03
To: Stefano Stabellini ; Andrei Cherechesu
Cc: Jorge Pereira ; xen-devel@lists.xenproject.org
Subject: Re: [Xen-devel] Having a DOM-U guest with 1:1 mapping
flight 146943 linux-4.19 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/146943/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-qemut-rhel6hvm-amd 13 guest-start.2 fail in 146901 REGR. vs.
142932
Tests which ar
flight 147020 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/147020/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-libvirt 6 libvirt-buildfail REGR. vs. 146882
Tests which
On 13/02/2020 12:54, Juergen Gross wrote:
Keyhandlers dumping hypervisor information to the console often need
to take locks while accessing data. In order to not block in case of
system inconsistencies it is convenient to use trylock variants when
obtaining the locks. On the other hand a busy sy
flight 146936 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/146936/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
test-amd64-amd64-xl-rtds 15 guest-saverestore fail pass in 146896
test-armhf-armhf-xl-rtds 16
-Original Message-
From: Julien Grall
Sent: Thursday, February 13, 2020 00:03
To: Stefano Stabellini ; Andrei Cherechesu
Cc: Jorge Pereira ; xen-devel@lists.xenproject.org
Subject: Re: [Xen-devel] Having a DOM-U guest with 1:1 mapping in the second
stage MMU.
Hello,
I used the Xen fr
On Tue, 2020-02-11 at 13:15 +0100, Juergen Gross wrote:
> sched_init_pdata() is used nowhere, it can be removed. Same applies
> to
> the .init_pdata hook of the per-scheduler interface. The last caller
> has been removed with commit f855dd962523b6cb47a92037bdd28b1485141abe
> ("sched: add minimalist
flight 147018 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/147018/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-libvirt 6 libvirt-buildfail REGR. vs. 146882
build-arm64-
Am Thu, 13 Feb 2020 11:28:29 +0100
schrieb Jan Beulich :
> On 12.02.2020 15:22, Olaf Hering wrote:
> > With the script below, the formula may look like this:
> > - each vcpu needs 1MB extra memory
> > - each GB of a HVM domU memory needs 8MB extra memory
> > - each HVM domU needs 2MB extra memory
On 13.02.2020 16:15, Roger Pau Monné wrote:
> On Thu, Feb 13, 2020 at 11:12:12AM +0100, Jan Beulich wrote:
>> On 12.02.2020 17:49, Roger Pau Monne wrote:
>>> --- a/xen/arch/x86/smpboot.c
>>> +++ b/xen/arch/x86/smpboot.c
>>> @@ -57,6 +57,30 @@ DEFINE_PER_CPU_READ_MOSTLY(cpumask_var_t, cpu_core_mask)
On Thu, Feb 13, 2020 at 03:30:19PM +, Anthony PERARD wrote:
> On Thu, Feb 13, 2020 at 03:27:51PM +, Wei Liu wrote:
> > Its last parameter should be libxl_domain_build_info.
> >
> > Fixes: 1b3cec69 ("tools/libxl: Combine legacy CPUID handling logic")
> > Signed-off-by: Wei Liu
> > ---
> >
On Thu, Feb 13, 2020 at 03:27:51PM +, Wei Liu wrote:
> Its last parameter should be libxl_domain_build_info.
>
> Fixes: 1b3cec69 ("tools/libxl: Combine legacy CPUID handling logic")
> Signed-off-by: Wei Liu
> ---
> tools/libxl/libxl_nocpuid.c | 2 +-
> 1 file changed, 1 insertion(+), 1 delet
Its last parameter should be libxl_domain_build_info.
Fixes: 1b3cec69 ("tools/libxl: Combine legacy CPUID handling logic")
Signed-off-by: Wei Liu
---
tools/libxl/libxl_nocpuid.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/tools/libxl/libxl_nocpuid.c b/tools/libxl/libxl_no
On Thu, Feb 13, 2020 at 11:12:12AM +0100, Jan Beulich wrote:
> On 12.02.2020 17:49, Roger Pau Monne wrote:
> > @@ -223,7 +223,10 @@ static void _clear_irq_vector(struct irq_desc *desc)
> > trace_irq_mask(TRC_HW_IRQ_CLEAR_VECTOR, irq, vector, tmp_mask);
> >
> > if ( likely(!desc->arch.mo
flight 147013 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/147013/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-libvirt 6 libvirt-buildfail REGR. vs. 146882
build-arm64-
flight 146930 linux-next real [real]
http://logs.test-lab.xenproject.org/osstest/logs/146930/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-arm64-arm64-xl-seattle 16 guest-start/debian.repeat fail REGR. vs. 146850
test-amd64-amd64-qem
get_cpu_idle_time() is calling vcpu_runstate_get() for an idle vcpu.
With core scheduling active this is fragile, as idle vcpus are assigned
to other scheduling units temporarily, and that assignment is changed
in some cases without holding the scheduling lock, and
vcpu_runstate_get() is using v->s
On 13.02.20 15:19, Sergey Dyasli wrote:
On 12/02/2020 12:24, Jürgen Groß wrote:
On 12.02.20 12:21, Sergey Dyasli wrote:
Hi Juergen,
Recently our testing has found a host crash which is reproducible.
Do you have any idea what might be going on here?
Oh, nice catch!
The problem is that get_cp
branch xen-unstable
xenbranch xen-unstable
job test-armhf-armhf-examine
testid reboot
Tree: linux
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git
Tree: linuxfirmware git://xenbits.xen.org/osstest/linux-firmware.git
Tree: ovmf git://xenbits.xen.org/osstest/ovmf.git
Tree: qemu
On 12/02/2020 12:24, Jürgen Groß wrote:
> On 12.02.20 12:21, Sergey Dyasli wrote:
>> Hi Juergen,
>>
>> Recently our testing has found a host crash which is reproducible.
>> Do you have any idea what might be going on here?
>
> Oh, nice catch!
>
> The problem is that get_cpu_idle_time() is calling v
On 2/13/20 12:54 PM, Juergen Gross wrote:
> Using for_each_domain() with out holding the domlist_read_lock is
> fragile, so add the lock in the keyhandlers it is missing.
>
> Signed-off-by: Juergen Gross
> ---
> xen/arch/x86/mm/p2m-ept.c | 4
p2m bits:
Acked-by: George Dunlap
_
On 13.02.2020 13:54, Juergen Gross wrote:
> Using for_each_domain() with out holding the domlist_read_lock is
> fragile, so add the lock in the keyhandlers it is missing.
>
> Signed-off-by: Juergen Gross
Where applicable
Acked-by: Jan Beulich
___
Xe
On 13.02.2020 13:54, Juergen Gross wrote:
> rangeset_printk() is only used locally, so it can be made static.
>
> Signed-off-by: Juergen Gross
Acked-by: Jan Beulich
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.o
On Thu, Feb 13, 2020 at 01:42:00PM +, Anthony PERARD wrote:
> The Arm container wasn't updated in the original patch.
>
> Fixes: 1a3673da6482 ("automation: updating container to have python3-config
> binary")
> Signed-off-by: Anthony PERARD
Acked-by: Wei Liu
__
The Arm container wasn't updated in the original patch.
Fixes: 1a3673da6482 ("automation: updating container to have python3-config
binary")
Signed-off-by: Anthony PERARD
---
Please update the Arm container, as I don't have an environment to do
it.
There were talk about removing bin86 and nasm
On 13.02.2020 12:41, Roger Pau Monné wrote:
> On Thu, Feb 13, 2020 at 11:19:02AM +0100, Jan Beulich wrote:
>> On 13.02.2020 11:03, Roger Pau Monné wrote:
>>> On Thu, Feb 13, 2020 at 10:59:29AM +0100, Jan Beulich wrote:
On 12.02.2020 17:49, Roger Pau Monne wrote:
> Using scratch_cpumask in
On 13.02.2020 13:24, Wei Liu wrote:
> On Thu, Feb 13, 2020 at 10:46:56AM +0100, Jan Beulich wrote:
>> On 12.02.2020 17:09, Wei Liu wrote:
>>> --- a/xen/arch/x86/guest/hyperv/private.h
>>> +++ b/xen/arch/x86/guest/hyperv/private.h
>>> @@ -26,6 +26,6 @@
>>>
>>> DECLARE_PER_CPU(void *, hv_input_pag
> -Original Message-
[snip]
>
> Ok, thanks. Kevin has completed his acks (patches #1 and #4).
>
> George, Julien, Tim,
>
> Can I have acks or otherwise, please?
>
I have acks from Julien and Tim. George, can you ack or otherwise please?
Paul
__
All dumping functions invoked by the "runq" keyhandler are called with
disabled interrupts, so there is no need to use the irqsave variants
of any locks in those functions.
Signed-off-by: Juergen Gross
---
xen/common/sched/credit.c | 10 --
xen/common/sched/credit2.c | 5 ++---
xen/com
Instead of using the normal locks use the keyhandler provided trylocks
with timeouts.
Signed-off-by: Juergen Gross
---
xen/arch/x86/io_apic.c | 53 +-
xen/arch/x86/irq.c | 5 -
xen/arch/x86/msi.c | 4 +++-
xen/arch/x86/numa.c| 16
Instead of using the normal locks use the keyhandler provided trylocks
with timeouts. This requires adding a special primitive for the pcidev
lock.
Signed-off-by: Juergen Gross
---
xen/drivers/passthrough/amd/iommu_intr.c | 14 ++
xen/drivers/passthrough/pci.c| 14 +++
rangeset_printk() is only used locally, so it can be made static.
Signed-off-by: Juergen Gross
---
xen/common/rangeset.c | 3 +--
xen/include/xen/rangeset.h | 2 --
2 files changed, 1 insertion(+), 4 deletions(-)
diff --git a/xen/common/rangeset.c b/xen/common/rangeset.c
index f34cafdc7e..
Instead of using the normal locks use the keyhandler provided trylocks
with timeouts. This requires a special primitive for the scheduler
lock.
Signed-off-by: Juergen Gross
---
xen/common/sched/core.c| 7 +++
xen/common/sched/cpupool.c | 4 +++-
xen/common/sched/credit.c | 25
Keyhandlers dumping hypervisor information to the console often need
to take locks while accessing data. In order to not block in case of
system inconsistencies it is convenient to use trylock variants when
obtaining the locks. On the other hand a busy system might easily
encounter held locks, so t
Instead of using the normal locks use the keyhandler provided trylocks
with timeouts. This requires adding a percpu read_trylock and a special
primitive for the grant lock.
Signed-off-by: Juergen Gross
---
xen/common/event_channel.c | 3 ++-
xen/common/grant_table.c | 32 +
Most keyhandlers are used to dump hypervisor data to the console and
they are used mostly for debugging purposes. In those cases it might
happen that some data structures are locked and thus are blocking the
handler to access the data.
In order to be able to still get some information don't use pl
Using for_each_domain() with out holding the domlist_read_lock is
fragile, so add the lock in the keyhandlers it is missing.
Signed-off-by: Juergen Gross
---
xen/arch/x86/mm/p2m-ept.c | 4
xen/arch/x86/time.c | 5 +
xen/common/grant_table.c| 7 +++
xen/driv
flight 147009 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/147009/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-libvirt 6 libvirt-buildfail REGR. vs. 146882
build-arm64-
Hi,
Gentle ping.
Cheers,
On 04/02/2020 14:06, Julien Grall wrote:
From: Julien Grall
Unlike shadow_enable(), hap_enable() can only be called once during
domain creation and with the mode equal to mode equal to
PG_external | PG_translate | PG_refcounts.
If it were called twice, then we might
On Wed, 12 Feb 2020 at 14:44, David Hildenbrand wrote:
>
> We want to actually resize ram blocks (make everything between
> used_length and max_length inaccessible) - however, not all ram block
> notifiers will support that. Let's teach the notifier that ram blocks
> are indeed resizable, but keep
On Thu, Feb 13, 2020 at 12:20:33PM +, Wei Liu wrote:
> On Wed, Feb 12, 2020 at 06:43:47PM +0100, Roger Pau Monné wrote:
> > On Wed, Feb 12, 2020 at 04:09:18PM +, Wei Liu wrote:
> > > +static uint64_t flush_tlb_ex(const cpumask_t *mask, const void *va,
> > > + uns
All the arch headers (i.e under asm-arm) are included using "asm/*.h".
To stay consistent, remove the only instance where "asm-arm/*.h" is
used.
Take the opportunity to move the inclusion with the rest of the asm/
include.
Signed-off-by: Julien Grall
---
xen/include/asm-arm/domain.h | 2 +-
1
On Thu, Feb 13, 2020 at 10:46:56AM +0100, Jan Beulich wrote:
> On 12.02.2020 17:09, Wei Liu wrote:
> > --- a/xen/arch/x86/guest/hyperv/private.h
> > +++ b/xen/arch/x86/guest/hyperv/private.h
> > @@ -26,6 +26,6 @@
> >
> > DECLARE_PER_CPU(void *, hv_input_page);
> > DECLARE_PER_CPU(void *, hv_vp_
On Thu, Feb 13, 2020 at 10:49:39AM +0100, Jan Beulich wrote:
> >> diff --git a/xen/arch/x86/guest/hyperv/Makefile
> >> b/xen/arch/x86/guest/hyperv/Makefile
> >> index 18902c33e9..0e39410968 100644
> >> --- a/xen/arch/x86/guest/hyperv/Makefile
> >> +++ b/xen/arch/x86/guest/hyperv/Makefile
> >> @@ -
On Wed, Feb 12, 2020 at 06:43:47PM +0100, Roger Pau Monné wrote:
> On Wed, Feb 12, 2020 at 04:09:18PM +, Wei Liu wrote:
> > Implement L0 assisted TLB flush for Xen on Hyper-V. It takes advantage
> > of several hypercalls:
> >
> > * HVCALL_FLUSH_VIRTUAL_ADDRESS_LIST
> > * HVCALL_FLUSH_VIRTUAL
On Wed, Feb 12, 2020 at 08:41:54AM +0100, Juergen Gross wrote:
> When run in a stubdom environment Xenstore can't select a logfile or
> emit memory statistics to a specific file.
>
> So remove or modify those control commands accordingly.
>
> Signed-off-by: Juergen Gross
> Acked-by: Andrew Coope
On Wed, Feb 12, 2020 at 08:41:53AM +0100, Juergen Gross wrote:
> In order to be able to connect to the console of Xenstore stubdom we
> need to create the appropriate entries in Xenstore.
>
> For the moment we don't support xenconsoled living in another domain
> than dom0, as this information isn'
On Wed, Feb 12, 2020 at 08:41:52AM +0100, Juergen Gross wrote:
> In order to be able to get access to the console of Xenstore stubdom
> we need an appropriate granttab entry. So call xc_dom_gnttab_init()
> when constructing the domain and preset some information needed
> for that function in the do
On Thu, Feb 13, 2020 at 10:29:16AM +, Wei Liu wrote:
> On Thu, Feb 13, 2020 at 08:48:39AM +, Durrant, Paul wrote:
> > > -Original Message-
> > > From: Roger Pau Monné
> > > Sent: 12 February 2020 18:01
> > > To: Wei Liu
> > > Cc: Xen Development List ; Durrant, Paul
> > > ; Michae
On Thu, Feb 13, 2020 at 11:19:02AM +0100, Jan Beulich wrote:
> On 13.02.2020 11:03, Roger Pau Monné wrote:
> > On Thu, Feb 13, 2020 at 10:59:29AM +0100, Jan Beulich wrote:
> >> On 12.02.2020 17:49, Roger Pau Monne wrote:
> >>> Using scratch_cpumask in send_IPI_mak is not safe because it can be
> >>
Hello,
The main aim of this series is to reduce the pressure around
cpu_add_remove_lock by converting it into a rw lock. Most users of the
lock want to take it in read mode, as they only care about the maps not
changing.
Patch #2 makes the writers take the lock in blocking mode, this is
mainly do
Don't allow cpu_hotplug_begin to fail by converting the trylock into a
blocking lock acquisition. Write users of the cpu_add_remove_lock are
limited to CPU plug/unplug operations, and cannot deadlock between
themselves or other users taking the lock in read mode as
cpu_add_remove_lock is always loc
Most users of the cpu maps just care about the maps not changing while
the lock is being held, but don't actually modify the maps.
Convert the lock into a rw lock, and take the lock in read mode in
get_cpu_maps and in write mode in cpu_hotplug_begin. This will lower
the contention around the lock,
This patch details proposes extra migration data and xenstore protocol
extensions to support non-cooperative live migration of guests.
Signed-off-by: Paul Durrant
---
Cc: Andrew Cooper
Cc: George Dunlap
Cc: Ian Jackson
Cc: Jan Beulich
Cc: Julien Grall
Cc: Konrad Rzeszutek Wilk
Cc: Stefano S
Ancha,
Anchal Agarwal writes:
> Hello,
> I am sending out a v3 version of series of patches that implements guest
> PM hibernation.
can you pretty please thread your patch series so that the 1-n/n mails
have a
References:
in the headers? git-send-email does that proper as do other tools.
Paul Durrant (2):
docs/designs: Add a design document for non-cooperative live migration
docs/designs: Add a design document for migration of xenstore data
docs/designs/non-cooperative-migration.md | 272 ++
docs/designs/xenstore-migration.md| 136 +++
2 fi
It has become apparent to some large cloud providers that the current
model of cooperative migration of guests under Xen is not usable as it
relies on software running inside the guest, which is likely beyond the
provider's control.
This patch introduces a proposal for non-cooperative live migratio
flight 147004 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/147004/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-libvirt 6 libvirt-buildfail REGR. vs. 146882
build-arm64-
Hi David,
On 01/02/2020 01:33, David Woodhouse wrote:
From: David Woodhouse
Remove a ternary operator that made my brain hurt.
Replace it with something simpler that makes it somewhat clearer that
the check for initrdidx < mbi->mods_count is because mbi->mods_count
is what find_first_bit() wi
Hi David,
On 01/02/2020 01:32, David Woodhouse wrote:
From: Wei Liu
We want to move vm_init, which calls vm_init_type under the hood, to
early boot stage. Add a path to get page from boot allocator instead.
Add an emacs block to that file while I was there.
Signed-off-by: Wei Liu
---
xen/
On Wed, Feb 12, 2020 at 05:53:54PM +0100, Roger Pau Monné wrote:
> On Wed, Feb 12, 2020 at 04:09:15PM +, Wei Liu wrote:
> > Change hv_vp_index to use uint32_t because that is what is defined in TLFS.
> >
> > Add "_addr" suffix to hv_do_rep_hypercall's parameters.
>
> Being of type paddr_t I'm
On Thu, Feb 13, 2020 at 08:48:39AM +, Durrant, Paul wrote:
> > -Original Message-
> > From: Roger Pau Monné
> > Sent: 12 February 2020 18:01
> > To: Wei Liu
> > Cc: Xen Development List ; Durrant, Paul
> > ; Michael Kelley ; Wei Liu
> > ; Jan Beulich ; Andrew Cooper
> >
> > Subject:
On 12.02.2020 15:22, Olaf Hering wrote:
> Am Wed, 12 Feb 2020 11:53:25 +0100
> schrieb Olaf Hering :
>
>> Is there a formula to calculate that amount of extra memory, is this
>> behavior documented somewhere?
See e.g. sh_min_allocation() and whatever its HAP counterpart is. But
this and hence ..
On 13.02.2020 11:03, Roger Pau Monné wrote:
> On Thu, Feb 13, 2020 at 10:59:29AM +0100, Jan Beulich wrote:
>> On 12.02.2020 17:49, Roger Pau Monne wrote:
>>> Using scratch_cpumask in send_IPI_mak is not safe because it can be
>>> called from interrupt context, and hence Xen would have to make sure
On 12.02.2020 17:49, Roger Pau Monne wrote:
> @@ -223,7 +223,10 @@ static void _clear_irq_vector(struct irq_desc *desc)
> trace_irq_mask(TRC_HW_IRQ_CLEAR_VECTOR, irq, vector, tmp_mask);
>
> if ( likely(!desc->arch.move_in_progress) )
> +{
> +put_scratch_cpumask();
>
Hi,
On 13/02/2020 11:01, Jürgen Groß wrote:
On 13.02.20 10:01, Julien Grall wrote:
Hi,
On 11/02/2020 10:35, Juergen Gross wrote:
With core scheduling active it is mandatory for stop_machine_run() to
be called in a tasklet only, as otherwise a scheduling deadlock would
occur: stop_machine_run(
On Thu, Feb 13, 2020 at 10:53:43AM +0100, Jan Beulich wrote:
> On 12.02.2020 22:05, Julien Grall wrote:
> > On 12/02/2020 17:49, Roger Pau Monne wrote:
> >> Commit:
> >>
> >> 5500d265a2a8fa63d60c08beb549de8ec82ff7a5
> >> x86/smp: use APIC ALLBUT destination shorthand when possible
> >
> > There is
On Thu, Feb 13, 2020 at 10:59:29AM +0100, Jan Beulich wrote:
> On 12.02.2020 17:49, Roger Pau Monne wrote:
> > Using scratch_cpumask in send_IPI_mak is not safe because it can be
> > called from interrupt context, and hence Xen would have to make sure
> > all the users of the scratch cpumask disabl
On 13.02.20 10:01, Julien Grall wrote:
Hi,
On 11/02/2020 10:35, Juergen Gross wrote:
With core scheduling active it is mandatory for stop_machine_run() to
be called in a tasklet only, as otherwise a scheduling deadlock would
occur: stop_machine_run() does a cpu rendezvous by activating a taskle
On 12.02.2020 17:49, Roger Pau Monne wrote:
> Using scratch_cpumask in send_IPI_mak is not safe because it can be
> called from interrupt context, and hence Xen would have to make sure
> all the users of the scratch cpumask disable interrupts while using
> it.
>
> Instead introduce a new cpumask t
On 13.02.2020 00:05, Wei Liu wrote:
> On Wed, Feb 12, 2020 at 05:49:47PM +0100, Roger Pau Monne wrote:
>> Unify the two adjacent header includes that are both gated with ifndef
>> __ASSEMBLY__.
>>
>> No functional change intended.
>>
>> Signed-off-by: Roger Pau Monné
>
> Reviewed-by: Wei Liu
Ac
On 12.02.2020 22:05, Julien Grall wrote:
> On 12/02/2020 17:49, Roger Pau Monne wrote:
>> Commit:
>>
>> 5500d265a2a8fa63d60c08beb549de8ec82ff7a5
>> x86/smp: use APIC ALLBUT destination shorthand when possible
>
> There is a more subtle problem introduced by this patch. I thought I
> would mention
On 12.02.2020 18:43, Roger Pau Monné wrote:
> On Wed, Feb 12, 2020 at 04:09:18PM +, Wei Liu wrote:
>> Implement L0 assisted TLB flush for Xen on Hyper-V. It takes advantage
>> of several hypercalls:
>>
>> * HVCALL_FLUSH_VIRTUAL_ADDRESS_LIST
>> * HVCALL_FLUSH_VIRTUAL_ADDRESS_LIST_EX
>> * HVCA
On 12.02.2020 17:09, Wei Liu wrote:
> --- a/xen/arch/x86/guest/hyperv/private.h
> +++ b/xen/arch/x86/guest/hyperv/private.h
> @@ -26,6 +26,6 @@
>
> DECLARE_PER_CPU(void *, hv_input_page);
> DECLARE_PER_CPU(void *, hv_vp_assist);
> -DECLARE_PER_CPU(unsigned int, hv_vp_index);
> +DECLARE_PER_CPU(
On 12/02/2020 18:13, Sander Eikelenboom wrote:
> On 12/02/2020 18:01, Roger Pau Monné wrote:
>> On Wed, Feb 12, 2020 at 05:53:39PM +0100, Sander Eikelenboom wrote:
>>> On 12/02/2020 17:49, Roger Pau Monne wrote:
Hello,
Commit:
5500d265a2a8fa63d60c08beb549de8ec82ff7a5
x
> -Original Message-
> From: Roger Pau Monné
> Sent: 12 February 2020 18:01
> To: Wei Liu
> Cc: Xen Development List ; Durrant, Paul
> ; Michael Kelley ; Wei Liu
> ; Jan Beulich ; Andrew Cooper
>
> Subject: Re: [PATCH 2/4] x86/hypervisor: pass flags to
> hypervisor_flush_tlb
>
> On Wed,
At 18:28 +0100 on 10 Feb (1581359306), 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.
>
> This was previously unconditionally done in each pre_flush call, but
> that's not requir
At 09:02 + on 13 Feb (1581584528), Tim Deegan wrote:
> At 18:28 +0100 on 10 Feb (1581359304), 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
Hi,
On 11/02/2020 10:35, Juergen Gross wrote:
With core scheduling active it is mandatory for stop_machine_run() to
be called in a tasklet only, as otherwise a scheduling deadlock would
occur: stop_machine_run() does a cpu rendezvous by activating a tasklet
on all other cpus. In case stop_machin
At 18:28 +0100 on 10 Feb (1581359304), 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 w
> -Original Message-
> From: Wei Liu On Behalf Of Wei Liu
> Sent: 12 February 2020 17:09
> To: Xen Development List
> Cc: Durrant, Paul ; Michael Kelley
> ; Wei Liu ; Wei Liu
> ; Jan Beulich ; Andrew Cooper
> ; Roger Pau Monné
> Subject: [PATCH 1/4] x86/hyperv: misc cleanup
>
> Change h
flight 147000 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/147000/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-libvirt 6 libvirt-buildfail REGR. vs. 146882
build-arm64-
94 matches
Mail list logo
