Re: [Xen-devel] [PATCH v3 for-next 4/4] xen: Convert __page_to_mfn and __mfn_to_page to use typesafe MFN

most of the callers are now switched to _mfn(domain_page_to_mfn(...)). > > Signed-off-by: Julien Grall <julien.gr...@linaro.org> Acked-by: Tim Deegan <t...@xen.org> ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH] mm/shadow: fix declaration of fetch_type_names

ger@citrix.com> Acked-by: Tim Deegan <t...@xen.org> ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH for 4.10 0/3] XSA-243 followup

ve PV l4 table setup code" and "x86/mm: factor out > pv_arch_init_memory" > x86/mm: Consolidate all Xen L2 slot writing into > init_xen_pae_l2_slots() > x86/mm: Consolidate all Xen L4 slot writing into init_xen_l4_slots() Acked-by: Tim Deegan <t...@xen.org>

Re: [Xen-devel] [PATCH 0/7] xen: Convert __page_to_mfn and __mfn_to_page to use typesafe MFN

to make __page_to_mfn and __mfn_to_page using typesafe > MFN. > > The first 6 patches will convert of the code to use typesafe MFN, easing > the tree-wide conversion in patch 7. x86 shadow code changes Acked-by: Tim Deegan <t...@xen.org> _

Re: [Xen-devel] [PATCH] x86: Make use of pagetable_get_mfn() where appropriate

At 19:36 +0100 on 28 Sep (1506627400), Andrew Cooper wrote: > ... instead of the opencoded _mfn(pagetable_get_pfn(...)) construct. > > Fix two overly long lines; no functional change. > > Signed-off-by: Andrew Cooper <andrew.coop...@citrix.com> Acked-by: Tim

Re: [Xen-devel] [PATCH v5 17/23] x86/mm: export base_disallow_mask and l1 mask in asm-x86/mm.h

At 07:52 -0600 on 22 Sep (1506066733), Jan Beulich wrote: > >>> On 14.09.17 at 14:58, wrote: > > The l1 mask needs to stay in x86/mm.c while l{2,3,4} masks are only > > needed by PV code. Both x86 common mm code and PV mm code use > > base_disallow_mask and l1 maks. > > > >

Re: [Xen-devel] [PATCH v2 0/4] Various XSA followups

For the shadow pagetable changes in patches 1 and 2: Acked-by: Tim Deegan <t...@xen.org> ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH] x86/mm: Consolidate all Xen L4 slot writing into init_xen_l4_slots()

ROOT_PAGETABLE_XEN_SLOTS); > + > +memcpy([l4_table_offset(XEN_VIRT_START)], > + _pg_table[l4_table_offset(XEN_VIRT_START)], > + (ROOT_PAGETABLE_FIRST_XEN_SLOT + slots - > +l4_table_offset(XEN_VIRT_START)) * sizeof(*l4t)); Doe

Re: [Xen-devel] [PATCH] x86/shadow: Clarify the safety of guest-linear mapping construction

gned-off-by: Andrew Cooper <andrew.coop...@citrix.com> Acked-by: Tim Deegan <t...@xen.org> ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH 2/2] x86/mm: Use mfn_t for make_cr3()

At 13:19 +0100 on 30 Aug (1504099173), Andrew Cooper wrote: > No functional change. > > Signed-off-by: Andrew Cooper <andrew.coop...@citrix.com> Acked-by: Tim Deegan <t...@xen.org> ___ Xen-devel mailing list Xen-deve

Re: [Xen-devel] [PATCH 1/5] x86/pv: Switch {fill, zap}_ro_mpt() to using mfn_t

At 12:19 +0100 on 29 Aug (1504009152), Andrew Cooper wrote: > And update all affected callers. Fix the fill_ro_mpt() prototype to be bool > like its implementation. > > Signed-off-by: Andrew Cooper <andrew.coop...@citrix.com> Acked-by: Tim De

Re: [Xen-devel] [PATCH 3/3] x86/mm: Introduce and use l?e_{get, from}_mfn()

At 14:14 +0100 on 24 Aug (1503584097), Andrew Cooper wrote: > This avoids the explicit boxing/unboxing of mfn_t in relevant codepaths. > > Signed-off-by: Andrew Cooper <andrew.coop...@citrix.com> Acked-by: Tim Deegan <t...@xen.org>

Re: [Xen-devel] [PATCH RFC 2/2] x86/mm: PG_translate implies PG_refcounts

At 11:05 +0100 on 24 Aug (1503572736), Wei Liu wrote: > On Thu, Aug 24, 2017 at 11:02:33AM +0100, Tim Deegan wrote: > > At 16:58 +0100 on 23 Aug (1503507504), Wei Liu wrote: > > > After 404595352 ("x86/paging: Enforce PG_external == PG_translate == > > &

Re: [Xen-devel] [PATCH RFC 1/2] xen: remove CONFIG_PAGING_ASSISTANCE

; > Remove it and simplify xen/paging.h. > > > > Signed-off-by: Wei Liu <wei.l...@citrix.com> > > This is something I certainly would want Tim to see (and perhaps > approve). Thanks. I see and approve. :) Acked-by: Tim Deegan <t...@xen.org> _

