On Wed, 2017-05-31 at 08:44 +0100, Andrew Cooper wrote:
> On 31/05/2017 08:09, Han, Huaitong wrote:
> > On Fri, 2017-05-26 at 18:03 +0100, Andrew Cooper wrote:
> >> This reverts commit c41e0266dd59ab50b7a153157e9bd2a3ad114b53.
> >>
> >> When determining Acce
On Fri, 2017-05-26 at 18:03 +0100, Andrew Cooper wrote:
> This reverts commit c41e0266dd59ab50b7a153157e9bd2a3ad114b53.
>
> When determining Access Rights, Protection Keys only take effect when CR4.PKE
> it set, and 4-level paging is active. All other circumstances (notibly, 32bit
> PAE paging) s
Y, I think it works well, and more better.
to Luwei: you can test if the problem is solved.
On Wed, 2016-06-01 at 10:03 +0100, Andrew Cooper wrote:
> On 01/06/16 05:58, Luwei Kang wrote:
> > CPUID.0XD.0X0.EAX is from machine value for dom0, and dom0 kernel will
> > xsetbv
> > with xfeatures_mas
On Wed, 2016-06-01 at 02:49 -0600, Jan Beulich wrote:
> >>> On 01.06.16 at 07:54, wrote:
> > On Wed, 2016-06-01 at 12:58 +0800, Luwei Kang wrote:
> >> CPUID.0XD.0X0.EAX is from machine value for dom0, and dom0 kernel will
> >> xsetbv
> >> with xfeatures_mask that is from CPUID.0XD.0X0.EAX, but ha
On Wed, 2016-06-01 at 12:58 +0800, Luwei Kang wrote:
> CPUID.0XD.0X0.EAX is from machine value for dom0, and dom0 kernel will xsetbv
> with xfeatures_mask that is from CPUID.0XD.0X0.EAX, but handle_xsetbv has
> ingored XSTATE_PKRU with hardware protection fault emulation, so dom0 kernel
> will cras
On Mon, 2016-02-29 at 11:17 +, Wei Liu wrote:
>
> * Memory protection-key support
> - Huaitong Han
The patches have been merged into staging branch.
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
On Thu, 2016-02-04 at 13:20 +0800, Huaitong Han wrote:
> On Thu, 2016-02-04 at 04:56 +, Tian, Kevin wrote:
> > > From: Huaitong Han
> > > Sent: Wednesday, February 03, 2016 10:12 PM
> > >
> > > The PKRU register (protection key rights for user pages) is a 32
> > > -bit register
> > > with the
On Thu, 2016-02-04 at 04:56 +, Tian, Kevin wrote:
> > From: Huaitong Han
> > Sent: Wednesday, February 03, 2016 10:12 PM
> >
> > The PKRU register (protection key rights for user pages) is a 32
> > -bit register
> > with the following format: for each i (0 ≤ i ≤ 15), PKRU[2i] is the
> > access
On Wed, 2016-02-03 at 08:19 -0700, Jan Beulich wrote:
> > > > On 03.02.16 at 15:12, wrote:
> > This patch disables pkeys for guest in non-paging mode, However XEN
> > always
> > uses
> > paging mode to emulate guest non-paging mode, To emulate this
> > behavior, pkeys
> > needs to be manually dis
On Wed, 2016-02-03 at 02:43 -0700, Jan Beulich wrote:
> > > > On 02.02.16 at 08:35, wrote:
> > Protection keys define a new 4-bit protection key field(PKEY) in
> > bits 62:59
> > of
> > leaf entries of the page tables.
> >
> > PKRU register defines 32 bits, there are 16 domains and 2 attribute
>
On Wed, 2016-02-03 at 02:50 -0700, Jan Beulich wrote:
> > > > On 02.02.16 at 08:35, wrote:
> > This patch adds pkeys support for cpuid handing.
> >
> > Pkeys hardware support is CPUID.7.0.ECX[3]:PKU. software support is
> > CPUID.7.0.ECX[4]:OSPKE and it reflects the support setting of
> > CR4.PKE
On Mon, 2016-02-01 at 10:45 +, Wei Liu wrote:
> This email only tracks big items for xen.git tree. Please reply for
> items you
> woulk like to see in 4.7 so that people have an idea what is going on
> and
> prioritise accordingly.
>
> You're welcome to provide description and use cases of the
On Wed, 2016-01-27 at 09:34 +, Tim Deegan wrote:
> Hi,
>
> At 07:22 + on 27 Jan (1453879344), Han, Huaitong wrote:
> > On Tue, 2016-01-26 at 14:30 +, Tim Deegan wrote:
> > > This seems OK. But can you please:
> > > - Add this new adjustment once
On Tue, 2016-01-26 at 14:30 +, Tim Deegan wrote:
> Hi,
>
> At 15:30 +0800 on 19 Jan (1453217458), Huaitong Han wrote:
> > At the moment, the pfec argument to gva_to_gfn has two functions:
> >
> > * To inform guest_walk what kind of access is happenind
> >
> > * As a value to pass back into t
On Mon, 2016-01-25 at 08:46 -0700, Jan Beulich wrote:
> > > > On 19.01.16 at 08:30, wrote:
>
>
> > +write_cr4(cr4 | X86_CR4_PKE);
> > +asm volatile (".byte 0x0f,0x01,0xee"
> > +: "=a" (pkru) : "c" (0) : "dx");
> > +write_cr4(cr4);
>
> I think you will want to abstract out t
On Mon, 2016-01-25 at 08:25 -0700, Jan Beulich wrote:
> > > > On 19.01.16 at 08:30, wrote:
> > Changes in v6:
> > *2 patches merged are not included.
> > *Don't write XSTATE_PKRU to PV's xcr0.
> > *Use "if()" instead of "?:" in cpuid handling patch.
> > *Update read_pkru function.
> > *Use value 4
On Tue, 2015-12-22 at 01:30 -0700, Jan Beulich wrote:
> > > > On 22.12.15 at 03:54, wrote:
> > On Mon, 2015-12-21 at 08:07 -0700, Jan Beulich wrote:
> > > > > > On 21.12.15 at 08:21, wrote:
> > > > @@ -4600,6 +4600,14 @@ void hvm_cpuid(unsigned int input,
> > > > unsigned
> > > > int *eax, unsign
On Mon, 2015-12-21 at 08:32 -0700, Jan Beulich wrote:
> > > > On 21.12.15 at 08:21, wrote:
> > --- a/xen/arch/x86/mm/guest_walk.c
> > +++ b/xen/arch/x86/mm/guest_walk.c
> > @@ -90,6 +90,55 @@ static uint32_t set_ad_bits(void *guest_p, void
> > *walk_p, int set_dirty)
> > return 0;
> > }
> >
On Mon, 2015-12-21 at 08:07 -0700, Jan Beulich wrote:
> > > > On 21.12.15 at 08:21, wrote:
> > @@ -4600,6 +4600,14 @@ void hvm_cpuid(unsigned int input, unsigned
> > int *eax, unsigned int *ebx,
> > /* Don't expose INVPCID to non-hap hvm. */
> > if ( (count == 0) && !hap_enabled(
On Wed, 2015-12-16 at 15:36 +, George Dunlap wrote:
> [Adding Tim, the previous mm maintainer]
>
> On 11/12/15 09:16, Wu, Feng wrote:
> > > > +{
> > > > +void *xsave_addr;
> > > > +unsigned int pkru = 0;
> > > > +bool_t pkru_ad, pkru_wd;
> > > > +
> > > > +bool_t uf = !!(pfec &
On Wed, 2015-12-16 at 02:12 -0700, Jan Beulich wrote:
> > > > On 16.12.15 at 10:03, wrote:
> > On Wed, 2015-12-16 at 01:32 -0700, Jan Beulich wrote:
> > > > > > On 16.12.15 at 09:16, wrote:
> > > > On Tue, 2015-12-15 at 02:02 -0700, Jan Beulich wrote:
> > > > > Well, I wouldn't want you to introd
On Wed, 2015-12-16 at 01:32 -0700, Jan Beulich wrote:
> > > > On 16.12.15 at 09:16, wrote:
> > On Tue, 2015-12-15 at 02:02 -0700, Jan Beulich wrote:
> > > Well, I wouldn't want you to introduce a brand new function, but
> > > instead just factor out the necessary piece from xsave() (making
> > > t
On Tue, 2015-12-15 at 02:02 -0700, Jan Beulich wrote:
> > > > On 15.12.15 at 09:14, wrote:
> > On Fri, 2015-12-11 at 02:26 -0700, Jan Beulich wrote:
> > > > > > On 10.12.15 at 19:19, wrote:
> > > > On 07/12/15 09:16, Huaitong Han wrote:
> > > > > +if ( likely(!pte_pkeys) )
> > > > > +
On Fri, 2015-12-11 at 02:26 -0700, Jan Beulich wrote:
> > > > On 10.12.15 at 19:19, wrote:
> > On 07/12/15 09:16, Huaitong Han wrote:
> > > +if ( likely(!pte_pkeys) )
> > > +return 0;
> > > +
> > > +/* Update vcpu xsave area */
> > > +fpu_xsave(vcpu);
> >
> > Is there a reason
On Thu, 2015-12-10 at 18:19 +, George Dunlap wrote:
> On 07/12/15 09:16, Huaitong Han wrote:
> > +{
> > +void *xsave_addr;
> > +unsigned int pkru = 0;
> > +bool_t pkru_ad, pkru_wd;
> > +
> > +bool_t uf = !!(pfec & PFEC_user_mode);
> > +bool_t wf = !!(pfec & PFEC_write_access
On Thu, 2015-12-10 at 18:59 +, Andrew Cooper wrote:
> On 07/12/15 09:16, Huaitong Han wrote:
> > +
> > +/* PKRU dom0 is always zero */
> > +if ( likely(!pte_pkeys) )
> > +return 0;
>
> This is not an architectural restriction (as far as I can tell). Xen
> must never make assum
On Wed, 2015-12-02 at 04:35 -0700, Jan Beulich wrote:
> >>> On 27.11.15 at 10:52, wrote:
> > --- a/xen/arch/x86/hvm/hvm.c
> > +++ b/xen/arch/x86/hvm/hvm.c
> > @@ -4304,7 +4304,8 @@ static enum hvm_copy_result
> > __hvm_clear(paddr_t addr, int size)
> > p2m_type_t p2mt;
> > char *p;
> >
On Wed, 2015-12-02 at 04:31 -0700, Jan Beulich wrote:
> > > > On 02.12.15 at 08:20, wrote:
> > > Does this even compile? There is already
> > >
> > > static void *get_xsave_addr(void *xsave, unsigned int
> > > xfeature_idx)
> > >
> > > higher in the same file.
> > >
> > > That function should
On Wed, 2015-12-02 at 04:06 -0700, Jan Beulich wrote:
> > > )
> > > +*ecx &= ~cpufeat_mask(X86_FEATURE_PKU);
> > > +
> > > +if ( (count == 0) && cpu_has_pku )
> > > +*ecx |= (v->arch.hvm_vcpu.guest_cr[4] & X86_CR4_PKE)
> > > ?
> > > + cpufeat_mas
On Tue, 2015-12-01 at 20:30 +, Andrew Cooper wrote:
> > +#include
>
> I can see why you need xstate.h, but I why do you need i387.h ?
Use vcpu_save_fpu functions.
> > +
> > if ( pse2M )
> > {
> > /* Special case: this guest VA is in a PSE superpage, so
> > there's
> > @@ -
> Does this even compile? There is already
>
> static void *get_xsave_addr(void *xsave, unsigned int xfeature_idx)
>
> higher in the same file.
>
> That function should be augmented to take a struct xsave_struct
> *xsave,
> look at whether the representation is compressed or not, and use the
>
On Fri, 2015-11-27 at 12:59 +, Andrew Cooper wrote:
> Just for my own understand, do you have a sample use-case for
> protection
> keys?
>
> As everything can WRPKRU, I cant see how it would actually be useful.
> Clearly there is a usecase or you (Intel) wouldn't have gone to the
> effort of p
On Mon, 2015-11-09 at 16:15 +, Wei Liu wrote:
> = Timeline =
>
> We now adopt a fixed cut-off date scheme. We will release twice a
> year. The upcoming 4.7 timeline are as followed:
>
> * Last posting date: March 18, 2016
> * Hard code freeze: April 1, 2016
> * RC1: TBD
> * Release: July 1, 2
On Wed, 2015-07-01 at 08:50 +0100, Andrew Cooper wrote:
> On 01/07/2015 03:49, Han, Huaitong wrote:
> > Hi, all,
> >
> > When I create a L1 guest with nestedhvm=1, and create a L2 guest in L1
> > guest, then migrate L1 guest, but the operation fails, and I find the
&
Hi, all,
When I create a L1 guest with nestedhvm=1, and create a L2 guest in L1
guest, then migrate L1 guest, but the operation fails, and I find the
bugfix requires a lot of work.
Does Xen support the operation? I guess the nestedvm migration feature
is not at all implemented.
Thanks a lot
Hua
On Thu, 2015-05-21 at 07:50 +0100, Jan Beulich wrote:
> >>> On 21.05.15 at 08:40, wrote:
> > @@ -329,7 +340,7 @@ static uint64_t acpi_pm_ticks_elapsed(uint64_t t1,
> > uint64_t t2)
> > }
> >
> > uint64_t (*__read_mostly cpuidle_get_tick)(void) = get_acpi_pm_tick;
> > -static uint64_t (*__read
On Wed, 2015-05-20 at 02:42 +, Han, Huaitong wrote:
> On Tue, 2015-05-19 at 10:01 +0100, Jan Beulich wrote:
> > >>> On 14.05.15 at 07:23, wrote:
> > > @@ -1172,7 +1196,10 @@ int pmstat_get_cx_stat(uint32_t cpuid, struct
> > > pm_cx_stat *stat)
> > &
On Tue, 2015-05-19 at 10:01 +0100, Jan Beulich wrote:
> >>> On 14.05.15 at 07:23, wrote:
> > @@ -1172,7 +1196,10 @@ int pmstat_get_cx_stat(uint32_t cpuid, struct
> > pm_cx_stat *stat)
> > {
> > struct acpi_processor_power *power = processor_powers[cpuid];
> > uint64_t idle_usage = 0, i
On Mon, 2015-05-11 at 12:10 +0100, Jan Beulich wrote:
> >>> On 11.05.15 at 11:34, wrote:
> > ---
> > ChangeLog:
> > V4:
> > delete pointless initializers and hard tabs.
>
> Thanks, but ...
>
> > V3:
> > 1.Don't use tick_to_ns inside lock in print_acpi_power.
>
> ... note that this also was not
Get it, thanks
On Mon, 2015-05-11 at 09:00 +0100, Jan Beulich wrote:
> >>> On 11.05.15 at 08:50, wrote:
> > On Fri, 2015-05-08 at 11:11 +0100, Jan Beulich wrote:
> >> >>> On 08.05.15 at 11:40, wrote:
> >> > All comments has been addressed, just changelog is written partly.
> >>
> >> Certainly n
On Fri, 2015-05-08 at 11:11 +0100, Jan Beulich wrote:
> >>> On 08.05.15 at 11:40, wrote:
> > All comments has been addressed, just changelog is written partly.
>
> Certainly not. There are still hard tabs in the patch, and there was
> still a pointless initializer that I had pointed out before.
All comments has been addressed, just changelog is written partly.
On Fri, 2015-05-08 at 09:35 +0100, Jan Beulich wrote:
> >>> On 08.05.15 at 10:11, wrote:
> > When checking the ACPI funciton of C-status, after 100 seconds sleep,
> > the sampling value of C0 status from the xenpm tool decreases.
All accepted.
-Original Message-
From: Jan Beulich [mailto:jbeul...@suse.com]
Sent: Monday, May 4, 2015 10:01 PM
To: Han, Huaitong
Cc: xen-devel@lists.xen.org
Subject: Re: [V2] x86/cpuidle: get accurate C0 value with xenpm tool
>>> On 04.05.15 at 15:23, wrote:
> On Mon, 2
On Mon, 2015-05-04 at 09:33 +0100, Jan Beulich wrote:
> >>> On 04.05.15 at 08:27, wrote:
> > When checking the ACPI funciton of C-status, after 100 seconds sleep,
> > the sampling value of C0 status from the xenpm tool decreases.
> > Because C0=NOW()-C1-C2-C3-C4, when NOW() value is during idle ti
-Original Message-
From: Jan Beulich [mailto:jbeul...@suse.com]
Sent: Thursday, April 16, 2015 4:49 PM
To: Han, Huaitong
Cc: xen-devel@lists.xen.org
Subject: Re: [v1] x86/cpuidle: get accurate C0 value with xenpm tool
>>> On 16.04.15 at 08:03, wrote:
> When checking the A
45 matches
Mail list logo
