On 18.02.2020 18:13, Anthony PERARD wrote:
> On Tue, Feb 18, 2020 at 05:43:30PM +0100, Jan Beulich wrote:
>> On 13.12.2019 13:18, Anthony PERARD wrote:
>>> On Fri, Dec 13, 2019 at 12:13:53PM +0100, Jan Beulich wrote:
On 12.12.2019 19:27, Anthony PERARD wrote:
> --- a/xen/arch/x86/Kconfig
>
(Resend; no idea where the original, sent on Dec 23rd, ended up - I
can't find it in the list archives in any event)
On 20.12.2019 22:39, Igor Druzhinin wrote:
> @@ -38,24 +37,22 @@ void hvm_init_guest_time(struct domain *d)
> uint64_t hvm_get_guest_time_fixed(const struct vcpu *v, uint64_t at_ts
flight 147210 linux-5.4 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/147210/
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.
146121
test-amd64-i386-xl
On 18.02.20 22:03, Thomas Gleixner wrote:
Juergen Gross writes:
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 supp
flight 147186 linux-4.4 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/147186/
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.
139698
test-amd64-i3
flight 147207 xtf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/147207/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
xtf 9d934985adb9eb8290e62df187e044105c9dd6b8
baseline version:
xtf 8afcfc0c18de7a9a40aa0e
On 18/02/2020 18:43, Jason Andryuk wrote:
> On Mon, Feb 17, 2020, 8:22 PM Andrew Cooper wrote:
>> On 17/02/2020 20:41, Jason Andryuk wrote:
>>> On Mon, Feb 17, 2020 at 2:46 PM Andrew Cooper
>>> wrote:
On 17/02/2020 19:19, Jason Andryuk wrote:
> enabling vecOn Tue, Dec 31, 2019 at 5:43 A
On Tue, 18 Feb 2020 at 20:07, Philippe Mathieu-Daudé wrote:
> I don't understand well cpu_physical_memory*(). Aren't these obsolete?
> They confuse me when using multi-core CPUs.
They sort of are, but there is no simple mechanical replacement
for them -- you need to look at the individual use to
flight 147181 linux-next real [real]
http://logs.test-lab.xenproject.org/osstest/logs/147181/
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.
147082
test-armhf-a
Juergen Gross writes:
> 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 PV domains.
>
> Add I/O bitma
Juergen -
On Mon, Feb 17, 2020 at 10:51 PM Jürgen Groß wrote:
> > Any thoughts, insights or guidance would be greatly appreciated!
> Can you check whether all vcpus of a hanging guest are consuming time
> (via xl vcpu-list) ?
> It would be interesting to see where the vcpus are running around. Ca
On 2/18/20 7:49 PM, Peter Maydell wrote:
On Tue, 18 Feb 2020 at 17:57, Stefan Weil wrote:
Am 18.02.20 um 14:20 schrieb Philippe Mathieu-Daudé:
This commit was produced with the included Coccinelle script
scripts/coccinelle/as-rw-const.patch.
Inspired-by: Peter Maydell
Signed-off-by: Philip
flight 147256 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/147256/
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 1
On 2/18/20 10:59 AM, Stefan Weil wrote:
> Personally I like the way how the standard C library handles such
> pointers for functions like memcpy, fread, fwrite and others.
>
> Therefore I suggest to use `const void *` and `void *` and to avoid type
> casts.
Seconded.
r~
__
flight 147195 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/147195/
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
Am 18.02.20 um 19:59 schrieb Stefan Weil:
> Indeed, fixing such inconsitencies would be good.
s/inconsitencies/inconsistencies/
:-)
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Am 18.02.20 um 19:49 schrieb Peter Maydell:
> I think that we should fix the inconsistency where these functions
> all take "uint8_t* buf":
>
> - address_space_rw()
> - address_space_read()
> - address_space_write()
> - address_space_write_rom()
> - cpu_physical_memory_rw()
> - cpu_memory_rw
On Tue, 18 Feb 2020 at 17:57, Stefan Weil wrote:
>
> Am 18.02.20 um 14:20 schrieb Philippe Mathieu-Daudé:
>
> > This commit was produced with the included Coccinelle script
> > scripts/coccinelle/as-rw-const.patch.
> >
> > Inspired-by: Peter Maydell
> > Signed-off-by: Philippe Mathieu-Daudé
> >
On Mon, Feb 17, 2020, 8:22 PM Andrew Cooper wrote:
>
> On 17/02/2020 20:41, Jason Andryuk wrote:
> > On Mon, Feb 17, 2020 at 2:46 PM Andrew Cooper
> > wrote:
> >> On 17/02/2020 19:19, Jason Andryuk wrote:
> >>> enabling vecOn Tue, Dec 31, 2019 at 5:43 AM Aaron Janse
> >>> wrote:
> On Tue,
On Tue, Feb 18, 2020 at 6:57 PM Stefan Weil wrote:
> Am 18.02.20 um 14:20 schrieb Philippe Mathieu-Daudé:
>
> > This commit was produced with the included Coccinelle script
> > scripts/coccinelle/as-rw-const.patch.
> >
> > Inspired-by: Peter Maydell
> > Signed-off-by: Philippe Mathieu-Daudé
> >
Am 18.02.20 um 14:20 schrieb Philippe Mathieu-Daudé:
> This commit was produced with the included Coccinelle script
> scripts/coccinelle/as-rw-const.patch.
>
> Inspired-by: Peter Maydell
> Signed-off-by: Philippe Mathieu-Daudé
> ---
> Based-on: <20200218112457.22712-1-peter.mayd...@linaro.org>
[
On 2/18/20 5:20 AM, Philippe Mathieu-Daudé wrote:
> This commit was produced with the included Coccinelle script
> scripts/coccinelle/as-rw-const.patch.
>
> Inspired-by: Peter Maydell
> Signed-off-by: Philippe Mathieu-Daudé
> ---
> Based-on: <20200218112457.22712-1-peter.mayd...@linaro.org>
Rev
On Tue, Feb 18, 2020 at 05:43:30PM +0100, Jan Beulich wrote:
> On 13.12.2019 13:18, Anthony PERARD wrote:
> > On Fri, Dec 13, 2019 at 12:13:53PM +0100, Jan Beulich wrote:
> >> On 12.12.2019 19:27, Anthony PERARD wrote:
> >>> --- a/xen/arch/x86/Kconfig
> >>> +++ b/xen/arch/x86/Kconfig
> >>> @@ -32,6
On 18/02/2020 17:00, Jan Beulich wrote:
> On 20.12.2019 22:39, Igor Druzhinin wrote:
>> Similarly to PV vTSC emulation, optimize HVM side for consistency
>> and scalability by dropping a spinlock protecting a single variable.
>>
>> Signed-off-by: Igor Druzhinin
>
> Seeing that you didn't reply to
On 20.12.2019 22:39, Igor Druzhinin wrote:
> Similarly to PV vTSC emulation, optimize HVM side for consistency
> and scalability by dropping a spinlock protecting a single variable.
>
> Signed-off-by: Igor Druzhinin
Seeing that you didn't reply to my comment sent on Dec 23rd,
I'm going to drop t
On 18/02/2020 16:52, Jan Beulich wrote:
> This is more robust than the raw xmalloc_bytes().
>
> Also add a sanity check on the input page range, to avoid returning
> the less applicable -ENOMEM in such cases (and trying the allocation in
> the first place).
>
> Signed-off-by: Jan Beulich
Acked-by
This is more robust than the raw xmalloc_bytes().
Also add a sanity check on the input page range, to avoid returning
the less applicable -ENOMEM in such cases (and trying the allocation in
the first place).
Signed-off-by: Jan Beulich
---
v2: Expand a bit the description of the sanity check addi
On 13.12.2019 13:18, Anthony PERARD wrote:
> On Fri, Dec 13, 2019 at 12:13:53PM +0100, Jan Beulich wrote:
>> On 12.12.2019 19:27, Anthony PERARD wrote:
>>> --- a/xen/arch/x86/Kconfig
>>> +++ b/xen/arch/x86/Kconfig
>>> @@ -32,6 +32,9 @@ config ARCH_DEFCONFIG
>>> string
>>> default "arch/x86/
On 18.02.2020 17:18, Roger Pau Monné wrote:
> On Tue, Feb 18, 2020 at 04:40:29PM +0100, Jan Beulich wrote:
>> On 18.02.2020 16:34, Andrew Cooper wrote:
>>> On 18/02/2020 14:43, Roger Pau Monné wrote:
OK, so what about:
if ( in_mc() || in_nmi() )
{
bool x2apic = current_
On 17.02.2020 12:17, Andrew Cooper wrote:
> --- a/xen/arch/x86/pv/iret.c
> +++ b/xen/arch/x86/pv/iret.c
> @@ -27,15 +27,15 @@ static void async_exception_cleanup(struct vcpu *curr)
> {
> unsigned int trap;
>
> -if ( !curr->arch.async_exception_mask )
> +if ( !curr->arch.async_event_
On 18/02/2020 16:11, Jan Beulich wrote:
> On 17.02.2020 12:17, Andrew Cooper wrote:
>> The async_exception_{state,mask} infrastructure is implemented in common
>> code,
>> but is limited to x86 because of the VCPU_TRAP_LAST ifdef-ary.
>>
>> The internals are very x86 specific (and even then, in ne
On Tue, Feb 18, 2020 at 04:40:29PM +0100, Jan Beulich wrote:
> On 18.02.2020 16:34, Andrew Cooper wrote:
> > On 18/02/2020 14:43, Roger Pau Monné wrote:
> >> On Tue, Feb 18, 2020 at 01:29:56PM +, Andrew Cooper wrote:
> >>> On 18/02/2020 11:46, Roger Pau Monné wrote:
> On Tue, Feb 18, 2020
On 17.02.2020 12:17, Andrew Cooper wrote:
> The async_exception_{state,mask} infrastructure is implemented in common code,
> but is limited to x86 because of the VCPU_TRAP_LAST ifdef-ary.
>
> The internals are very x86 specific (and even then, in need of correction),
> and won't be of interest to
On 17.02.2020 12:17, Andrew Cooper wrote:
> --- a/xen/arch/x86/nmi.c
> +++ b/xen/arch/x86/nmi.c
> @@ -587,25 +587,25 @@ static void do_nmi_trigger(unsigned char key)
>
> static void do_nmi_stats(unsigned char key)
> {
> -int i;
> -struct domain *d;
> -struct vcpu *v;
> +const st
flight 147248 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/147248/
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 1
Documentation says " is a comma separated list
of settings, from the following list". There's no mention
of a specific order, yet so far the parsing logic did accept only
strategy, then policy (and neither of the two omitted). Make "state"
move
- back to STATE_TYPE when finding a comma after havin
Uniformly passing "false" can't be right, but has been benign because of
the function not using this parameter.
Signed-off-by: Jan Beulich
--- a/tools/libxl/libxl_pci.c
+++ b/tools/libxl/libxl_pci.c
@@ -1567,7 +1567,7 @@ void libxl__device_pci_add(libxl__egc *e
}
}
-rc = libx
As the code comment says, this will allow use of a 2Mb super page
mapping at the end of "low" memory.
Signed-off-by: Jan Beulich
--- a/tools/libxl/libxl_dm.c
+++ b/tools/libxl/libxl_dm.c
@@ -563,6 +563,13 @@ int libxl__domain_device_construct_rdm(l
/* Just check if RDM > our memory boun
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 PV domains.
Add I/O bitmap support via a new paravirt functi
While in "host" strategy all regions get processed, of the per-device
ones only the first entry has been consumed so far.
Signed-off-by: Jan Beulich
--- a/tools/libxl/libxl_dm.c
+++ b/tools/libxl/libxl_dm.c
@@ -471,8 +471,7 @@ int libxl__domain_device_construct_rdm(l
/* Query RDM entries
Reserved device memory region processing as well as E820 table creation
happen earlier than the adding of (PCI) devices, yet they consume the
policy (e.g. to decide whether to add entries to the E820 table). But so
far it was only at the stage of PCI device addition that the final
policy was establ
While playing with this, I've noticed a number of issues,
some actual bugs, some merely cosmetic (at least at this point
in time. This is the collection of adjustments made, with bug
fixes first.
1: honor multiple per-device reserved memory regions
2: establish per-device reserved memory policy ea
On 18.02.2020 16:34, Andrew Cooper wrote:
> On 18/02/2020 14:43, Roger Pau Monné wrote:
>> On Tue, Feb 18, 2020 at 01:29:56PM +, Andrew Cooper wrote:
>>> On 18/02/2020 11:46, Roger Pau Monné wrote:
On Tue, Feb 18, 2020 at 11:35:37AM +, Andrew Cooper wrote:
> On 18/02/2020 11:22, Ro
flight 147174 linux-4.9 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/147174/
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.
142947
test-amd64-i3
On 18/02/2020 14:43, Roger Pau Monné wrote:
> On Tue, Feb 18, 2020 at 01:29:56PM +, Andrew Cooper wrote:
>> On 18/02/2020 11:46, Roger Pau Monné wrote:
>>> On Tue, Feb 18, 2020 at 11:35:37AM +, Andrew Cooper wrote:
On 18/02/2020 11:22, Roger Pau Monné wrote:
> On Tue, Feb 18, 2020
On 17.02.2020 12:45, Roger Pau Monne wrote:
> Import the functions and it's dependencies. Based on Linux 5.5, commit
> id d5226fa6dbae0569ee43ecfc08bdcd6770fc4755.
>
> Signed-off-by: Roger Pau Monné
Acked-by: Jan Beulich
___
Xen-devel mailing list
David Woodhouse writes ("[RFC PATCH v3 0/22] Live update: boot memory
management, data stream handling, record format"):
> Now with added documentation:
> http://david.woodhou.se/live-update-handover.pdf
I had a look at this. I didn't read the patches in detail, but I did
read all of
[RFC PAT
Pawel Marczewski writes ("[Xen-devel] Race condition in console_available
callback? (libvirt + libxl + xenconsoled)"):
> I am trying to debug an issue in QubesOS where a domain created by
> libvirt often does not have information stored about the console TTY path.
Hi. Marek drew my attention to
On 18.02.2020 15:42, Alexandru Stefan ISAILA wrote:
>
--- a/xen/arch/x86/mm/hap/hap.c
+++ b/xen/arch/x86/mm/hap/hap.c
@@ -488,8 +488,17 @@ int hap_enable(struct domain *d, u32 mode)
goto out;
}
+if ( (d->arch.altp2m_working_e
On Tue, Feb 18, 2020 at 01:29:56PM +, Andrew Cooper wrote:
> On 18/02/2020 11:46, Roger Pau Monné wrote:
> > On Tue, Feb 18, 2020 at 11:35:37AM +, Andrew Cooper wrote:
> >>
> >> On 18/02/2020 11:22, Roger Pau Monné wrote:
> >>> On Tue, Feb 18, 2020 at 11:21:12AM +, Andrew Cooper wrote:
>>> --- a/xen/arch/x86/mm/hap/hap.c
>>> +++ b/xen/arch/x86/mm/hap/hap.c
>>> @@ -488,8 +488,17 @@ int hap_enable(struct domain *d, u32 mode)
>>>goto out;
>>>}
>>>
>>> +if ( (d->arch.altp2m_working_eptp = alloc_xenheap_page()) == NULL )
>>> +{
>>> +
On 14.02.2020 18:59, Andrew Cooper wrote:
> On 28/01/2020 14:10, Jan Beulich wrote:
>> On 28.01.2020 13:52, Andrew Cooper wrote:
>>> boot_cpu_has(X86_FEATURE_X2APIC) doesn't need checking to interpret
>>> APIC_BASE_EXTD.
>> Hmm, the comment you remove ...
>>
>>> --- a/xen/arch/x86/apic.c
>>> +++ b/
On 18/02/2020 11:46, Roger Pau Monné wrote:
> On Tue, Feb 18, 2020 at 11:35:37AM +, Andrew Cooper wrote:
>>
>> On 18/02/2020 11:22, Roger Pau Monné wrote:
>>> On Tue, Feb 18, 2020 at 11:21:12AM +, Andrew Cooper wrote:
On 18/02/2020 11:10, Roger Pau Monné wrote:
> On Tue, Feb 18, 20
On 14.02.2020 20:55, Andrew Cooper wrote:
> This is an Intel-only, read-only MSR related to microcode loading. Expose it
> in similar circumstances as the PATCHLEVEL MSR.
>
> This should have been alongside c/s 013896cb8b2 "x86/msr: Fix handling of
> MSR_AMD_PATCHLEVEL/MSR_IA32_UCODE_REV"
>
> Si
This commit was produced with the included Coccinelle script
scripts/coccinelle/as-rw-const.patch.
Inspired-by: Peter Maydell
Signed-off-by: Philippe Mathieu-Daudé
---
Based-on: <20200218112457.22712-1-peter.mayd...@linaro.org>
Maybe can be squashed in Peter's patch?
Cocci script can be writte
On 18/02/2020 12:21, Juergen Gross wrote:
> Today the RCU handling in Xen is affecting scheduling in several ways.
> It is raising sched softirqs without any real need and it requires
> tasklets for rcu_barrier(), which interacts badly with core scheduling.
>
> This small series repairs those issu
On Tue, Feb 18, 2020 at 10:40:29AM +, Wei Liu wrote:
> >
> > > +uint64_t ret;
> > > +
> > > +if ( !flush || cpumask_empty(mask) )
> > > +{
> > > +ASSERT_UNREACHABLE();
> > > +return -EINVAL;
> > > +}
> > > +
> > > +local_irq_save(irq_flags);
> >
> > I think
On Mon, Feb 10, 2020 at 06:28:29PM +0100, Roger Pau Monne wrote:
> @@ -256,6 +257,16 @@ void flush_area_mask(const cpumask_t *mask, const void
> *va, unsigned int flags)
> if ( (flags & ~FLUSH_ORDER_MASK) &&
> !cpumask_subset(mask, cpumask_of(cpu)) )
> {
> +if ( cpu_has
Some keyhandlers are calling process_pending_softirqs() while holding
a rcu_read_lock(). This is wrong, as process_pending_softirqs() might
activate rcu calls which should not happen inside a rcu_read_lock().
For that purpose add process_pending_softirqs_norcu() which will not
do any rcu activity
Today rcu_barrier() is calling stop_machine_run() to synchronize all
physical cpus in order to ensure all pending rcu calls have finished
when returning.
As stop_machine_run() is using tasklets this requires scheduling of
idle vcpus on all cpus imposing the need to call rcu_barrier() on idle
cpus
Xen's RCU implementation relies on no softirq handling taking place
while being in a RCU critical section. Add ASSERT()s in debug builds
in order to catch any violations.
For that purpose modify rcu_read_[un]lock() to use a dedicated percpu
counter instead of preempt_[en|dis]able() as this enables
As rcu callbacks are processed in __do_softirq() there is no need to
use the scheduling softirq for forcing quiescent state. Any other
softirq would do the job and the scheduling one is the most expensive.
So use the already existing rcu softirq for that purpose. For telling
apart why the rcu soft
Today the RCU handling in Xen is affecting scheduling in several ways.
It is raising sched softirqs without any real need and it requires
tasklets for rcu_barrier(), which interacts badly with core scheduling.
This small series repairs those issues.
Additionally some ASSERT()s are added for verif
> -Original Message-
> From: Ian Jackson
> Sent: 18 February 2020 11:48
> To: Durrant, Paul
> Cc: xen-devel@lists.xenproject.org; Wei Liu ; Anthony Perard
> ; Andrew Cooper ;
> George Dunlap ; Jan Beulich ;
> Julien Grall ; Konrad Rzeszutek Wilk
> ; Stefano Stabellini ;
> Jason Andryuk
>
Durrant, Paul writes ("RE: [PATCH v5 5/7] libxl: allow creation of domains with
a specified or random domid"):
> Ian Jackson
> > Sorry if I was confused; I will read this again.
>
> It is hard to follow the error paths. Early on in development I ended up with
> domains getting destroyed when I
On Tue, Feb 18, 2020 at 11:35:37AM +, Andrew Cooper wrote:
>
>
> On 18/02/2020 11:22, Roger Pau Monné wrote:
> > On Tue, Feb 18, 2020 at 11:21:12AM +, Andrew Cooper wrote:
> >> On 18/02/2020 11:10, Roger Pau Monné wrote:
> >>> On Tue, Feb 18, 2020 at 10:53:45AM +, Andrew Cooper wrote:
On 18/02/2020 11:28, Jan Beulich wrote:
> On 18.02.2020 12:21, Andrew Cooper wrote:
>> On 18/02/2020 11:10, Roger Pau Monné wrote:
>>> On Tue, Feb 18, 2020 at 10:53:45AM +, Andrew Cooper wrote:
On 17/02/2020 18:43, Roger Pau Monne wrote:
> @@ -67,7 +68,20 @@ static void send_IPI_shortc
flight 147166 linux-4.14 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/147166/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-armhf-armhf-xl-credit2 7 xen-boot fail REGR. vs. 142849
test-armhf-armhf-xl
> -Original Message-
> From: Ian Jackson
> Sent: 18 February 2020 11:17
> To: Durrant, Paul
> Cc: xen-devel@lists.xenproject.org; Wei Liu ; Anthony Perard
> ; Andrew Cooper ;
> George Dunlap ; Jan Beulich ;
> Julien Grall ; Konrad Rzeszutek Wilk
> ; Stefano Stabellini ;
> Jason Andryuk
>
Durrant, Paul writes ("RE: [PATCH v5 4/7] libxl: add infrastructure to track
and query 'recent' domids"):
> Ian Jackson :
> > Paul Durrant writes ("[PATCH v5 4/7] libxl: add infrastructure to track
> > > +int libxl_clear_domid_history(libxl_ctx *ctx);
> >
> > I think this needs a clear doc commen
On 18/02/2020 11:22, Roger Pau Monné wrote:
> On Tue, Feb 18, 2020 at 11:21:12AM +, Andrew Cooper wrote:
>> On 18/02/2020 11:10, Roger Pau Monné wrote:
>>> On Tue, Feb 18, 2020 at 10:53:45AM +, Andrew Cooper wrote:
On 17/02/2020 18:43, Roger Pau Monne wrote:
> @@ -67,7 +68,20 @@
On 18.02.2020 12:21, Andrew Cooper wrote:
> On 18/02/2020 11:10, Roger Pau Monné wrote:
>> On Tue, Feb 18, 2020 at 10:53:45AM +, Andrew Cooper wrote:
>>> On 17/02/2020 18:43, Roger Pau Monne wrote:
@@ -67,7 +68,20 @@ static void send_IPI_shortcut(unsigned int shortcut,
int vector,
>>
On Tue, Feb 18, 2020 at 11:21:12AM +, Andrew Cooper wrote:
> On 18/02/2020 11:10, Roger Pau Monné wrote:
> > On Tue, Feb 18, 2020 at 10:53:45AM +, Andrew Cooper wrote:
> >> On 17/02/2020 18:43, Roger Pau Monne wrote:
> >>> @@ -67,7 +68,20 @@ static void send_IPI_shortcut(unsigned int shortc
On 18/02/2020 11:10, Roger Pau Monné wrote:
> On Tue, Feb 18, 2020 at 10:53:45AM +, Andrew Cooper wrote:
>> On 17/02/2020 18:43, Roger Pau Monne wrote:
>>> @@ -67,7 +68,20 @@ static void send_IPI_shortcut(unsigned int shortcut, int
>>> vector,
>>> void send_IPI_mask(const cpumask_t *mask, int
Hi Roger,
On 18/02/2020 09:48, Roger Pau Monné wrote:
On Mon, Feb 17, 2020 at 07:29:29PM +, Julien Grall wrote:
Hi Roger,
On 17/02/2020 18:43, Roger Pau Monne wrote:
Add helpers to track when executing in #MC context. This is modeled
after the in_irq helpers.
Note that there are no users
Durrant, Paul writes ("RE: [PATCH v5 5/7] libxl: allow creation of domains with
a specified or random domid"):
> No, the domain will not be leaked. The existing failure handling in libxl
> will clean up if *domid != INVALID_DOMID.
Sorry if I was confused; I will read this again.
> > > diff --gi
On Tue, Feb 18, 2020 at 10:53:45AM +, Andrew Cooper wrote:
> On 17/02/2020 18:43, Roger Pau Monne wrote:
> > @@ -67,7 +68,20 @@ static void send_IPI_shortcut(unsigned int shortcut, int
> > vector,
> > void send_IPI_mask(const cpumask_t *mask, int vector)
> > {
> > bool cpus_locked = fal
On Tue, Feb 18, 2020 at 10:40:02AM +, Andrew Cooper wrote:
> On 17/02/2020 18:43, Roger Pau Monne wrote:
> > Add helpers to track when running in #MC context. This is modeled
> > after the in_irq helpers, but does not support reentry.
> >
> > Note that there are no users of in_mc() introduced b
On 17/02/2020 18:43, Roger Pau Monne wrote:
> @@ -67,7 +68,20 @@ static void send_IPI_shortcut(unsigned int shortcut, int
> vector,
> void send_IPI_mask(const cpumask_t *mask, int vector)
> {
> bool cpus_locked = false;
> -cpumask_t *scratch = this_cpu(scratch_cpumask);
> +cpumask_t
On 18.02.20 11:26, Andrew Cooper wrote:
On 18/02/2020 07:40, Jürgen Groß wrote:
On 17.02.20 19:43, Roger Pau Monne wrote:
Hello,
Commit:
5500d265a2a8fa63d60c08beb549de8ec82ff7a5
x86/smp: use APIC ALLBUT destination shorthand when possible
Introduced a bogus usage of the scratch cpumask: it w
On 18.02.20 11:15, Roger Pau Monné wrote:
On Tue, Feb 18, 2020 at 08:40:58AM +0100, Jürgen Groß wrote:
On 17.02.20 19:43, Roger Pau Monne wrote:
Hello,
Commit:
5500d265a2a8fa63d60c08beb549de8ec82ff7a5
x86/smp: use APIC ALLBUT destination shorthand when possible
Introduced a bogus usage of th
On Mon, Feb 17, 2020 at 06:34:12PM +0100, Roger Pau Monné wrote:
> On Mon, Feb 17, 2020 at 01:55:17PM +, 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 17/02/2020 18:43, Roger Pau Monne wrote:
> Add helpers to track when running in #MC context. This is modeled
> after the in_irq helpers, but does not support reentry.
>
> Note that there are no users of in_mc() introduced by the change,
> further users will be added by followup changes.
>
> Sign
On Mon, Feb 17, 2020 at 07:51:42PM +, Michael Kelley wrote:
> From: Wei Liu On Behalf Of Wei Liu
>
> [snip]
>
> > diff --git a/xen/arch/x86/guest/hyperv/util.c
> > b/xen/arch/x86/guest/hyperv/util.c
> > new file mode 100644
> > index 00..0abb37b05f
> > --- /dev/null
> > +++ b/xen/ar
On 18/02/2020 07:40, Jürgen Groß wrote:
> On 17.02.20 19:43, Roger Pau Monne wrote:
>> Hello,
>>
>> Commit:
>>
>> 5500d265a2a8fa63d60c08beb549de8ec82ff7a5
>> x86/smp: use APIC ALLBUT destination shorthand when possible
>>
>> Introduced a bogus usage of the scratch cpumask: it was used in a
>> funct
On Tue, Feb 18, 2020 at 08:40:58AM +0100, Jürgen Groß wrote:
> On 17.02.20 19:43, Roger Pau Monne wrote:
> > Hello,
> >
> > Commit:
> >
> > 5500d265a2a8fa63d60c08beb549de8ec82ff7a5
> > x86/smp: use APIC ALLBUT destination shorthand when possible
> >
> > Introduced a bogus usage of the scratch cp
On Mon, Feb 17, 2020 at 07:29:29PM +, Julien Grall wrote:
> Hi Roger,
>
> On 17/02/2020 18:43, Roger Pau Monne wrote:
> > Add helpers to track when executing in #MC context. This is modeled
> > after the in_irq helpers.
> >
> > Note that there are no users of in_mc() introduced by the change,
> -Original Message-
> From: Ian Jackson
> Sent: 17 February 2020 17:52
> To: Durrant, Paul
> Cc: xen-devel@lists.xenproject.org; Wei Liu ; Anthony Perard
> ; Andrew Cooper ;
> George Dunlap ; Jan Beulich ;
> Julien Grall ; Konrad Rzeszutek Wilk
> ; Stefano Stabellini ;
> Jason Andryuk
>
On Mon, Feb 17, 2020 at 07:29:29PM +, Julien Grall wrote:
> Hi Roger,
>
> On 17/02/2020 18:43, Roger Pau Monne wrote:
> > Add helpers to track when executing in #MC context. This is modeled
> > after the in_irq helpers.
> >
> > Note that there are no users of in_mc() introduced by the change,
> -Original Message-
> From: Ian Jackson
> Sent: 17 February 2020 17:43
> To: Durrant, Paul
> Cc: xen-devel@lists.xenproject.org; Wei Liu ; Anthony Perard
>
> Subject: Re: [PATCH v5 4/7] libxl: add infrastructure to track and query
> 'recent' domids
>
> Paul Durrant writes ("[PATCH v5 4
flight 147161 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/147161/
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
On Mon, Feb 17, 2020 at 11:05:53PM +, Anchal Agarwal wrote:
> On Mon, Feb 17, 2020 at 11:05:09AM +0100, Roger Pau Monné wrote:
> > On Fri, Feb 14, 2020 at 11:25:34PM +, Anchal Agarwal wrote:
> > > From: Munehisa Kamata > >
> > > Add freeze, thaw and restore callbacks for PM suspend and hi
Hi all,
I think that it might be of interest to this list, so I'm sending a
brief description of our workshop's scope, Virtualization in
High-performance Cloud computing (VHPC, https://vhpc.org), an
academic/industry workshop held in conjunction with ISC-HPC
(https://isc-hpc.com) in Frankfurt, Jun
> From: Roger Pau Monne
> Sent: Monday, February 17, 2020 7:46 PM
>
> Current implementation of nested VMX has a half baked handling of MSR
> bitmaps for the L1 VMM: it maps the L1 VMM provided MSR bitmap, but
> doesn't actually load it into the nested vmcs, and thus the nested
> guest vmcs ends
On 17.02.2020 16:14, Jan Beulich wrote:
> On 30.01.2020 14:07, Alexandru Stefan ISAILA wrote:
>> @@ -4814,6 +4815,30 @@ static int do_altp2m_op(
>> break;
>> }
>>
>> +case HVMOP_altp2m_set_visibility:
>> +{
>> +uint16_t altp2m_idx = a.u.set_visibility.altp2m_idx
95 matches
Mail list logo