Re: [Xen-devel] [PATCH RFC 2/2] x86/mm: PG_translate implies PG_refcounts

_refcounts > are replaced by calls to paging_mode_translate. Would it be a good idea to merge all three and have only PG_external? > Signed-off-by: Wei Liu <wei.l...@citrix.com> Acked-by: Tim Deegan <t...@xen.org> with one adjustment: > /* common paging mode bits */ >

Re: [Xen-devel] [PATCH v3 0/6] xen: RCU: x86/ARM: Add support of rcu_idle_{enter, exit}

race > period, and we simplify the code (a.k.a. 'win-win' :-D). Thanks! Reviewed-by: Tim Deegan <t...@xen.org> ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH v2 2/4] xen/x86: Drop unnecessary barriers

At 09:04 -0600 on 18 Aug (1503047077), Jan Beulich wrote: > >>> On 18.08.17 at 16:47, wrote: > > At 01:48 -0600 on 17 Aug (1502934495), Jan Beulich wrote: > >> >>> On 16.08.17 at 18:47, wrote: > >> > On 16/08/17 16:23, Jan Beulich wrote: > >> > On

Re: [Xen-devel] [PATCH v2 2/4] xen/x86: Drop unnecessary barriers

At 15:47 +0100 on 18 Aug (1503071247), Tim Deegan wrote: > At 01:48 -0600 on 17 Aug (1502934495), Jan Beulich wrote: > > >>> On 16.08.17 at 18:47, <andrew.coop...@citrix.com> wrote: > > > atomic_read() is not free to be reordered by the compiler. It is an asm >

Re: [Xen-devel] [PATCH v2 2/4] xen/x86: Drop unnecessary barriers

At 01:48 -0600 on 17 Aug (1502934495), Jan Beulich wrote: > >>> On 16.08.17 at 18:47, wrote: > > On 16/08/17 16:23, Jan Beulich wrote: > > On 16.08.17 at 13:22, wrote: > >>> --- a/xen/arch/x86/mm/shadow/multi.c > >>> +++

[Xen-devel] [PATCH] xen/x86/shadow: adjust barriers around gtable_dirty_version.

-by: Tim Deegan <t...@xen.org> --- xen/arch/x86/mm/shadow/multi.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/xen/arch/x86/mm/shadow/multi.c b/xen/arch/x86/mm/shadow/multi.c index c9c2252..f8a8928 100644 --- a/xen/arch/x86/mm/shadow/multi.c +++ b/xen/arch/x86/mm/

Re: [Xen-devel] [PATCH v2 2/4] xen/x86: Drop unnecessary barriers

At 14:55 +0100 on 18 Aug (1503068128), Tim Deegan wrote: > At 12:22 +0100 on 16 Aug (1502886128), Andrew Cooper wrote: > > diff --git a/xen/arch/x86/mm/shadow/multi.c b/xen/arch/x86/mm/shadow/multi.c > > index c9c2252..1e3dfaf 100644 > > --- a/xen/arch/x86/mm/shadow/multi.c &

Re: [Xen-devel] [PATCH v2 2/4] xen/x86: Drop unnecessary barriers

At 12:22 +0100 on 16 Aug (1502886128), Andrew Cooper wrote: > diff --git a/xen/arch/x86/mm/shadow/multi.c b/xen/arch/x86/mm/shadow/multi.c > index c9c2252..1e3dfaf 100644 > --- a/xen/arch/x86/mm/shadow/multi.c > +++ b/xen/arch/x86/mm/shadow/multi.c > @@ -3112,7 +3112,6 @@ static int

Re: [Xen-devel] [PATCH v2 1/4] x86/mcheck: Minor cleanup to amd_nonfatal

At 12:22 +0100 on 16 Aug (1502886127), Andrew Cooper wrote: > * Drop trailing whitespace. > * Move amd_nonfatal_mcheck_init() into .init.text and drop a trailing > return. > * Drop unnecessary wmb()'s. Because of Xen's implementation, they are only > compiler barriers anyway, and each

Re: [Xen-devel] [PATCH v2 3/6] xen: RCU/x86/ARM: discount CPUs that were idle when grace period started.

