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 access
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
> >> - domain A
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
> >> - domain A
uld highly doubt (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
for v2 (not v1).
Cheers,
Tim.
__
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 something about
> >>
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:
> >> >> ... it wouldn't better be the o
ICS the underflow happens when the
per-type handler returns no data at all (because all VCPUs are
offline).
With the commit message fixed,
Reviewed-by: Tim Deegan
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
n Cojocaru
I actually preferred the first patch :P but this is fine.
Acked-by: Tim Deegan
> diff --git a/xen/common/hvm/save.c b/xen/common/hvm/save.c
> index 78706f5..3bdd124 100644
> --- a/xen/common/hvm/save.c
> +++ b/xen/common/hvm/save.c
> @@ -113,6 +113,9 @@ int hvm
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 t
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;
&
d 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
> Signed-off-by: Andrew Cooper
Reviewed-by: Tim Deegan
_
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 the
Hi,
At 09:59 +0100 on 05 May (1493978382), Lars Kurth wrote:
> > On 5 May 2017, at 09:43, Tim Deegan wrote:
> > - Only features listed as Supported in MAINTAINERS get support.
>
> This seems related to George's proposal of the scope. I am not sure
> MAINTAINERS is
; other changes.
>
> Signed-off-by: Andrew Cooper
s/sturct/struct/
Reviewed-by: Tim Deegan
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
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
Does the test for write-p
.
I think this would be clearer as "all data accesses to user-mode addresses".
> PKRU WD applies to any data write, not just to
>mapping which are writable. However, a supervisor access without CR0.WP
>bypasses any protection from protection keys.
>
&g
or: initializer element is not constant
> #define INVALID_MFN _mfn(~0UL)
>
> Signed-off-by: Julien Grall
Acked-by: Tim Deegan
> I know that this solution will not work for non-debug build. I would
> like input from the community on way to fix it nicely.
It seems to WFM: htt
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();
> +
> +cpumask_setall(&rcu_ctrl
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 w
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 sh_page_fault(s
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
&
Signed-off-by: Tim Deegan
---
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/shad
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
> >>> +++ b/xen/arch/x86/mm/shadow/multi.c
> >>> @@ -3112,7 +3112,6 @@ static int
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, wrote:
> > > atomic_read() is not free to be reordered by the compiler. It is an asm
> > > volatile with a vo
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 16.08.17 at 13:22, wrote:
> >> >>> --- a/xen
the grace
> period, and we simplify the code (a.k.a. 'win-win' :-D).
Thanks!
Reviewed-by: Tim Deegan
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
_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
Acked-by: Tim Deegan
with one adjustment:
> /* common paging mode bits */
> #define PG_mode_shift 10
> -/* Refcounts
xen/paging.h.
> >
> > Signed-off-by: Wei Liu
>
> This is something I certainly would want Tim to see (and perhaps
> approve).
Thanks. I see and approve. :)
Acked-by: Tim Deegan
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
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 ==
> > >
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
Acked-by: Tim Deegan
___
Xen-devel mailing list
Xen-devel@lists.xen.
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
Acked-by: Tim Deegan
___
Xen-devel
At 13:19 +0100 on 30 Aug (1504099173), Andrew Cooper wrote:
> No functional change.
>
> Signed-off-by: Andrew Cooper
Acked-by: Tim Deegan
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
omment and some clarifying assertions.
>
> Also, there is no longer support for translate != external, so drop the clause
> as it is dead.
>
> Finally, correct the comment for sh_install_xen_entries_in_l2h(). We need to
> add Xen mappings into l2h for 3-on-any PV guests.
>
> Signe
: ROOT_PAGETABLE_XEN_SLOTS);
> +
> +memcpy(&l4t[l4_table_offset(XEN_VIRT_START)],
> + &idle_pg_table[l4_table_offset(XEN_VIRT_START)],
> + (ROOT_PAGETABLE_FIRST_XEN_SLOT + slots -
> + l4_table
pings
For the shadow pagetable changes in patches 1 and 2:
Acked-by: Tim Deegan
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
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
Acked-by: Tim Deegan
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
___
Xen-devel mai
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
__
At 11:23 +0100 on 17 Oct (1508239433), Roger Pau Monne wrote:
> fetch_type_names usage is guarded by SHADOW_DEBUG_PROPAGATE in
> SHADOW_DEBUG, fix the declaration so it's also guarded by
> SHADOW_DEBUG_PROPAGATE instead of DEBUG_TRACE_DUMP.
>
> Signed-off-by: Roger Pau M
t of the callers are now switched to _mfn(domain_page_to_mfn(...)).
>
> Signed-off-by: Julien Grall
Acked-by: Tim Deegan
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
the walker should accept them.
Reviewed-by: Tim Deegan
> 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 control setti
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 exte
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, rc
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
>
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
> > &g
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 INVALID_MFN _mfn(~0UL)
>
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
> >> > @@ -56,7 +56,7 @@
> >> >
>
ed bytes by mistake.
Tim.
> Signed-off-by: Andrew Cooper
> ---
> CC: Tim Deegan
> CC: Jan Beulich
> ---
> xen/arch/x86/mm/shadow/common.c | 10 +++---
> 1 file changed, 7 insertions(+), 3 deletions(-)
>
> diff --git a/xen/arch/x86/mm/shadow/common.c b/xen/arch/x8
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
Cheers,
Tim.
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
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 -0600 on 20 Jun (1497929778), Jan Beul
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;
>
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 20.06.17 at 12:06, wrote:
> > At 03:36
mmon
> 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
Acked-by:
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, intpte_t new, mfn_t gmfn)
Can
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
Reviewed-by
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.
> >
> > Export base_disallow_m
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.
>
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
Acked-by: Tim Deegan
___
Xen-devel m
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 alignment re
, 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
> Reviewed-by: Jan Beulich
Reviewed-by: Tim Deegan
___
Xen-devel mai
Reviewed-by: Paul Durrant
For the whole series, Acked-by: Tim Deegan
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
calls. The
>wrappers already include it.
> * Use hex rather than decimal for printing a pagefault error code.
>
> Signed-off-by: Andrew Cooper
Acked-by: Tim Deegan
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
At 10:55 +0100 on 08 Sep (1473332146), Andrew Cooper wrote:
> Signed-off-by: Andrew Cooper
s/predecates/predicates/, and Acked-by: Tim Deegan
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
At 11:56 + on 09 Sep (1473422177), Lars Kurth wrote:
> Community Decisions with Funding and Legal Implications
> (#funding-and-legal)
> ---
>
> In some cases sub-project local and global decisions **may require
> input** from the [Advisory Bo
;
> Signed-off-by: Andrew Cooper
Acked-by: Tim Deegan
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
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 width
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
r));
> ASSERT(page_list_empty(&p2m->pod.single));
>
> -if ( p2m->np2m_base == P2M_BASE_EADDR )
> +/* No need to flush if it's already empty */
> +if ( p2m->p2m_class == p2m_nested &&
> +
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
> >> @@ -360,6 +361,21 @@ void paging_dump_vcpu_info(struct vcpu *v);
> >> int paging_set_allocation(s
pointer. Both this and the segment limit now take the allocated size
> into account.
>
> Signed-off-by: Jan Beulich
This looks pretty good to me. Once the question below is resolved,
Reviewed-by: Tim Deegan
> ---
> TBD: Do we really want to re-init the TSS every time we are about
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 noticed (only) whil
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, 128);
> >> > +tss = mem_alloc(TSS_
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 that. Hvmloader m
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 we really want to re-init the TSS every time we
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
Reviewed-by: Tim Deegan
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
nge.
>
> Signed-off-by: Andrew Cooper
Acked-by: Tim Deegan
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
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
ndrew Cooper
Acked-by: Tim Deegan
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
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 keep the client's version and s/0/128/ when
setting up the TSS. But let's not bikeshed this any further.
Reviewed-by: Tim Deegan
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
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é
Acked-by: Tim Deegan
___
Xen-devel
G run.
>
> Signed-off-by: Andrew Cooper
> ---
Acked-by: Tim Deegan
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
s it doesn't need
> recalculating for each instruction.
>
> Signed-off-by: Andrew Cooper
Shadow code changes Acked-by: Tim Deegan
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
Hi,
At 15:38 + on 23 Nov (1479915529), Andrew Cooper wrote:
> The emulator needs to gain an understanding of interrupts and exceptions
> generated by its actions.
>
> Move hvm_emulate_ctxt.{exn_pending,trap} into struct x86_emulate_ctxt so they
> are visible to the emulator. This removes the
At 15:38 + on 23 Nov (1479915532), Andrew Cooper wrote:
> Introduce a new x86_emul_pagefault() similar to x86_emul_hw_exception(), and
> use this instead of hvm_inject_page_fault() from emulation codepaths.
>
> Replace one hvm_inject_hw_exception() in the shadow emulation codepaths.
>
> Signe
At 15:38 + on 23 Nov (1479915533), Andrew Cooper wrote:
> which is filled with pagefault information should one occur.
>
> No functional change.
>
> Signed-off-by: Andrew Cooper
> Reviewed-by: Jan Beulich
Acked-by: Tim Deegan
___
At 15:38 + on 23 Nov (1479915534), Andrew Cooper wrote:
> No functional change.
>
> Signed-off-by: Andrew Cooper
Shouldn't this also update the comments to describe the new semantics
of hvm_copy_*()?
Tim.
___
Xen-devel mailing list
Xen-devel@lis
At 15:38 + on 23 Nov (1479915535), Andrew Cooper wrote:
> The functions use linear addresses, not virtual addresses, as no segmentation
> is used. (Lots of other code in Xen makes this mistake.)
>
> Signed-off-by: Andrew Cooper
Acked-by
At 15:38 + on 23 Nov (1479915536), Andrew Cooper wrote:
> Drop the call to hvm_inject_page_fault() in __hvm_copy(), and require callers
> to inject the pagefault themselves.
>
> No functional change.
>
> Signed-off-by: Andrew Cooper
> index afacd5f..88d4642 100644
> --- a/xen/arch/x86/mm/sh
At 16:35 + on 23 Nov (1479918931), Tim Deegan wrote:
> At 15:38 + on 23 Nov (1479915534), Andrew Cooper wrote:
> > No functional change.
> >
> > Signed-off-by: Andrew Cooper
>
> Shouldn't this also update the comments to describe the new semantics
>
At 09:33 -0700 on 23 Nov (1479893609), Jan Beulich wrote:
> >>> On 23.11.16 at 17:19, wrote:
> > Hi,
> >
> > At 15:38 + on 23 Nov (1479915529), Andrew Cooper wrote:
> >> The emulator needs to gain an understanding of interrupts and exceptions
> >> generated by its actions.
> >>
> >> Move hvm
At 16:40 + on 23 Nov (1479919254), Andrew Cooper wrote:
> On 23/11/16 16:31, Tim Deegan wrote:
> > At 15:38 + on 23 Nov (1479915532), Andrew Cooper wrote:
> >> Introduce a new x86_emul_pagefault() similar to x86_emul_hw_exception(),
> >> and
> >> use t
At 17:19 + on 24 Nov (1480007992), Andrew Cooper wrote:
> On 24/11/16 17:08, Jan Beulich wrote:
> On 24.11.16 at 18:00, wrote:
> >> On 24/11/16 14:53, Jan Beulich wrote:
> >> On 23.11.16 at 16:38, wrote:
> --- a/xen/arch/x86/mm.c
> +++ b/xen/arch/x86/mm.c
> @@ -5377,7
At 00:25 -0700 on 25 Nov (1480033543), Jan Beulich wrote:
> >>> On 24.11.16 at 18:37, wrote:
> > As an interim between now and getting a proper audit hook, would a bool
> > permit_traps in x86_emulate_ctxt suffice?
>
> That's one option; the other would be to do away with only the
> exception inj
frame suffers a pagefault during translation.
>
> Signed-off-by: Andrew Cooper
Acked-by: Tim Deegan
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
at the time.
>
> It is only used twice; there is no need to call it out differently from other
> uses of X86EMUL_RETRY.
>
> No functional change.
>
> Signed-off-by: Andrew Cooper
Acked-by: Tim Deegan
___
Xen-devel mailing l
c inline wrapper.
> reserved_bit_page_fault() is pure code motion.
>
> No functional change.
>
> Signed-off-by: Andrew Cooper
Acked-by: Tim Deegan
with one note:
> +if ( vector == TRAP_page_fault )
> +{
> +v->arch.pv_vcpu.ctrlreg[2] = event->cr2;
&g
At 11:13 + on 28 Nov (1480331605), Andrew Cooper wrote:
> The emulator needs to gain an understanding of interrupts and exceptions
> generated by its actions.
>
> Move hvm_emulate_ctxt.{exn_pending,trap} into struct x86_emulate_ctxt so they
> are visible to the emulator. This removes the need
At 12:48 + on 28 Nov (1480337304), Andrew Cooper wrote:
> On 28/11/16 12:04, Tim Deegan wrote:
> > At 11:13 + on 28 Nov (1480331605), Andrew Cooper wrote:
> >> +/*
> >> * NB. We do not unshadow on X86EMUL_EXCEPTION. It's not clear that it
>
Hi,
At 11:13 + on 28 Nov (1480331610), Andrew Cooper wrote:
> Use x86_emul_{hw_exception,pagefault}() rather than
> {pv,hvm}_inject_page_fault() and hvm_inject_hw_exception() to cause raised
> faults to be known to the emulator. This requires altering the callers of
> x86_emulate() to properl
At 11:13 + on 28 Nov (1480331614), Andrew Cooper wrote:
> Drop the call to hvm_inject_page_fault() in __hvm_copy(), and require callers
> to inject the pagefault themselves.
This seems like it'd be easy to forget to DTRT with the fault,
especially in code being ported forward across this serie
1 - 100 of 612 matches
Mail list logo
