On 18/04/18 12:43, Andrew Cooper wrote:
> This avoids opencoding the functionality (and missing one bit of it), and and
> some comments explaining what is going on.
>
> Signed-off-by: Andrew Cooper
Release-acked-by: Juergen Gross
Juergen
___
Xen-de
On 18/04/18 18:12, Jan Beulich wrote:
On 18.04.18 at 10:30, wrote:
>> @@ -160,5 +161,20 @@ unsigned int flush_area_local(const void *va, unsigned
>> int flags)
>>
>> local_irq_restore(irqfl);
>>
>> +if ( flags & FLUSH_ROOT_PGTBL )
>> +get_cpu_info()->root_pgt_changed = t
Hi Jan,
Thank you for reply. Maybe My description is not clear. Please allow me to
explain it again.
Multiple CPU may be share an channel(according to hpet_get_channel(), it is
possible ). When one of them get the lock of
channel(hpet_broadcast_exit()->hpet_detach_channel()->spin_lock_irq(&ch
Hi Jan，
Yes, I mean with another patch. And Thank you again.
-Original Message-
From: Jan Beulich [mailto:jbeul...@suse.com]
Sent: Wednesday, April 18, 2018 6:52 PM
To: Fiona Li(BJ-RD)
Cc: xen-devel
Subject: RE: RE: [PATCH] x86/cpu: Support a new cpu vendor,which is Shanghai
>>> On 18.0
On Wed, 18 Apr 2018, Julien Grall wrote:
> On 18/04/18 11:45, Mirela Simonovic wrote:
> > On Tue, Apr 17, 2018 at 4:11 PM, Julien Grall wrote:
> > >
> > >
> > > On 17/04/18 13:54, Mirela Simonovic wrote:
> > > >
> > > > Hi Julien,
> > >
> > >
> > > Hi,
> > >
> > > >
> > > > On Wed, Apr 11,
On Tue, 17 Apr 2018, Julien Grall wrote:
> On 17/04/18 11:52, Mirela Simonovic wrote:
> > Hi Julien,
>
> Hi Mirela,
>
> > On Mon, Apr 16, 2018 at 5:21 PM, Julien Grall wrote:
> > >
> > >
> > > On 16/04/18 14:41, Mirela Simonovic wrote:
> > > >
> > > > On Mon, Apr 16, 2018 at 3:14 PM, Julien G
Disable erratas because they don't apply to QEMU's software emulated
CPUs.
Arbitrarily choose a limit of 4 CPUs.
Select the credit and NULL schedulers only.
Signed-off-by: Stefano Stabellini
---
xen/arch/arm/configs/qemu.config | 81
1 file changed, 81
Hi all,
This patch series is the first step toward building a small certifiable
Xen hypervisor for ARM boards.
First, the series makes a few changes to allow disabling more kconfig
options: most of them already exist but cannot be disabled.
Then, it introduces a reference kconfig for Renesas RCa
On 04/18/2018 01:08 PM, Laura Abbott wrote:
> There's an ongoing effort to remove VLAs[1] from the kernel to eventually
> turn on -Wvla. It turns out, the few VLAs in use in Xen produce only a
> single entry array that is always bounded by GDT_SIZE. Clean up the code to
> get rid of the VLA and the
This is a reference tiny kconfig for Renesas RCar. In terms of
schedulers, it selects credit and NULL only. It enables all the ARM64
errata.
Signed-off-by: Stefano Stabellini
CC: artem_myga...@epam.com
CC: volodymyr_babc...@epam.com
---
This patch is untested on Renesas RCar, please test!
Als
Add a Xen build target to count the lines of code of the source files
built. Uses `cloc' to do the job.
Generate the list of source files from the %.o targets, append output
to "sourcelist".
Remove sourcelist on clean, and also at the beginning of the build
target to avoid appending to sourcelist
Make it possible to disable the following existing kconfig options:
HAS_GICV3
HAS_ARM_HDLCD
HAS_MEM_ACCESS
Today they are silent option. This patch adds one line descriptions and
make them de/selectable.
Also, do not select VIDEO: make HAS_ARM_HDLCD select VIDEO instead. In
fact, VIDEO is o
All the UART drivers are silent options. Add one line descriptions so
that can be de/selected via menuconfig.
Signed-off-by: Stefano Stabellini
---
xen/drivers/char/Kconfig | 16
1 file changed, 8 insertions(+), 8 deletions(-)
diff --git a/xen/drivers/char/Kconfig b/xen/drivers
Introduce a Kconfig option for the ARM SMMUv2 driver.
Signed-off-by: Stefano Stabellini
CC: jbeul...@suse.com
---
xen/drivers/passthrough/Kconfig | 2 ++
xen/drivers/passthrough/arm/Kconfig | 7 +++
xen/drivers/passthrough/arm/Makefile | 2 +-
3 files changed, 10 insertions(+), 1 delet
All of this is as recommended by the Intel whitepaper:
https://software.intel.com/sites/default/files/managed/1d/46/Retpoline-A-Branch-Target-Injection-Mitigation.pdf
The RSB-alternative bit in MSR_ARCH_CAPABILITIES may be set by a hypervisor to
indicate that the virtual machine may migrate to a
On Sat, 14 Apr 2018, Paul Durrant wrote:
> > -Original Message-
> > From: Roger Pau Monne
> > Sent: 13 April 2018 20:53
> > To: Lars Kurth
> > Cc: xen-devel ; Daniel Smith
> > ; Alexey G ; Stefano
> > Stabellini ; Julien Grall ;
> > Paul
> > Durrant ; Christopher Clark
> > ; Rich Persaud
There's an ongoing effort to remove VLAs[1] from the kernel to eventually
turn on -Wvla. It turns out, the few VLAs in use in Xen produce only a
single entry array that is always bounded by GDT_SIZE. Clean up the code to
get rid of the VLA and the loop.
[1] https://lkml.org/lkml/2018/3/7/621
Sig
On Wed, Apr 18, 2018 at 09:38:39AM +0300, Oleksandr Andrushchenko wrote:
> On 04/17/2018 11:57 PM, Dongwon Kim wrote:
> >On Tue, Apr 17, 2018 at 09:59:28AM +0200, Daniel Vetter wrote:
> >>On Mon, Apr 16, 2018 at 12:29:05PM -0700, Dongwon Kim wrote:
> >>>Yeah, I definitely agree on the idea of expan
On 18/04/18 17:14, Jan Beulich wrote:
On 18.04.18 at 18:02, wrote:
>> On 18/04/18 16:43, Jan Beulich wrote:
>> On 18.04.18 at 12:43, wrote:
This avoids opencoding the functionality (and missing one bit of it), and
and
some comments explaining what is going on.
>>> Missing
>>> On 18.04.18 at 18:02, wrote:
> On 18/04/18 16:43, Jan Beulich wrote:
> On 18.04.18 at 12:43, wrote:
>>> This avoids opencoding the functionality (and missing one bit of it), and
>>> and
>>> some comments explaining what is going on.
>> Missing which bit of it? The MSR writes aren't stric
>>> On 18.04.18 at 10:30, wrote:
> @@ -160,5 +161,20 @@ unsigned int flush_area_local(const void *va, unsigned
> int flags)
>
> local_irq_restore(irqfl);
>
> +if ( flags & FLUSH_ROOT_PGTBL )
> +get_cpu_info()->root_pgt_changed = true;
> +
> return flags;
> }
> +
> +void
>>> On 18.04.18 at 17:54, wrote:
> On 18/04/18 17:45, Jan Beulich wrote:
> On 18.04.18 at 17:33, wrote:
>>> On 18/04/18 17:29, Jan Beulich wrote:
>>> On 18.04.18 at 10:30, wrote:
> --- a/xen/arch/x86/mm/shadow/multi.c
> +++ b/xen/arch/x86/mm/shadow/multi.c
> @@ -967,7 +967,7
On 18/04/18 16:43, Jan Beulich wrote:
On 18.04.18 at 12:43, wrote:
>> This avoids opencoding the functionality (and missing one bit of it), and and
>> some comments explaining what is going on.
> Missing which bit of it? The MSR writes aren't strictly necessary afaict, and
> functionally clea
On Wed, Apr 18, 2018 at 03:42:29PM +0300, Oleksandr Andrushchenko wrote:
> On 04/18/2018 01:55 PM, Roger Pau Monné wrote:
> >On Wed, Apr 18, 2018 at 01:39:35PM +0300, Oleksandr Andrushchenko wrote:
> >>On 04/18/2018 01:18 PM, Paul Durrant wrote:
> -Original Message-
> From: Xen-deve
>>> On 18.04.18 at 12:26, wrote:
> @@ -1019,6 +1020,12 @@ void __init noreturn __start_xen(unsigned long mbi_p)
> bootsym(trampoline_xen_phys_start) = e;
>
> /*
> + * All PTEs with PFNs above pte_update_limit
> + * were updated earlier. Skip them
On 18/04/18 17:45, Jan Beulich wrote:
On 18.04.18 at 17:33, wrote:
>> On 18/04/18 17:29, Jan Beulich wrote:
>> On 18.04.18 at 10:30, wrote:
--- a/xen/arch/x86/mm/shadow/multi.c
+++ b/xen/arch/x86/mm/shadow/multi.c
@@ -967,7 +967,7 @@ static int shadow_set_l4e(struct domain
>>> On 18.04.18 at 11:25, wrote:
> From: David Wang
>
> For the ch->cpumask be cleared by other cpu, cpumask_first() called by
> hpet_detach_channel() return nr_cpu_ids. That lead an assertion in
> set_channel_irq_affinity() when cpumask_of() check cpu.
> Fix this by using a local variable.
The
>>> On 18.04.18 at 17:33, wrote:
> On 18/04/18 17:29, Jan Beulich wrote:
> On 18.04.18 at 10:30, wrote:
>>> --- a/xen/arch/x86/mm/shadow/multi.c
>>> +++ b/xen/arch/x86/mm/shadow/multi.c
>>> @@ -967,7 +967,7 @@ static int shadow_set_l4e(struct domain *d,
>>> sh_put_ref(d, osl3mfn, pad
>>> On 18.04.18 at 12:43, wrote:
> This avoids opencoding the functionality (and missing one bit of it), and and
> some comments explaining what is going on.
Missing which bit of it? The MSR writes aren't strictly necessary afaict, and
functionally clearing bti_ist_info is all that's needed for t
On 18/04/18 17:32, Jan Beulich wrote:
On 18.04.18 at 11:37, wrote:
>> On 18/04/18 11:13, Jan Beulich wrote:
>> On 18.04.18 at 10:30, wrote:
Avoid flushing the complete TLB when switching %cr3 for mitigation of
Meltdown by using the PCID feature if available.
We are us
On 18/04/18 17:29, Jan Beulich wrote:
On 18.04.18 at 10:30, wrote:
>> --- a/xen/arch/x86/mm/shadow/multi.c
>> +++ b/xen/arch/x86/mm/shadow/multi.c
>> @@ -967,7 +967,7 @@ static int shadow_set_l4e(struct domain *d,
>> sh_put_ref(d, osl3mfn, paddr);
>> }
>>
>> -if ( !cpu_has
>>> On 18.04.18 at 11:37, wrote:
> On 18/04/18 11:13, Jan Beulich wrote:
> On 18.04.18 at 10:30, wrote:
>>> Avoid flushing the complete TLB when switching %cr3 for mitigation of
>>> Meltdown by using the PCID feature if available.
>>>
>>> We are using 4 PCID values for a 64 bit pv domain subj
>>> On 18.04.18 at 10:30, wrote:
> --- a/xen/arch/x86/mm/shadow/multi.c
> +++ b/xen/arch/x86/mm/shadow/multi.c
> @@ -967,7 +967,7 @@ static int shadow_set_l4e(struct domain *d,
> sh_put_ref(d, osl3mfn, paddr);
> }
>
> -if ( !cpu_has_no_xpti )
> +if ( is_pv_domain(d) && d->a
On 04/16/2018 09:24 AM, Oleksandr Andrushchenko wrote:
From: Oleksandr Andrushchenko
Please note: this patch series depends on [3].
The dependency is now merged into Xen kernel tree [4] for-linus-4.17
This patch series adds support for Xen [1] para-virtualized
sound frontend driver. It imple
From: Oleksandr Andrushchenko
It is now only possible to control if multi-touch virtual device
is created or not (via the corresponding XenStore entries),
but keyboard and pointer devices are always created.
In some cases this is not desirable. For example, if virtual
keyboard device is exposed t
p2m_change_type_range() handles end > max_mapped_pfn, but not
start > max_mapped_pfn. Check the latter just after grabbing the
lock and bail if true.
Signed-off-by: Razvan Cojocaru
Suggested-by: George Dunlap
---
Changes since V1:
- Added ASSERT()s.
- Wrapped the new condition in an unlikely(
On 04/18/2018 01:55 PM, Roger Pau Monné wrote:
On Wed, Apr 18, 2018 at 01:39:35PM +0300, Oleksandr Andrushchenko wrote:
On 04/18/2018 01:18 PM, Paul Durrant wrote:
-Original Message-
From: Xen-devel [mailto:xen-devel-boun...@lists.xenproject.org] On Behalf
Of Roger Pau Monné
Sent: 18 Ap
>>> On 18.04.18 at 13:39, wrote:
> On Wed, Apr 18, 2018 at 02:53:03AM -0600, Jan Beulich wrote:
> On 06.12.17 at 08:50, wrote:
>>> Each vcpu of hvm guest consumes at least one shadow page. Currently, only
> 256
>>> (for hap case) pages are pre-allocated as shadow memory at beginning. It
> w
>>> On 18.04.18 at 13:20, wrote:
> On Wed, Apr 18, 2018 at 02:38:48AM -0600, Jan Beulich wrote:
> On 06.12.17 at 08:50, wrote:
>>> /*static*/ void ap_start(void)
>>> {
>>> -printf(" - CPU%d ... ", ap_cpuid);
>>> +printf(" - CPU%d ... ", ap_cpuid());
>>> cacheattr_init();
>>>
On 18/04/18 12:39, Chao Gao wrote:
> On Wed, Apr 18, 2018 at 02:53:03AM -0600, Jan Beulich wrote:
> On 06.12.17 at 08:50, wrote:
>>> Each vcpu of hvm guest consumes at least one shadow page. Currently, only
>>> 256
>>> (for hap case) pages are pre-allocated as shadow memory at beginning. It
On Wed, Apr 18, 2018 at 02:53:03AM -0600, Jan Beulich wrote:
On 06.12.17 at 08:50, wrote:
>> Each vcpu of hvm guest consumes at least one shadow page. Currently, only 256
>> (for hap case) pages are pre-allocated as shadow memory at beginning. It
>> would
>> run out if guest has more than 25
On Tue, Apr 17, 2018 at 06:04:37PM +0100, Ian Jackson wrote:
> diff --git a/tools/misc/mktarball b/tools/misc/mktarball
> index 73282b5..42d5430 100755
> --- a/tools/misc/mktarball
> +++ b/tools/misc/mktarball
> @@ -29,7 +29,21 @@ mkdir -p $tdir
>
> git_archive_into $xen_root $tdir/xen-$desc
>
On Wed, Apr 18, 2018 at 02:38:48AM -0600, Jan Beulich wrote:
On 06.12.17 at 08:50, wrote:
>> Intel SDM Extended XAPIC (X2APIC) -> "Initialization by System Software"
>> has the following description:
>>
>> "The ACPI interfaces for the x2APIC are described in Section 5.2, “ACPI
>> System
>>
On 04/18/2018 11:53 AM, Jan Beulich wrote:
On 18.04.18 at 12:23, wrote:
>> That is, sensible input looks like:
>> * start < end
>> * For hostp2ms:
>> - start <= max_mapped_pfn
>> - either end <= max_mapped_pfn, or end == ~0UL
>> (But for altp2ms, start or end > max_mapped_pfn is fine.)
>
>
On 18/04/18 11:45, Mirela Simonovic wrote:
On Tue, Apr 17, 2018 at 4:11 PM, Julien Grall wrote:
On 17/04/18 13:54, Mirela Simonovic wrote:
Hi Julien,
Hi,
On Wed, Apr 11, 2018 at 5:11 PM, Julien Grall
wrote:
Hi,
On 11/04/18 14:19, Mirela Simonovic wrote:
In existing code the p
On Wed, Apr 18, 2018 at 01:39:35PM +0300, Oleksandr Andrushchenko wrote:
> On 04/18/2018 01:18 PM, Paul Durrant wrote:
> > > -Original Message-
> > > From: Xen-devel [mailto:xen-devel-boun...@lists.xenproject.org] On Behalf
> > > Of Roger Pau Monné
> > > Sent: 18 April 2018 11:11
> > > To:
>>> On 18.04.18 at 12:23, wrote:
> That is, sensible input looks like:
> * start < end
> * For hostp2ms:
> - start <= max_mapped_pfn
> - either end <= max_mapped_pfn, or end == ~0UL
> (But for altp2ms, start or end > max_mapped_pfn is fine.)
So I guess that's part of the difficulty I'm having w
>>> On 18.04.18 at 12:25, wrote:
> [FionaLi] : I am sorry. I understood wrongly. The C000 range are
> extensions, which provide some additional feature different from Intel. As
> you suggested, we will enable those features in guest OSes and remove these
> code from patch. Can we support t
On 04/18/2018 01:45 PM, George Dunlap wrote:
> On 04/18/2018 09:20 AM, Razvan Cojocaru wrote:
>> On 04/17/2018 04:53 PM, George Dunlap wrote:
>>> On 04/17/2018 11:50 AM, Razvan Cojocaru wrote:
void p2m_init_altp2m_ept(struct domain *d, unsigned int i)
{
struct p2m_domain *p2m
On Tue, Apr 17, 2018 at 4:11 PM, Julien Grall wrote:
>
>
> On 17/04/18 13:54, Mirela Simonovic wrote:
>>
>> Hi Julien,
>
>
> Hi,
>
>>
>> On Wed, Apr 11, 2018 at 5:11 PM, Julien Grall
>> wrote:
>>>
>>> Hi,
>>>
>>> On 11/04/18 14:19, Mirela Simonovic wrote:
In existing code the pagin
On 04/18/2018 09:20 AM, Razvan Cojocaru wrote:
> On 04/17/2018 04:53 PM, George Dunlap wrote:
>> On 04/17/2018 11:50 AM, Razvan Cojocaru wrote:
>>> void p2m_init_altp2m_ept(struct domain *d, unsigned int i)
>>> {
>>> struct p2m_domain *p2m = d->arch.altp2m_p2m[i];
>>> +struct p2m_domain
This avoids opencoding the functionality (and missing one bit of it), and and
some comments explaining what is going on.
Signed-off-by: Andrew Cooper
---
CC: Jan Beulich
CC: Juergen Gross
This is effectively a bugfix of c/s 710a8eb "x86: suppress BTI mitigations
around S3 suspend/resume" so sh
Jan
Thanks for your reply. Answer the following.
Best wish!
FionaLi
-Original Message-
From: Jan Beulich [mailto:jbeul...@suse.com]
Sent: Tuesday, April 10, 2018 2:35 PM
To: lifang...@126.com; Fiona Li(BJ-RD)
Cc: xen-devel@lists.xenproject.org
Subject: Re: RE: [PATCH] x86/cpu: Support a
On 04/18/2018 01:18 PM, Paul Durrant wrote:
-Original Message-
From: Xen-devel [mailto:xen-devel-boun...@lists.xenproject.org] On Behalf
Of Roger Pau Monné
Sent: 18 April 2018 11:11
To: Oleksandr Andrushchenko
Cc: jgr...@suse.com; Artem Mygaiev ;
Dongwon Kim ; airl...@linux.ie;
oleksandr
Hi Julien,
On Wed, Apr 18, 2018 at 11:48 AM, Julien Grall wrote:
>
>
> On 17/04/18 16:22, Mirela Simonovic wrote:
>>
>> Hi Julien,
>>
>> On Tue, Apr 17, 2018 at 4:11 PM, Julien Grall
>> wrote:
>>>
>>>
>>>
>>> On 17/04/18 13:54, Mirela Simonovic wrote:
Hi Julien,
>>>
>>>
>>>
>>> Hi
On 04/18/2018 01:23 PM, Paul Durrant wrote:
-Original Message-
From: Oleksandr Andrushchenko [mailto:andr2...@gmail.com]
Sent: 18 April 2018 11:21
To: Paul Durrant ; Roger Pau Monne
Cc: jgr...@suse.com; Artem Mygaiev ;
Dongwon Kim ; airl...@linux.ie;
oleksandr_andrushche...@epam.com; lin
Commit 0d31d16 (x86/setup: do not relocate Xen over current Xen image
placement) disallowed src/dst images overlaps when relocating Xen image.
Though it deliberately allowed destination region between __image_base__
and (__image_base__ + XEN_IMG_OFFSET) overlaps with the end of source
image. And he
> -Original Message-
> From: Oleksandr Andrushchenko [mailto:andr2...@gmail.com]
> Sent: 18 April 2018 11:21
> To: Paul Durrant ; Roger Pau Monne
>
> Cc: jgr...@suse.com; Artem Mygaiev ;
> Dongwon Kim ; airl...@linux.ie;
> oleksandr_andrushche...@epam.com; linux-ker...@vger.kernel.org; dri
On 04/18/2018 08:38 AM, Jan Beulich wrote:
On 17.04.18 at 19:16, wrote:
>> --- a/xen/arch/x86/mm/p2m.c
>> +++ b/xen/arch/x86/mm/p2m.c
>> @@ -976,6 +976,13 @@ void p2m_change_type_range(struct domain *d,
>> ASSERT(p2m_is_changeable(ot) && p2m_is_changeable(nt));
>>
>> p2m_lock(p2m)
On 04/18/2018 01:18 PM, Paul Durrant wrote:
-Original Message-
From: Xen-devel [mailto:xen-devel-boun...@lists.xenproject.org] On Behalf
Of Roger Pau Monné
Sent: 18 April 2018 11:11
To: Oleksandr Andrushchenko
Cc: jgr...@suse.com; Artem Mygaiev ;
Dongwon Kim ; airl...@linux.ie;
oleksandr
> -Original Message-
> From: Xen-devel [mailto:xen-devel-boun...@lists.xenproject.org] On Behalf
> Of Roger Pau Monné
> Sent: 18 April 2018 11:11
> To: Oleksandr Andrushchenko
> Cc: jgr...@suse.com; Artem Mygaiev ;
> Dongwon Kim ; airl...@linux.ie;
> oleksandr_andrushche...@epam.com; linux
On Wed, Apr 18, 2018 at 11:01:12AM +0300, Oleksandr Andrushchenko wrote:
> On 04/18/2018 10:35 AM, Roger Pau Monné wrote:
> > On Wed, Apr 18, 2018 at 09:38:39AM +0300, Oleksandr Andrushchenko wrote:
> > > On 04/17/2018 11:57 PM, Dongwon Kim wrote:
> > > > On Tue, Apr 17, 2018 at 09:59:28AM +0200, D
On 18/04/18 11:42, Sergey Dyasli wrote:
> Hi Juergen,
>
> 2 small requests from me below.
>
> On Wed, 2018-04-18 at 10:30 +0200, Juergen Gross wrote:
>> Instead of switching XPTI globally on or off add a per-domain flag for
>> that purpose. This allows to modify the xpti boot parameter to support
On 18/04/18 11:49, Jan Beulich wrote:
On 18.04.18 at 11:42, wrote:
>> On Wed, 2018-04-18 at 10:30 +0200, Juergen Gross wrote:
>> @@ -119,8 +122,9 @@ static void __init print_details(enum ind_thunk thunk)
>> boot_cpu_has(X86_FEATURE_RSB_NATIVE) ? " RSB_NATIVE" : "",
>>
On 17/04/18 16:22, Mirela Simonovic wrote:
Hi Julien,
On Tue, Apr 17, 2018 at 4:11 PM, Julien Grall wrote:
On 17/04/18 13:54, Mirela Simonovic wrote:
Hi Julien,
Hi,
On Wed, Apr 11, 2018 at 5:11 PM, Julien Grall
wrote:
Hi,
On 11/04/18 14:19, Mirela Simonovic wrote:
In existin
>>> On 18.04.18 at 11:42, wrote:
> On Wed, 2018-04-18 at 10:30 +0200, Juergen Gross wrote:
> @@ -119,8 +122,9 @@ static void __init print_details(enum ind_thunk thunk)
> boot_cpu_has(X86_FEATURE_RSB_NATIVE) ? " RSB_NATIVE" : "",
> boot_cpu_has(X86_FEATURE_RSB_VMEXIT)
Hi Juergen,
2 small requests from me below.
On Wed, 2018-04-18 at 10:30 +0200, Juergen Gross wrote:
> Instead of switching XPTI globally on or off add a per-domain flag for
> that purpose. This allows to modify the xpti boot parameter to support
> running dom0 without Meltdown mitigations. Using
On 18/04/18 11:13, Jan Beulich wrote:
On 18.04.18 at 10:30, wrote:
>> Avoid flushing the complete TLB when switching %cr3 for mitigation of
>> Meltdown by using the PCID feature if available.
>>
>> We are using 4 PCID values for a 64 bit pv domain subject to XPTI and
>> 2 values for the non-X
From: David Wang
For the ch->cpumask be cleared by other cpu, cpumask_first() called by
hpet_detach_channel() return nr_cpu_ids. That lead an assertion in
set_channel_irq_affinity() when cpumask_of() check cpu.
Fix this by using a local variable.
Signed-off-by: David Wang
---
xen/arch/x86/hpet
Dear community members,
on Tuesday, we created Xen 4.1q RC1 and will release a new release candidate
every FRIDAY, until we declare a release candidate as the final candidate and
cut the Xen 4.11 release.
We will also hold a Test Day every TUESDAY for the release candidate that was
released the
>>> On 18.04.18 at 10:30, wrote:
> Avoid flushing the complete TLB when switching %cr3 for mitigation of
> Meltdown by using the PCID feature if available.
>
> We are using 4 PCID values for a 64 bit pv domain subject to XPTI and
> 2 values for the non-XPTI case:
>
> - guest active and in kernel
>>> On 06.12.17 at 08:50, wrote:
> Each vcpu of hvm guest consumes at least one shadow page. Currently, only 256
> (for hap case) pages are pre-allocated as shadow memory at beginning. It would
> run out if guest has more than 256 vcpus and guest creation fails. Bump the
> number of shadow pages t
>>> On 06.12.17 at 08:50, wrote:
> --- a/tools/libacpi/build.c
> +++ b/tools/libacpi/build.c
> @@ -30,6 +30,11 @@
>
> #define align16(sz)(((sz) + 15) & ~15)
> #define fixed_strcpy(d, s) strncpy((d), (s), sizeof(d))
> +#define min(X, Y) ({ \
> +co
>>> On 06.12.17 at 08:50, wrote:
> Intel SDM Extended XAPIC (X2APIC) -> "Initialization by System Software"
> has the following description:
>
> "The ACPI interfaces for the x2APIC are described in Section 5.2, “ACPI System
> Description Tables,” of the Advanced Configuration and Power Interface
Instead of having multiple places with more or less identical asm
statements just have one function doing a write to cr3.
As this function should be named write_cr3() rename the current
write_cr3() function to switch_cr3().
Suggested-by: Andrew Copper
Signed-off-by: Juergen Gross
Reviewed-by: J
Today cpu_info->xen_cr3 is either 0 to indicate %cr3 doesn't need to
be switched on entry to Xen, or negative for keeping the value while
indicating not to restore %cr3, or positive in case %cr3 is to be
restored.
Switch to use a flag byte instead of a negative xen_cr3 value in order
to allow %cr3
Instead of switching XPTI globally on or off add a per-domain flag for
that purpose. This allows to modify the xpti boot parameter to support
running dom0 without Meltdown mitigations. Using "xpti=nodom0" as boot
parameter will achieve that.
Move the xpti boot parameter handling to xen/arch/x86/pv
Avoid flushing the complete TLB when switching %cr3 for mitigation of
Meltdown by using the PCID feature if available.
We are using 4 PCID values for a 64 bit pv domain subject to XPTI and
2 values for the non-XPTI case:
- guest active and in kernel mode
- guest active and in user mode
- hypervis
This patch series aims at reducing the overhead of the XPTI Meltdown
mitigation.
Patch 1 had been posted before, the main changes in this patch are due
to addressing Jan's comments on my first version. The main objective of
that patch is to avoid copying the L4 page table each time the guest is
be
pv_guest_cr4_to_real_cr4() is becoming more and more complex. Convert
it from a macro to an ordinary function.
Signed-off-by: Juergen Gross
Reviewed-by: Jan Beulich
---
V6:
- new patch, split off from (old) patch 7 (Andrew Cooper)
---
xen/arch/x86/mm.c| 14 ++
xen/includ
Add some helper macros to access the address and pcid parts of cr3.
Use those helpers where appropriate.
Signed-off-by: Juergen Gross
Reviewed-by: Jan Beulich
---
V6:
- new patch (Andrew Cooper)
---
xen/arch/x86/debug.c| 2 +-
xen/arch/x86/domain_page.c | 2 +-
xen/include/a
If possible use the INVPCID instruction for flushing the TLB instead of
toggling cr4.pge for that purpose.
While at it remove the dependency on cr4.pge being required for mtrr
loading, as this will be required later anyway.
Add a command line option "invpcid" for controlling the use of
INVPCID (d
Instead of flushing the TLB from global pages when switching address
spaces with XPTI being active just disable global pages via %cr4
completely when a domain subject to XPTI is active. This avoids the
need for extra TLB flushes as loading %cr3 will remove all TLB
entries.
In order to avoid states
For mitigation of Meltdown the current L4 page table is copied to the
cpu local root page table each time a 64 bit pv guest is entered.
Copying can be avoided in cases where the guest L4 page table hasn't
been modified while running the hypervisor, e.g. when handling
interrupts or any hypercall no
On 04/17/2018 04:53 PM, George Dunlap wrote:
> On 04/17/2018 11:50 AM, Razvan Cojocaru wrote:
>> void p2m_init_altp2m_ept(struct domain *d, unsigned int i)
>> {
>> struct p2m_domain *p2m = d->arch.altp2m_p2m[i];
>> +struct p2m_domain *hostp2m = p2m_get_hostp2m(d);
>> struct ept_data
>>> On 06.12.17 at 08:50, wrote:
> One 4K-byte page at most contains 128 'ioreq_t'. In order to remove the vcpu
> number constraint imposed by one IOREQ page, bump the number of IOREQ page to
> 4 pages. With this patch, multiple pages can be used as IOREQ page.
In case I didn't say so before - I'
flight 74632 distros-debian-squeeze real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/74632/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-i386-squeeze-netboot-pygrub 10 debian-di-install fail like
74577
test-amd64-i386-i386
I wonder why I am starting to get CCed on Xen patches all of a sudden.
I happened to run into Jürgen at a conference only last weekend, but
I still don't know anything whatsoever about Xen or how it works.
If get_maintainer.pl has started to return my name on this stuff I
really want to know why
On 4/17/18 6:02 PM, Dario Faggioli wrote:
On Tue, 2018-04-17 at 15:08 +0100, Andrew Cooper wrote:
On 17/04/18 15:02, Juergen Gross wrote:
Is this something we should be aware of in Xen, too?
If we had something close to a working topology representation,
probably.
True, as far as letting t
On 04/18/2018 10:35 AM, Roger Pau Monné wrote:
On Wed, Apr 18, 2018 at 09:38:39AM +0300, Oleksandr Andrushchenko wrote:
On 04/17/2018 11:57 PM, Dongwon Kim wrote:
On Tue, Apr 17, 2018 at 09:59:28AM +0200, Daniel Vetter wrote:
On Mon, Apr 16, 2018 at 12:29:05PM -0700, Dongwon Kim wrote:
3.2 Ba
On 04/18/2018 10:48 AM, Razvan Cojocaru wrote:
> On 04/18/2018 10:38 AM, Jan Beulich wrote:
> On 17.04.18 at 19:16, wrote:
>>> --- a/xen/arch/x86/mm/p2m.c
>>> +++ b/xen/arch/x86/mm/p2m.c
>>> @@ -976,6 +976,13 @@ void p2m_change_type_range(struct domain *d,
>>> ASSERT(p2m_is_changeable(o
On 04/18/2018 10:38 AM, Jan Beulich wrote:
On 17.04.18 at 19:16, wrote:
>> --- a/xen/arch/x86/mm/p2m.c
>> +++ b/xen/arch/x86/mm/p2m.c
>> @@ -976,6 +976,13 @@ void p2m_change_type_range(struct domain *d,
>> ASSERT(p2m_is_changeable(ot) && p2m_is_changeable(nt));
>>
>> p2m_lock(p2m)
>>> On 17.04.18 at 19:16, wrote:
> --- a/xen/arch/x86/mm/p2m.c
> +++ b/xen/arch/x86/mm/p2m.c
> @@ -976,6 +976,13 @@ void p2m_change_type_range(struct domain *d,
> ASSERT(p2m_is_changeable(ot) && p2m_is_changeable(nt));
>
> p2m_lock(p2m);
> +
> +if ( start > p2m->max_mapped_pfn )
>
On Wed, Apr 18, 2018 at 09:38:39AM +0300, Oleksandr Andrushchenko wrote:
> On 04/17/2018 11:57 PM, Dongwon Kim wrote:
> > On Tue, Apr 17, 2018 at 09:59:28AM +0200, Daniel Vetter wrote:
> > > On Mon, Apr 16, 2018 at 12:29:05PM -0700, Dongwon Kim wrote:
> 3.2 Backend exports dma-buf to xen-front
>
>
On 04/17/2018 12:08 PM, Oleksandr Andrushchenko wrote:
On 04/17/2018 12:04 PM, Daniel Vetter wrote:
On Tue, Apr 17, 2018 at 10:40:12AM +0300, Oleksandr Andrushchenko wrote:
From: Oleksandr Andrushchenko
Even if xen-front allocates its buffers from contiguous memory
those are still not contigu
95 matches
Mail list logo