Hi, This looks good to me. I have one question: At 18:45 +0200 on 16 Aug (1502909149), Dario Faggioli wrote: > @@ -474,7 +484,41 @@ static struct notifier_block cpu_nfb = { > void __init rcu_init(void) > { > void *cpu = (void *)(long)smp_processor_id(); > + > +

Re: [Xen-devel] [PATCH 3/5] xen: RCU/x86/ARM: discount CPUs that were idle when grace period started.

At 18:21 +0200 on 14 Aug (1502734919), Dario Faggioli wrote: > On Mon, 2017-08-14 at 14:54 +0100, Tim Deegan wrote: > > At 15:24 +0200 on 14 Aug (1502724279), Dario Faggioli wrote: > > > About the former... I'm not sure which check of rcp->cur you're > > > refe

Re: [Xen-devel] [PATCH 3/5] xen: RCU/x86/ARM: discount CPUs that were idle when grace period started.

Hi, At 15:24 +0200 on 14 Aug (1502724279), Dario Faggioli wrote: > On Mon, 2017-08-14 at 11:39 +0100, Tim Deegan wrote: > > At 11:19 +0200 on 14 Aug (1502709563), Dario Faggioli wrote: > > > 3) CPU2 is not in idle_cpumask, and so it will not be in the > > > sampled >

Re: [Xen-devel] [PATCH 3/5] xen: RCU/x86/ARM: discount CPUs that were idle when grace period started.

Hi, At 11:19 +0200 on 14 Aug (1502709563), Dario Faggioli wrote: > Basically, for the race to occur (in [3]), it is necessary that [2] > (CPU1 doing rcp->cur++) happens after [1] (last call to rcu_pending() > of CPU2, before clearing the mask and going idle). In fact, it that is > not the case,

Re: [Xen-devel] [PATCH 3/5] xen: RCU/x86/ARM: discount CPUs that were idle when grace period started.

Hi, At 10:01 +0200 on 27 Jul (1501149684), Dario Faggioli wrote: > In Xen, that is impossible, and that's particularly problematic > when system is idle (or lightly loaded) systems, as CPUs that > are idle may never have the chance to tell RCU about their > quiescence, and grace periods could

Re: [Xen-devel] [PATCH] x86/pagewalk: Remove opt_allow_superpage check from guest_can_use_l2_superpages()

r should accept them. Reviewed-by: Tim Deegan <t...@xen.org> > guest_can_use_l2_superpages() checking opt_allow_superpage is a piece of PV > guest policy enforcement, rather than its intended purpose of meaning "would > hardware tolerate finding an L2 superpage with these

Re: [Xen-devel] [PATCH v2 4/4] x86/shadow: Switch to using bool

At 16:40 +0100 on 30 Jun (1498840853), Andrew Cooper wrote: > * sh_pin() has boolean properties, so switch its return type. > * sh_remove_shadows() uses ints everywhere other than its stub. > > Signed-off-by: Andrew Cooper <andrew.coop...@citrix.com> Reviewed-by: Tim De

Re: [Xen-devel] [PATCH 4/4] x86/shadow: Switch to using bool

Hi, At 12:16 +0100 on 28 Jun (1498652182), Andrew Cooper wrote: > sh_pin() has boolean properties, so switch its return type. > > Signed-off-by: Andrew Cooper Good idea, thanks. > -static bool_t > +static bool > sh_write_guest_entry(struct vcpu *v, intpte_t *p,

Re: [Xen-devel] [PATCH 2/2] xen/mm: Introduce {G, M}FN_INVALID_INITIALIZER

common > value to initialize a variable and directly passed as an argument. > > Introduce 2 news define {G,M}FN_INVALID_INITIALIZER to be used for > initializing a variable. > > [1] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64856 > > Signed-off-by: Julien Grall <juli

Re: [Xen-devel] [PATCH v2 01/16] xen/mm: Don't use _{g, m}fn for defining INVALID_{G, M}FN

At 03:18 -0600 on 23 Jun (1498187924), Jan Beulich wrote: > >>> On 23.06.17 at 10:55, wrote: > > > > > On 23/06/17 09:30, Jan Beulich wrote: > > On 22.06.17 at 20:31, wrote: > >>> Hi, > >>> > >>> On 20/06/17 11:32, Jan Beulich wrote: > >>> On

Re: [Xen-devel] [PATCH v2 01/16] xen/mm: Don't use _{g, m}fn for defining INVALID_{G, M}FN

At 09:58 +0100 on 23 Jun (1498211910), Tim Deegan wrote: > At 09:41 +0100 on 23 Jun (1498210893), Julien Grall wrote: > > On 23/06/17 09:30, Jan Beulich wrote: > > > > > >> typedef struct > > >> { > > >> unsigned long i; >

Re: [Xen-devel] [PATCH v2 01/16] xen/mm: Don't use _{g, m}fn for defining INVALID_{G, M}FN

At 09:41 +0100 on 23 Jun (1498210893), Julien Grall wrote: > Hi Jan, > > On 23/06/17 09:30, Jan Beulich wrote: > On 22.06.17 at 20:31, wrote: > >> Hi, > >> > >> On 20/06/17 11:32, Jan Beulich wrote: > >> On 20.06.17 at 12:06, wrote: > At 03:36

Re: [Xen-devel] [PATCH 3/6] x86/shadow: Use ERR_PTR infrastructure for sh_emulate_map_dest()

dr); Using "return ~PTR_ERR(addr)" when the usual idiom is "return -PTR_ERR(foo)" is a bit subtle. Still, the code seems to be correct, so if people prefer it, Acked-by: Tim Deegan <t...@xen.org> Cheers, Tim. ___ Xen-devel mai

Re: [Xen-devel] [PATCH 2/6] x86/shadow: Fixes to hvm_emulate_insn_fetch()

y mistake. Tim. > Signed-off-by: Andrew Cooper <andrew.coop...@citrix.com> > --- > CC: Tim Deegan <t...@xen.org> > CC: Jan Beulich <jbeul...@suse.com> > --- > xen/arch/x86/mm/shadow/common.c | 10 +++--- > 1 file changed, 7 insertions(+), 3 deletions(-) >

Re: [Xen-devel] [PATCH v2 01/16] xen/mm: Don't use _{g, m}fn for defining INVALID_{G, M}FN

At 03:36 -0600 on 20 Jun (1497929778), Jan Beulich wrote: > >>> On 20.06.17 at 11:14, wrote: > > At 01:32 -0600 on 20 Jun (1497922345), Jan Beulich wrote: > >> >>> On 19.06.17 at 18:57, wrote: > >> > --- a/xen/include/xen/mm.h > >> > +++ b/xen/include/xen/mm.h

Re: [Xen-devel] [PATCH v2 01/16] xen/mm: Don't use _{g, m}fn for defining INVALID_{G, M}FN

At 01:32 -0600 on 20 Jun (1497922345), Jan Beulich wrote: > >>> On 19.06.17 at 18:57, wrote: > > --- a/xen/include/xen/mm.h > > +++ b/xen/include/xen/mm.h > > @@ -56,7 +56,7 @@ > > > > TYPE_SAFE(unsigned long, mfn); > > #define PRI_mfn "05lx" > > -#define

Re: [Xen-devel] [PATCH 01/24] xen/mm: Don't use _{g, m}fn for defining INVALID_{G, M}FN

or: initializer element is not constant > #define INVALID_MFN _mfn(~0UL) > > Signed-off-by: Julien Grall <julien.gr...@arm.com> Acked-by: Tim Deegan <t...@xen.org> > I know that this solution will not work for non-debug build. I would > like input from the community

Re: [Xen-devel] [PATCH v2 for-4.9] x86/pagewalk: Fix determination of Protection Key access rights

Andrew Cooper <andrew.coop...@citrix.com> Reviewed-by: Tim Deegan <t...@xen.org> ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH for-4.9] x86/pagewalk: Fix determination of Protection Key access rights

At 17:51 +0100 on 16 May (1494957116), Andrew Cooper wrote: > c/s 4c5d78a10 was accidentally buggy when handling Protection Keys. > Protection keys applies to all user translations, not just accesses which > originate from user mode. Reviewed-by: Tim Deegan <t...@xen.org> Does the

Re: [Xen-devel] [PATCH for-next] x86/shadow: Use ERR_PTR infrastructure for sh_emulate_map_dest()

; other changes. > > Signed-off-by: Andrew Cooper <andrew.coop...@citrix.com> s/sturct/struct/ Reviewed-by: Tim Deegan <t...@xen.org> ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel

Re: [Xen-devel] Security support scope (apropos of Xen and CNA)

Hi, At 09:59 +0100 on 05 May (1493978382), Lars Kurth wrote: > > On 5 May 2017, at 09:43, Tim Deegan <t...@xen.org> wrote: > > - Only features listed as Supported in MAINTAINERS get support. > > This seems related to George's proposal of the scope. I am not sure > MA

Re: [Xen-devel] Security support scope (apropos of Xen and CNA)

At 13:53 +0100 on 04 May (1493905990), Ian Jackson wrote: > To become a CNA (CVE Numbering Authority), which we would like to do, > we need to provide MITRE's CNA programme with a definition of the > scope of our CNA. That should be the scope of our general security > support, clearly. > > At

Re: [Xen-devel] [PATCH 3/7] x86/mm: Further restrict permissions on some virtual mappings

Only mappings of the M2P (compat and regular) don't need to be >writeable or executable. > * The PV GDT mappings don't need to be executable. > > Reported-by: Jann Horn <ja...@google.com> > Signed-off-by: Andrew Cooper <andrew.c

Re: [Xen-devel] [PATCH V2] xen/hvm: fix hypervisor crash with hvm_save_one()

At 10:15 +0100 on 03 May (1493806508), Tim Deegan wrote: > At 00:31 -0600 on 03 May (1493771502), Jan Beulich wrote: > > +else if ( ctxt.cur > sizeof(*desc) ) > > { > > uint32_t off; > > -const struct hvm_save_descriptor *desc; &

Re: [Xen-devel] [PATCH V2] xen/hvm: fix hypervisor crash with hvm_save_one()

At 00:31 -0600 on 03 May (1493771502), Jan Beulich wrote: > Hmm, with both of you being of that opinion, I've taken another > look. I think I see now why you think that way (this being data > from an internal producer, overflow/underflow are not a primary > concern), so I'll withdraw my objection

Re: [Xen-devel] [PATCH V2] xen/hvm: fix hypervisor crash with hvm_save_one()

.com> > Signed-off-by: Razvan Cojocaru <rcojoc...@bitdefender.com> > Tested-by: Razvan Cojocaru <rcojoc...@bitdefender.com> I actually preferred the first patch :P but this is fine. Acked-by: Tim Deegan <t...@xen.org> > diff --git a/xen/common/hvm/save.c b/xen/com

Re: [Xen-devel] [PATCH] xen/hvm: fix hypervisor crash with hvm_save_one()

appens when the per-type handler returns no data at all (because all VCPUs are offline). With the commit message fixed, Reviewed-by: Tim Deegan <t...@xen.org> ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH v2] x86/mm: also flush TLB when putting writable foreign page reference

At 02:50 -0600 on 02 May (1493693403), Jan Beulich wrote: > >>> On 02.05.17 at 10:32, wrote: > > At 04:52 -0600 on 28 Apr (1493355160), Jan Beulich wrote: > >> >>> On 27.04.17 at 11:51, wrote: > >> > At 03:23 -0600 on 27 Apr (1493263380), Jan Beulich wrote: > >> >>

Re: [Xen-devel] [PATCH v2] x86/mm: also flush TLB when putting writable foreign page reference

At 04:52 -0600 on 28 Apr (1493355160), Jan Beulich wrote: > >>> On 27.04.17 at 11:51, wrote: > > At 03:23 -0600 on 27 Apr (1493263380), Jan Beulich wrote: > >> ... it wouldn't better be the other way around: We use the patch > >> in its current (or even v1) form, and try to do

Re: [Xen-devel] [PATCH v2] x86/mm: also flush TLB when putting writable foreign page reference

t (but if it's that what > you're after, I could certainly collect a few numbers). I think that would be a good idea, just as a sanity-check. But apart from that the patch looks correct to me, so: Reviewed-by: Tim Deegan <t...@xen.org> for v2 (not v1). Cheers, Tim.

Re: [Xen-devel] [PATCH v2] x86/mm: also flush TLB when putting writable foreign page reference

At 08:07 -0600 on 26 Apr (1493194043), Jan Beulich wrote: > >>> On 25.04.17 at 12:59, wrote: > > Hi, > > > > At 02:59 -0600 on 25 Apr (1493089158), Jan Beulich wrote: > >> Jann's explanation of the problem: > >> > >> "start situation: > >> - domain A and domain B are PV domains >

Re: [Xen-devel] [PATCH v2] x86/mm: also flush TLB when putting writable foreign page reference

At 05:59 -0600 on 25 Apr (1493099950), Jan Beulich wrote: > >>> On 25.04.17 at 12:59, wrote: > > Hi, > > > > At 02:59 -0600 on 25 Apr (1493089158), Jan Beulich wrote: > >> Jann's explanation of the problem: > >> > >> "start situation: > >> - domain A and domain B are PV domains >

Re: [Xen-devel] [PATCH v2] x86/mm: also flush TLB when putting writable foreign page reference

Hi, At 02:59 -0600 on 25 Apr (1493089158), Jan Beulich wrote: > Jann's explanation of the problem: > > "start situation: > - domain A and domain B are PV domains > - domain A and B both have currently scheduled vCPUs, and the vCPUs >are not scheduled away > - domain A has XSM_TARGET

Re: [Xen-devel] [PATCH v2 for-4.9 1/6] x86/hvm: Correct some address space terminology

ndrew.coop...@citrix.com> > Reviewed-by: Paul Durrant <paul.durr...@citrix.com> For the whole series, Acked-by: Tim Deegan <t...@xen.org> ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH v3 5/6] x86/pagewalk: Improve the logic behind setting access and dirty bits

