On 17.02.2020 20:06, Andrew Cooper wrote:
> On 17/02/2020 13:09, Jan Beulich wrote:
>> On 10.02.2020 15:28, Andrew Cooper wrote:
>>> On 05/02/2020 09:43, Jan Beulich wrote:
Introduce IOMMU_PDE_NEXT_LEVEL_{MIN,MAX} to replace literal 1, 6, and 7
instances. While doing so replace two uses
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
function that could be called from interrupt context, and hence
flight 147157 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/147157/
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
On 18.02.20 01:39, Glen wrote:
Hello Sander -
If I might chime in, I'm also experiencing what we believe is the same
problem, and hope I'm not breaking any protocol by sharing a few quick
details...
On Mon, Feb 17, 2020 at 3:46 PM Sander Eikelenboom wrote:
On 17/02/2020 20:58, Sarah Newman
> From: Juergen Gross
> Sent: Thursday, February 13, 2020 8:55 PM
>
> 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
Reviewed-by: Kevin Tian
> From: Juergen Gross
> Sent: Tuesday, February 11, 2020 5:31 PM
>
> One of the main design goals of core scheduling is to avoid actions
> which are not directly related to the domain currently running on a
> given cpu or core. Live patching is one of those actions which are
> allowed taking
I am working on a project related to hypervisor.I used the command
xentrace -d -e 0xf000-T 20 trace.bin
xnalyze trace.bin > x.txt
HOW TO ANALYZE THIS FILE AND TO GET WHAT HYPERCALL THIS HYPERCALL NUMBER
CORRESPOND TO
Total time: 9.98 seconds (using cpu speed 2.40 GHz)
--- Log volume summary
> From: Jan Beulich
> Sent: Thursday, February 6, 2020 11:20 PM
>
> Both callers request the host P2M's default access, which can as well be
> done inside the function. While touching this anyway, make the "gfn"
> parameter type-safe as well.
>
> Signed-off-by: Jan Beulich
Reviewed-by: Kevin
> From: Jan Beulich
> Sent: Thursday, February 6, 2020 11:35 PM
>
> The field looks to have been bogusly added by the patch introducing the
> struct (431685e8deb6 "VT-d: add command line option for extra rmrrs").
>
> Signed-off-by: Jan Beulich
>
Reviewed-by: Kevin Tian
> From: Jan Beulich
> Sent: Thursday, February 6, 2020 9:31 PM
> To: xen-devel@lists.xenproject.org
> Cc: Tian, Kevin
> Subject: [PATCH 2/2] VT-d: adjust logging of RMRRs
>
> Consistently use [,] range representation, shrink leading double blanks
> to a single one, and slightly adjust text in
> From: Jan Beulich
> Sent: Thursday, February 6, 2020 9:31 PM
>
> Checking just the first and last page is not sufficient (and redundant
> for single-page regions). As we don't need to care about IA64 anymore,
> use an x86-specific function to get this done without looping over each
>
Hello Sander -
If I might chime in, I'm also experiencing what we believe is the same
problem, and hope I'm not breaking any protocol by sharing a few quick
details...
On Mon, Feb 17, 2020 at 3:46 PM Sander Eikelenboom wrote:
> On 17/02/2020 20:58, Sarah Newman wrote:
> > On 1/7/20 6:25 AM,
> From: Jan Beulich
> Sent: Saturday, February 1, 2020 12:42 AM
>
> It's not needed there and introduces a needless, almost global
> dependency. Include the file (or in some cases just xen/err.h) where
> actually needed, or - in one case - simply forward-declare a struct. In
> microcode*.c take
flight 147160 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/147160/
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
flight 147218 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/147218/
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
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, Dec 31, 2019, at 12:27 AM, Andrew Cooper wrote:
Is there any full boot log in the
flight 147144 linux-4.19 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/147144/
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
flight 147140 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/147140/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-xl-rtds 18 guest-localmigrate/x10 fail like 147069
On 17/02/2020 20:58, Sarah Newman wrote:
> On 1/7/20 6:25 AM, Alastair Browne wrote:
>>
>> CONCLUSION
>>
>> So in conclusion, the tests indicate that credit2 might be unstable.
>>
>> For the time being, we are using credit as the chosen scheduler. We
>> are booting the kernel with a parameter
On 2/14/20 10:47 AM, Ian Jackson wrote:
Jim Fehlig writes ("[OSSTEST PATCH V2] build: fix configuration of libvirt"):
libvirt.git commit 2621d48f00 removed the last traces of gnulib, which
also removed the '--no-git' option from autogen.sh. Unknown options are
now passed to the configure
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 hibernation
> > support. All frontend drivers that needs to use
flight 147213 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/147213/
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
Clang 8.0 (see [1]) and by extent some of the version of armclang does
not support register allocation using the syntax rN.
Thankfully, both GCC [2] and clang are able to support the xN syntax for
Arm64. Introduce a new macro ASM_REG() and use in common code for
register allocation.
[1]
Hi George,
On 06/02/2020 12:08, George Dunlap wrote:
On 2/3/20 4:58 PM, Julien Grall wrote:
From: Julien Grall
It is not entirely clear why the slot 0 of each p2m should be populated
with empty page-tables. The commit introducing it 759af8e3800 "[HVM]
Fix 64-bit HVM domain creation." does
Hi Roger,
Thank you for the renaming.
On 17/02/2020 11:45, Roger Pau Monne wrote:
So BIT_WORD can be imported from Linux. The difference between current
Linux implementation of BIT_WORD is that the size of the word unit is
a long integer, while the Xen one is hardcoded to 32 bits.
Current
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, Dec 31, 2019, at 12:27 AM, Andrew Cooper wrote:
> >>> Is there any full boot log in the bad case? Debugging via
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/arch/x86/guest/hyperv/util.c
> @@ -0,0 +1,74 @@
>
On 1/7/20 6:25 AM, Alastair Browne wrote:
CONCLUSION
So in conclusion, the tests indicate that credit2 might be unstable.
For the time being, we are using credit as the chosen scheduler. We
are booting the kernel with a parameter "sched=credit" to ensure that
the correct scheduler is used.
flight 147129 linux-5.4 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/147129/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-xl-shadow23 leak-check/check fail REGR. vs. 146121
On 17/02/2020 19:19, Jason Andryuk wrote:
> enabling vecOn Tue, Dec 31, 2019 at 5:43 AM Aaron Janse
> wrote:
>> On Tue, Dec 31, 2019, at 12:27 AM, Andrew Cooper wrote:
>>> Is there any full boot log in the bad case? Debugging via divination
>>> isn't an effective way to get things done.
>>
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,
further users will be added by followup changes.
Signed-off-by: Roger Pau Monné
enabling vecOn Tue, Dec 31, 2019 at 5:43 AM Aaron Janse wrote:
>
> On Tue, Dec 31, 2019, at 12:27 AM, Andrew Cooper wrote:
> > Is there any full boot log in the bad case? Debugging via divination
> > isn't an effective way to get things done.
>
> Agreed. I included some more verbose logs towards
On 17/02/2020 13:09, Jan Beulich wrote:
> On 10.02.2020 15:28, Andrew Cooper wrote:
>> On 05/02/2020 09:43, Jan Beulich wrote:
>>> Introduce IOMMU_PDE_NEXT_LEVEL_{MIN,MAX} to replace literal 1, 6, and 7
>>> instances. While doing so replace two uses of memset() by initializers.
>>>
>>>
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,
further users will be added by followup changes.
Signed-off-by: Roger Pau Monné
---
xen/arch/x86/cpu/mcheck/mce.c | 2 ++
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.
Signed-off-by: Roger Pau Monné
---
xen/arch/x86/traps.c
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 to be used by send_IPI_mask, and
disable interrupts
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
function that could be called from interrupt context, and hence using
the scratch cpumask there is not safe.
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
Acked-by: Jan Beulich
---
xen/include/asm-x86/smp.h | 5 +
1 file changed, 1 insertion(+), 4 deletions(-)
diff --git
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
This is modeled after the irq_count variable, and is used to account
for all the NMIs handled by the system.
This will allow to repurpose the nmi_count() helper so it can be used
in a similar manner as local_irq_count(): account for the NMIs
currently in service.
Signed-off-by: Roger Pau Monné
Andrew Cooper writes ("[PATCH v2 5/6] tools/libx[cl]: Don't use
HVM_PARAM_PAE_ENABLED as a function parameter"):
> HVM_PARAM_PAE_ENABLED is set and consumed by the toolstack only. It is in
> practice a complicated and non-standard way of passing a boolean parameter
> into
HVM_PARAM_PAE_ENABLED is set and consumed by the toolstack only. It is in
practice a complicated and non-standard way of passing a boolean parameter
into xc_cpuid_apply_policy().
This is silly. Pass PAE as a regular parameter instead.
In libxl__cpuid_legacy(), leave a rather better
Paul Durrant writes ("[PATCH v5 7/7] xl: allow domid to be preserved on
save/restore or migrate"):
> This patch adds a '-D' command line option to save and migrate to allow
> the domain id to be incorporated into the saved domain configuration and
> hence be preserved.
>
> NOTE: Logically it may
Paul Durrant writes ("[PATCH v5 5/7] libxl: allow creation of domains with a
specified or random domid"):
> This patch adds a 'domid' field to libxl_domain_create_info and then
> modifies libxl__domain_make() to have Xen use that value if it is valid.
> If the domid value is invalid then Xen will
branch xen-unstable
xenbranch xen-unstable
job test-amd64-i386-xl-qemuu-ovmf-amd64
testid debian-hvm-install
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
Paul Durrant writes ("[PATCH v5 4/7] libxl: add infrastructure to track and
query 'recent' domids"):
> A domid is considered recent if the domain it represents was destroyed
> less than a specified number of seconds ago. For debugging and/or testing
> purposes the number can be set using the
branch xen-unstable
xenbranch xen-unstable
job test-armhf-armhf-xl
testid xen-boot
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: qemuu
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_ADDRESS_LIST_EX
> * HVCALL_FLUSH_VIRTUAL_ADDRESS_SPACE
> *
On 14.02.2020 19:55, Andrew Cooper wrote:
> There is no need to have both helpers implement the same workaround. The size
> and layout of the the Event and PPR logs (and others for that matter) share a
> lot of commonality.
>
> Use MASK_EXTR() to locate the code field, and use ACCESS_ONCE()
Andrew Cooper writes ("[PATCH 5/6] tools/libx[cl]: Don't use
HVM_PARAM_PAE_ENABLED as a function parameter"):
> The sole use of HVM_PARAM_PAE_ENABLED is as a non-standard calling
> convention for xc_cpuid_apply_policy(). Pass PAE as a regular
> parameter instead.
Following our conversation on
On 17.02.20 15:23, Igor Druzhinin wrote:
On 17/02/2020 12:30, Igor Druzhinin wrote:
On 17/02/2020 12:28, Jürgen Groß wrote:
On 17.02.20 13:26, Igor Druzhinin wrote:
On 17/02/2020 07:20, Juergen Gross wrote:
Today rcu_barrier() is calling stop_machine_run() to synchronize all
physical cpus in
From: Oleksandr Tyshchenko
For the IPMMU-VMSA we need to prevent the use cases where devices
which use the same micro-TLB are assigned to different Xen domains
(micro-TLB cannot be shared between multiple Xen domains, since it
points to the context bank to use for the page walk).
As each Xen
Am Mon, 27 Jan 2020 11:54:37 +
schrieb "Durrant, Paul" :
> I suppose. Could we have "pc-i440fx" as the default, which libxl prefix
> matches against qemu's supported versions to select the latest? I guess that
> would work.
This can not be fixed in libxl because libxl can not possibly know
Ping?
> -Original Message-
> From: Paul Durrant
> Sent: 31 January 2020 15:02
> To: xen-devel@lists.xenproject.org
> Cc: Durrant, Paul ; Andrew Cooper
> ; Anthony PERARD ;
> George Dunlap ; Ian Jackson
> ; Jan Beulich ; Jason
> Andryuk ; Julien Grall ; Konrad
> Rzeszutek Wilk ; Stefano
On 17/02/2020 12:30, Igor Druzhinin wrote:
> On 17/02/2020 12:28, Jürgen Groß wrote:
>> On 17.02.20 13:26, Igor Druzhinin wrote:
>>> On 17/02/2020 07:20, Juergen Gross wrote:
Today rcu_barrier() is calling stop_machine_run() to synchronize all
physical cpus in order to ensure all pending
> -Original Message-
> From: Wei Liu On Behalf Of Wei Liu
> Sent: 17 February 2020 13:55
> To: Xen Development List
> Cc: Michael Kelley ; Durrant, Paul
> ; Wei Liu ; Roger Pau Monné
> ; Wei Liu ; Jan Beulich
> ; Andrew Cooper
> Subject: [PATCH v3 2/3] x86/hyperv: skeleton for L0
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;
> +
> +if ( a.u.set_visibility.pad ||
Hi all
This seris is based on Roger's L0 assisted flush series.
I have done some testing against a Linux on Hyper-V in a 32-vcpu VM.
All builds were done with -j32.
Building Xen on Linux:
real0m45.376s
user2m28.156s
sys 0m51.672s
Building Xen on Linux on Xen on Hyper-V, no
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
* HVCALL_FLUSH_VIRTUAL_ADDRESS_SPACE
* HVCALL_FLUSH_VIRTUAL_ADDRESS_SPACE_EX
Pick the most efficient hypercalls available.
On 17.02.20 14:47, Roger Pau Monné wrote:
On Mon, Feb 17, 2020 at 02:17:23PM +0100, Jürgen Groß wrote:
On 17.02.20 13:49, Roger Pau Monné wrote:
On Mon, Feb 17, 2020 at 01:32:59PM +0100, Jürgen Groß wrote:
On 17.02.20 13:17, Roger Pau Monné wrote:
On Mon, Feb 17, 2020 at 01:11:59PM +0100,
Hyper-V's L0 assisted flush has fine-grained control over what gets
flushed. We need all the flags available to make the best decisions
possible.
No functional change because Xen's implementation doesn't care about
what is passed to it.
Signed-off-by: Wei Liu
Reviewed-by: Roger Pau Monné
flight 147141 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/147141/
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
Implement a basic hook for L0 assisted TLB flush. The hook needs to
check if prerequisites are met. If they are not met, it returns an error
number to fall back to native flushes.
Introduce a new variable to indicate if hypercall page is ready.
Signed-off-by: Wei Liu
Reviewed-by: Roger Pau
On 03.02.2020 12:21, Wei Xu wrote:
> Parse the ACPI SPCR table and initialize the 16550 compatible serial port
> for ARM only. Currently we only support one UART on ARM. Some fields
> which we do not care yet on ARM are ignored.
>
> Signed-off-by: Wei Xu
>
> ---
> Changes in v3:
> - address the
On Mon, Feb 17, 2020 at 02:17:23PM +0100, Jürgen Groß wrote:
> On 17.02.20 13:49, Roger Pau Monné wrote:
> > On Mon, Feb 17, 2020 at 01:32:59PM +0100, Jürgen Groß wrote:
> > > On 17.02.20 13:17, Roger Pau Monné wrote:
> > > > On Mon, Feb 17, 2020 at 01:11:59PM +0100, Jürgen Groß wrote:
> > > > >
On 17.02.20 13:49, Roger Pau Monné wrote:
On Mon, Feb 17, 2020 at 01:32:59PM +0100, Jürgen Groß wrote:
On 17.02.20 13:17, Roger Pau Monné wrote:
On Mon, Feb 17, 2020 at 01:11:59PM +0100, Jürgen Groß wrote:
On 17.02.20 12:49, Julien Grall wrote:
Hi Juergen,
On 17/02/2020 07:20, Juergen Gross
> -Original Message-
> From: Wei Liu
> Sent: 17 February 2020 12:48
> To: Durrant, Paul
> Cc: Roger Pau Monné ; Wei Liu ; Xen
> Development List ; Michael Kelley
> ; Wei Liu ; Jan Beulich
> ; Andrew Cooper
> Subject: Re: [PATCH v2 2/3] x86/hyperv: skeleton for L0 assisted TLB flush
>
>
On 10.02.2020 15:28, Andrew Cooper wrote:
> On 05/02/2020 09:43, Jan Beulich wrote:
>> Introduce IOMMU_PDE_NEXT_LEVEL_{MIN,MAX} to replace literal 1, 6, and 7
>> instances. While doing so replace two uses of memset() by initializers.
>>
>> Signed-off-by: Jan Beulich
>
> This does not look to be
On Mon, Feb 17, 2020 at 01:32:59PM +0100, Jürgen Groß wrote:
> On 17.02.20 13:17, Roger Pau Monné wrote:
> > On Mon, Feb 17, 2020 at 01:11:59PM +0100, Jürgen Groß wrote:
> > > On 17.02.20 12:49, Julien Grall wrote:
> > > > Hi Juergen,
> > > >
> > > > On 17/02/2020 07:20, Juergen Gross wrote:
> >
On Mon, Feb 17, 2020 at 12:21:09PM +, Durrant, Paul wrote:
> > -Original Message-
> > From: Roger Pau Monné
> > Sent: 17 February 2020 12:08
> > To: Durrant, Paul
> > Cc: Wei Liu ; Xen Development List > de...@lists.xenproject.org>; Michael Kelley ; Wei
> > Liu ; Jan Beulich ;
On Mon, Feb 17, 2020 at 01:13:28PM +0100, Roger Pau Monné wrote:
> On Mon, Feb 17, 2020 at 12:08:01PM +, Wei Liu wrote:
> > On Mon, Feb 17, 2020 at 01:00:54PM +0100, Roger Pau Monné wrote:
> > > On Mon, Feb 17, 2020 at 11:45:38AM +, Wei Liu wrote:
> > > > On Mon, Feb 17, 2020 at 12:40:31PM
> -Original Message-
> From: Roger Pau Monné
> Sent: 17 February 2020 12:08
> To: Durrant, Paul
> Cc: Wei Liu ; Xen Development List de...@lists.xenproject.org>; Michael Kelley ; Wei
> Liu ; Jan Beulich ; Andrew Cooper
>
> Subject: Re: [PATCH v2 2/3] x86/hyperv: skeleton for L0
On 17.02.20 13:17, Roger Pau Monné wrote:
On Mon, Feb 17, 2020 at 01:11:59PM +0100, Jürgen Groß wrote:
On 17.02.20 12:49, Julien Grall wrote:
Hi Juergen,
On 17/02/2020 07:20, Juergen Gross wrote:
+void rcu_barrier(void)
{
- atomic_t cpu_count = ATOMIC_INIT(0);
- return
On 17/02/2020 12:28, Jürgen Groß wrote:
> On 17.02.20 13:26, Igor Druzhinin wrote:
>> On 17/02/2020 07:20, Juergen Gross wrote:
>>> 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.
>>>
On 17.02.20 13:26, Igor Druzhinin wrote:
On 17/02/2020 07:20, Juergen Gross wrote:
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
On 17/02/2020 07:20, Juergen Gross wrote:
> 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
> -Original Message-
> From: Roger Pau Monné
> Sent: 17 February 2020 11:41
> To: Wei Liu
> Cc: Durrant, Paul ; Xen Development List de...@lists.xenproject.org>; Michael Kelley ; Wei
> Liu ; Jan Beulich ; Andrew Cooper
>
> Subject: Re: [PATCH v2 2/3] x86/hyperv: skeleton for L0
On Mon, Feb 17, 2020 at 01:11:59PM +0100, Jürgen Groß wrote:
> On 17.02.20 12:49, Julien Grall wrote:
> > Hi Juergen,
> >
> > On 17/02/2020 07:20, Juergen Gross wrote:
> > > +void rcu_barrier(void)
> > > {
> > > - atomic_t cpu_count = ATOMIC_INIT(0);
> > > - return
On Mon, Feb 17, 2020 at 12:08:01PM +, Wei Liu wrote:
> On Mon, Feb 17, 2020 at 01:00:54PM +0100, Roger Pau Monné wrote:
> > On Mon, Feb 17, 2020 at 11:45:38AM +, Wei Liu wrote:
> > > On Mon, Feb 17, 2020 at 12:40:31PM +0100, Roger Pau Monné wrote:
> > > > On Mon, Feb 17, 2020 at 11:34:41AM
On 17.02.20 12:49, Julien Grall wrote:
Hi Juergen,
On 17/02/2020 07:20, Juergen Gross wrote:
+void rcu_barrier(void)
{
- atomic_t cpu_count = ATOMIC_INIT(0);
- return stop_machine_run(rcu_barrier_action, _count, NR_CPUS);
+ if ( !atomic_cmpxchg(_count, 0, num_online_cpus()) )
What
On Mon, Feb 17, 2020 at 12:01:23PM +, Durrant, Paul wrote:
> > -Original Message-
> > From: Roger Pau Monné
> > Sent: 17 February 2020 11:41
> > To: Wei Liu
> > Cc: Durrant, Paul ; Xen Development List > de...@lists.xenproject.org>; Michael Kelley ; Wei
> > Liu ; Jan Beulich ;
On Mon, Feb 17, 2020 at 01:00:54PM +0100, Roger Pau Monné wrote:
> On Mon, Feb 17, 2020 at 11:45:38AM +, Wei Liu wrote:
> > On Mon, Feb 17, 2020 at 12:40:31PM +0100, Roger Pau Monné wrote:
> > > On Mon, Feb 17, 2020 at 11:34:41AM +, Wei Liu wrote:
> > > > On Fri, Feb 14, 2020 at 04:55:44PM
On Fri, Feb 14, 2020 at 04:42:47PM +, Michael Kelley wrote:
> From: Wei Liu On Behalf Of Wei Liu Sent: Friday,
> February 14, 2020 4:35 AM
> >
> > Implement L0 assisted TLB flush for Xen on Hyper-V. It takes advantage
> > of several hypercalls:
> >
> > * HVCALL_FLUSH_VIRTUAL_ADDRESS_LIST
On Mon, Feb 17, 2020 at 11:45:38AM +, Wei Liu wrote:
> On Mon, Feb 17, 2020 at 12:40:31PM +0100, Roger Pau Monné wrote:
> > On Mon, Feb 17, 2020 at 11:34:41AM +, Wei Liu wrote:
> > > On Fri, Feb 14, 2020 at 04:55:44PM +, Durrant, Paul wrote:
> > > > > -Original Message-
> > > >
Hi all,
Any ideas on this patch appreciated.
Regards,
Alex
On 30.01.2020 15:07, Alexandru Stefan ISAILA wrote:
> At this moment a guest can call vmfunc to change the altp2m view. This
> should be limited in order to avoid any unwanted view switch.
>
> The new xc_altp2m_set_visibility() solves
Hi Juergen,
On 17/02/2020 07:20, Juergen Gross wrote:
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
Nested VMX doesn't expose support for
SECONDARY_EXEC_VIRTUALIZE_X2APIC_MODE,
SECONDARY_EXEC_VIRTUAL_INTR_DELIVERY or
SECONDARY_EXEC_APIC_REGISTER_VIRT, and hence the x2APIC MSRs should
always be trapped in the nested guest MSR bitmap, or else a nested
guest could access the hardware x2APIC MSRs
So BIT_WORD can be imported from Linux. The difference between current
Linux implementation of BIT_WORD is that the size of the word unit is
a long integer, while the Xen one is hardcoded to 32 bits.
Current users of BITOP_WORD on Arm (which considers a word a long
integer) are switched to use
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 up using the same MSR bitmap as the L1 VMM.
This is wrong as there's no
Import the functions and it's dependencies. Based on Linux 5.5, commit
id d5226fa6dbae0569ee43ecfc08bdcd6770fc4755.
Signed-off-by: Roger Pau Monné
---
Changes since v4:
- Introduce BIT_WORD in generic header bitops.h (instead of the x86
one).
- Include byteorder.h for __LITTLE_ENDIAN
-
On Mon, Feb 17, 2020 at 12:40:31PM +0100, Roger Pau Monné wrote:
> On Mon, Feb 17, 2020 at 11:34:41AM +, Wei Liu wrote:
> > On Fri, Feb 14, 2020 at 04:55:44PM +, Durrant, Paul wrote:
> > > > -Original Message-
> > > > From: Wei Liu On Behalf Of Wei Liu
> > > > Sent: 14 February
Hello,
Current nested VMX code advertises support for the MSR bitmap feature,
yet the implementation isn't done. Previous to this series Xen just maps
the nested guest MSR bitmap (as set by L1) and that's it, the L2 guest
ends up using the L1 MSR bitmap.
This series adds handling of the L2 MSR
On Mon, Feb 17, 2020 at 11:34:41AM +, Wei Liu wrote:
> On Fri, Feb 14, 2020 at 04:55:44PM +, Durrant, Paul wrote:
> > > -Original Message-
> > > From: Wei Liu On Behalf Of Wei Liu
> > > Sent: 14 February 2020 13:34
> > > To: Xen Development List
> > > Cc: Michael Kelley ;
On Fri, Feb 14, 2020 at 04:55:44PM +, Durrant, Paul wrote:
> > -Original Message-
> > From: Wei Liu On Behalf Of Wei Liu
> > Sent: 14 February 2020 13:34
> > To: Xen Development List
> > Cc: Michael Kelley ; Durrant, Paul
> > ; Wei Liu ; Wei Liu
> > ; Jan Beulich ; Andrew Cooper
> >
The name async_exception isn't appropriate. NMI isn't an exception at all,
and while MCE is classified as an exception (i.e. can occur at any point), the
mechanics of injecting it behave like other external interrupts. Rename to
async_event_* which is a little shorter.
Drop VCPU_TRAP_NONE and
The hardware domain doesn't necessarily have the domid 0. Render v instead,
adjusting the strings to avoid printing trailing whitespace.
Rename i to cpu, and use separate booleans for pending/masked. Drop the
unnecessary domain local variable.
Signed-off-by: Andrew Cooper
---
CC: Jan Beulich
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 other architectures. Move it all into x86
specific
This infrastructure is only compiled for x86, very x86 specific (so of no
interest to other architectures), and very broken.
Amongst other things, MCEs have a higher priority than NMIs, and there is no
such thing as masking an MCE. In order to address these bugs (which will
completely change the
flight 147111 linux-4.4 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/147111/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-qemuu-nested-amd 14 xen-boot/l1 fail REGR. vs. 139698
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 hibernation
> support. All frontend drivers that needs to use PM_HIBERNATION/PM_SUSPEND
> events, need to implement these xenbus_driver callbacks.
>
100 matches
Mail list logo