ent, to make it > easier to follow. > > Alter set_ad_bits() to take properly typed pointers and booleans rather than > integers. > > Signed-off-by: Andrew Cooper <andrew.coop...@citrix.com> > Reviewed-by: Jan Beulich <jbeul...@suse.c

Re: [Xen-devel] [PATCH v2 5/9] x86/pagewalk: Helpers for reserved bit handling

At 17:02 + on 23 Mar (1490288548), Andrew Cooper wrote: > On 23/03/17 16:55, Tim Deegan wrote: > > At 16:31 + on 16 Mar (1489681899), Andrew Cooper wrote: > >> Some bits are unconditionally reserved in pagetable entries, or reserved > >> because of alignmen

Re: [Xen-devel] [PATCH v2 9/9] x86/pagewalk: non-functional cleanup

At 16:31 + on 16 Mar (1489681903), Andrew Cooper wrote: > * Drop trailing whitespace > * Consistently apply Xen style > * Introduce a local variable block > > Signed-off-by: Andrew Cooper <andrew.coop...@citrix.com> Acked-by: Tim

Re: [Xen-devel] [PATCH v2 8/9] x86/pagewalk: Improve the logic behind setting access and dirty bits

At 16:31 + on 16 Mar (1489681902), Andrew Cooper wrote: > --- a/xen/arch/x86/mm/guest_walk.c > +++ b/xen/arch/x86/mm/guest_walk.c > @@ -32,24 +32,28 @@ asm(".file \"" __OBJECT_FILE__ "\""); > #include > #include > > -/* Modify a guest pagetable entry to set the Accessed and Dirty bits. >

Re: [Xen-devel] [PATCH v2 7/9] x86/shadow: Use the pagewalk reserved bits helpers

ut the installed shadow is valid and hardware > doesn't fault. > > Reuse the pagewalk reserved bits helpers, and assert in > l?e_propagate_from_guest() that shadows are not attempted to be created with > reserved bits set. > > Signed-off-by: Andrew Cooper <andrew.coop..

Re: [Xen-devel] [PATCH v2 5/9] x86/pagewalk: Helpers for reserved bit handling

individual vcpu and guest pagetable entry, and > calculates whether any reserved bits are set. > > While here, add a couple of newlines to aid readability. > > Signed-off-by: Andrew Cooper <andrew.coop...@citrix.com> Reviewed-by: Tim Deegan <t...@xen.org>, although:

Re: [Xen-devel] [PATCH v2 4/9] x86/pagewalk: Clean up guest_supports_* predicates

n CR4 rather than CR0. > > Requested-by: Jan Beulich <jbeul...@suse.com> > Signed-off-by: Andrew Cooper <andrew.coop...@citrix.com> Acked-by: Tim Deegan <t...@xen.org> (with or without the renaming Jan asked for). ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH v2 3/9] x86/shadow: Drop VALID_GFN()

At 16:31 + on 16 Mar (1489681897), Andrew Cooper wrote: > There is only one single user of VALID_GFN(). Inline the macro to remove the > added layer of indirection in sh_gva_to_gfn() > > Signed-off-by: Andrew Cooper <andrew.coop...@citrix.com> Acked-by: Tim De

Re: [Xen-devel] [PATCH v2 2/9] x86/pagewalk: Use pointer syntax for pfec parameter

At 16:31 + on 16 Mar (1489681896), Andrew Cooper wrote: > It is a pointer, not an array. > > No functional change. > > Requested-by: Jan Beulich <jbeul...@suse.com> > Signed-off-by: Andrew Cooper <andrew.coop...@citrix.com> Acke

[Xen-devel] [PATCH] tools/kdd: don't use a pointer to an unaligned field.

<roger@citrix.com> Signed-off-by: Tim Deegan <t...@xen.org> --- tools/debugger/kdd/kdd.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/tools/debugger/kdd/kdd.c b/tools/debugger/kdd/kdd.c index 70f007e..1bd5dd5 100644 --- a/tools/debugger/kdd/kdd.c +++ b/tools/

Re: [Xen-devel] [PATCH] tools/kdd: remove unneeded packed attributes

Hi, At 12:02 +0900 on 10 Mar (1489147353), Roger Pau Monne wrote: > The layout of the structures make them already aligned, there's no need for > the > packed attributes. That's not right -- kdd_pkt gets 8 bytes longer with this patch. In fact this code has the bug that clang's new warning is

Re: [Xen-devel] [PATCH 1/2] build/clang: remove the address-of-packed-member warning

At 14:36 + on 06 Mar (1488811016), George Dunlap wrote: > On 06/03/17 13:58, Jan Beulich wrote: > On 06.03.17 at 13:31, wrote: > >> --- a/Config.mk > >> +++ b/Config.mk > >> @@ -216,6 +216,7 @@ $(call > >>

Re: [Xen-devel] [PATCH 5/7] x86/shadow: Use the pagewalk reserved bits helpers

At 12:26 + on 02 Mar (1488457613), Andrew Cooper wrote: > On 01/03/17 16:03, Jan Beulich wrote: > On 27.02.17 at 15:03, wrote: > >> The shadow logic should never create a shadow of a guest PTE which contains > >> reserved bits from the guests point of view.

Re: [Xen-devel] [PATCH 7/7] x86/pagewalk: Re-implement the pagetable walker

gt; * 3-level entries can no longer alias Xen's idea of paged or shared. > > Signed-off-by: Andrew Cooper <andrew.coop...@citrix.com> Reviewed-by: Tim Deegan <t...@xen.org> ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH 2/7] x86/shadow: Try to correctly identify implicit supervisor accesses

At 14:03 + on 27 Feb (1488204193), Andrew Cooper wrote: > Signed-off-by: Andrew Cooper <andrew.coop...@citrix.com> Reviewed-by: Tim Deegan <t...@xen.org> ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH 6/7] x86/pagewalk: Consistently use guest_walk_*() helpers for translation

id, so this doesn't cause a behavioural change. > > Signed-off-by: Andrew Cooper <andrew.coop...@citrix.com> Reviewed-by: Tim Deegan <t...@xen.org> ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH 3/7] x86/pagewalk: Helpers for reserved bit handling

rs. > > Signed-off-by: Andrew Cooper <andrew.coop...@citrix.com> Reviewed-by: Tim Deegan <t...@xen.org> ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH 1/7] x86/hvm: Correctly identify implicit supervisor accesses

calculation of the appropriate pagewalk input before its first use. > > Signed-off-by: Andrew Cooper <andrew.coop...@citrix.com> Reviewed-by: Tim Deegan <t...@xen.org> ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH 3/7] x86/pagewalk: Helpers for reserved bit handling

At 14:17 + on 02 Mar (1488464221), Andrew Cooper wrote: > On 02/03/17 14:12, Tim Deegan wrote: > > At 14:03 + on 27 Feb (1488204194), Andrew Cooper wrote: > >> +static inline bool guest_has_pse36(const struct vcpu *v) > >> +{ > >> +

Re: [Xen-devel] [PATCH 5/7] x86/shadow: Use the pagewalk reserved bits helpers

At 14:03 + on 27 Feb (1488204196), Andrew Cooper wrote: > The shadow logic should never create a shadow of a guest PTE which contains Nit: a _valid/present_ shadow. > reserved bits from the guests point of view. Such a shadowed entry might not > cause #PF[RSVD] when walked by hardware, thus

Re: [Xen-devel] [PATCH 3/7] x86/pagewalk: Helpers for reserved bit handling

At 14:03 + on 27 Feb (1488204194), Andrew Cooper wrote: > +static inline bool guest_has_pse36(const struct vcpu *v) > +{ > + /* No support for 2-level PV guests. */ > +return is_pv_vcpu(v) ? 0 : paging_mode_hap(v->domain); > +} Should this check the CPUID policy to see whether PSE36

Re: [Xen-devel] [PATCH] x86/shadow: Fix build with CONFIG_SHADOW_PAGING=n following c/s 45ac805

NFIG run. > > Signed-off-by: Andrew Cooper <andrew.coop...@citrix.com> > --- Acked-by: Tim Deegan <t...@xen.org> ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH 2/3] x86: remove has_hvm_container_{domain/vcpu}

At 15:13 + on 24 Feb (1487949198), Roger Pau Monne wrote: > It is now useless since PVHv1 is removed and PVHv2 is a HVM domain from Xen's > point of view. > > Signed-off-by: Roger Pau Monné <roger@citrix.com> Acked-by: Tim De

Re: [Xen-devel] [PATCH v2] x86/VMX: sanitize VM86 TSS handling

ll function > were tools only (and hence we could freely change their behavior). > Also, since we wouldn't be able to tell size 128 from size 0 with what > you propose, "get" would then possibly return a value different from > what was passed to "set". Sure you could - just

Re: [Xen-devel] [PATCH] x86/paging: Package up the log dirty function pointers

: Andrew Cooper <andrew.coop...@citrix.com> Acked-by: Tim Deegan <t...@xen.org> ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH v2] x86/VMX: sanitize VM86 TSS handling

At 05:03 -0700 on 17 Feb (1487307837), Jan Beulich wrote: > The present way of setting this up is flawed: Leaving the I/O bitmap > pointer at zero means that the interrupt redirection bitmap lives > outside (ahead of) the allocated space of the TSS. Similarly setting a > TSS limit of 255 when only

Re: [Xen-devel] [PATCH] x86/mm: Swap mfn_valid() to use mfn_t

> > Signed-off-by: Andrew Cooper <andrew.coop...@citrix.com> Acked-by: Tim Deegan <t...@xen.org> ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH v3] x86/shadow: Correct guest behaviour when creating PTEs above maxphysaddr

() in guest_pt.h but it is unused in the > codebase. Repurpose it to perform a guest-specific maxphysaddr check, which > replaces the users of gfn_bits. > > Signed-off-by: Andrew Cooper <andrew.coop...@citrix.com> Reviewed-by: Tim Deegan <t...@xen.org> _

Re: [Xen-devel] [PATCH] x86/VMX: sanitize VM86 TSS handling

At 04:49 -0700 on 16 Feb (1487220558), Jan Beulich wrote: > >>> On 16.02.17 at 12:14, wrote: > On 15.02.17 at 12:21, wrote: > >> At 01:18 -0700 on 15 Feb (1487121525), Jan Beulich wrote: > >>> >>> On 14.02.17 at 18:33, wrote: > >>> >> TBD: Do

Re: [Xen-devel] [PATCH] x86/VMX: sanitize VM86 TSS handling

At 01:18 -0700 on 15 Feb (1487121525), Jan Beulich wrote: > >>> On 14.02.17 at 18:33, wrote: > >> TBD: Do we really want to re-init the TSS every time we are about to > >> use it? > > > > No - I think we should init it when the guest writes the param(s) and > > leave it at

Re: [Xen-devel] [PATCH] x86/VMX: sanitize VM86 TSS handling

At 01:13 -0700 on 15 Feb (1487121231), Jan Beulich wrote: > >>> On 14.02.17 at 18:35, wrote: > > At 06:37 -0700 on 13 Feb (1486967832), Jan Beulich wrote: > >> >>> On 13.02.17 at 14:19, wrote: > >> > -tss = mem_alloc(128, 128); > >> > -memset(tss, 0,

Re: [Xen-devel] [PATCH] x86/VMX: sanitize VM86 TSS handling

At 06:37 -0700 on 13 Feb (1486967832), Jan Beulich wrote: > >>> On 13.02.17 at 14:19, wrote: > > -tss = mem_alloc(128, 128); > > -memset(tss, 0, 128); > > +tss = mem_alloc(TSS_SIZE, TSS_SIZE); > > tss = mem_alloc(TSS_SIZE, 128); > > is sufficient here, as I've

Re: [Xen-devel] [PATCH] x86/VMX: sanitize VM86 TSS handling

O bitmap > pointer. Both this and the segment limit now take the allocated size > into account. > > Signed-off-by: Jan Beulich <jbeul...@suse.com> This looks pretty good to me. Once the question below is resolved, Reviewed-by: Tim Deegan <t...@xen.org> > --- > TBD: Do we

Re: [Xen-devel] [PATCH v2] x86/shadow: Correct guest behaviour when creating PTEs above maxphysaddr

td.maxphysaddr = max_t(uint8_t, p->extd.maxphysaddr, > (p->basic.pae || p->basic.pse36) ? 36 : > 32); That looks good to me. Reviewed-by: Tim Deegan <t...@xen.org> > >> @@ -360,6 +361,21 @@ void paging_dump_vcpu_info(struct vcpu *v); > >> int paging

Re: [Xen-devel] [PATCH v2] xen/p2m: Fix p2m_flush_table for non-nested cases

p;& > + p2m->np2m_base == P2M_BASE_EADDR ) Looks like p2m_is_nestedp2m(p2m) is the usual idiom. Either way: Reviewed-by: Tim Deegan <t...@xen.org> ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH] x86/shadow: Correct the behaviour of a guests view of maxphysaddr

At 15:29 + on 08 Feb (1486567798), Andrew Cooper wrote: > On Intel, a guest can get an PTE shadowed which should have faulted and > didn't (because the smfn is actually within 39 bits) Yes. , while on AMD, a > guest can try to create a PTE which shouldn't fault (because CPUID says > anything

Re: [Xen-devel] [PATCH] x86/shadow: Correct the behaviour of a guests view of maxphysaddr

Hi, At 12:36 + on 08 Feb (1486557378), Andrew Cooper wrote: > XSA-173 (c/s 8b1764833) introduces gfn_bits, and an upper limit which might be > lower than the real maxphysaddr, to avoid overflowing the superpage shadow > backpointer. > > However, plenty of hardware has a physical address

Re: [Xen-devel] [PATCH 2/2] x86/shadow: Move shadow pagetable fields into struct shadow_vcpu

At 17:26 + on 30 Jan (1485797162), Andrew Cooper wrote: > The vTLB and last_write* booleans are used exclusively by the shadow pagetable > code. Move them from paging_vcpu to shadow_vcpu, which causes them to be > entirely omitted on a build without shadow paging support. > > While changing

Re: [Xen-devel] [PATCH 1/2] x86/mm: Plumb a error return through {paging, hap, shadow}_vcpu_init()

At 17:26 + on 30 Jan (1485797161), Andrew Cooper wrote: > No functional change yet, but required for subsequent changes. > > Signed-off-by: Andrew Cooper <andrew.coop...@citrix.com> Acked-by: Tim Deegan <t...@xen.org> ___ X

Re: [Xen-devel] [PATCH] xen/p2m: Remove np2m-specific filter from generic p2m_flush_table

At 03:44 -0700 on 31 Jan (1485834259), Jan Beulich wrote: > >>> On 30.01.17 at 16:17, wrote: > > Commit 71bb7304e7a7a35ea6df4b0cedebc35028e4c159 added flushing of > > nested p2m tables whenever the host p2m table changed. Unfortunately > > in the process, it added a

Re: [Xen-devel] [PATCH] x86/p2m: Stop other vcpus using a nested p2m before clearing it

won't continue to use the flushed mappings. > > While modifying this function, remove all the trailing whitespace and tweak > style in the affected areas. > > Signed-off-by: Andrew Cooper <andrew.coop...@citrix.com> Reviewed-by: Tim Deegan <t...@xen.org> __

Re: [Xen-devel] [PATCH v5 4/9] xen/x86: populate PVHv2 Dom0 physical memory map

At 09:40 -0700 on 27 Jan (1485510008), Jan Beulich wrote: > >>> On 27.01.17 at 14:20, <t...@xen.org> wrote: > > At 12:51 + on 27 Jan (1485521470), Andrew Cooper wrote: > >> On 27/01/17 11:14, Tim Deegan wrote: > >> > But looking at it now,

Re: [Xen-devel] [PATCH v5 4/9] xen/x86: populate PVHv2 Dom0 physical memory map

> Despite being owned by the guest, this TSS is actually managed by Xen. > It should be initialised to defaults each time Xen needs to use it on > behalf of the guest. At 14:35 + on 27 Jan (1485527708), Andrew Cooper wrote: > On 27/01/17 14:01, Tim Deegan wrote: > > Hi

  1   2   3   4   5   6   >