At 10:41 -0700 on 25 Mar (1427280115), Ed White wrote:
> >>
> >> The second thing is how similar some of this is to nested p2m code,
> >> making me wonder whether it could share more code with that. It's not
> >> as much duplication as I had feared, but e.g. altp2m_write_p2m_entry()
> >> is _ident
>>
>> The second thing is how similar some of this is to nested p2m code,
>> making me wonder whether it could share more code with that. It's not
>> as much duplication as I had feared, but e.g. altp2m_write_p2m_entry()
>> is _identical_ to nestedp2m_write_p2m_entry(), (making the
>> copyright cl
>>
>> Is there any chance you might reconsider your decision not to help
>> with toolstack support of the patch series? I'm still trying to find
>> an internal resource to do that work, but right now it's the biggest
>> risk I see to getting the series into 4.6.
>
> My comment regarding hesitation
On 2015/01/13 21:45, Andrew Cooper wrote:
> On 13/01/15 20:02, Ed White wrote:
>> On 01/13/2015 11:01 AM, Andrew Cooper wrote:
>>
>>> I can't think of any reasonable case where the alternate p2m would want
>>> mappings different to the host p2m. That is to say, an altp2m will map
>>> the same set
At 11:58 +0100 on 05 Mar (1425553138), Tamas K Lengyel wrote:
> On Thu, Mar 5, 2015 at 11:36 AM, Tim Deegan wrote:
> > At 00:06 +0100 on 05 Mar (1425510383), Tamas K Lengyel wrote:
> >> Let's assume we trap an instruction that only performs data accesses
> >> on pages other than the one the instru
On Thu, Mar 5, 2015 at 11:36 AM, Tim Deegan wrote:
> At 00:06 +0100 on 05 Mar (1425510383), Tamas K Lengyel wrote:
>> Let's assume we trap an instruction that only performs data accesses
>> on pages other than the one the instruction was fetched from. Since
>> the instruction fetch is repeated aft
On Thu, Mar 5, 2015 at 12:41 AM, Ed White wrote:
> On 03/04/2015 03:06 PM, Tamas K Lengyel wrote:
>>> Right. The key observation is that at any single point in time, a given
>>> hardware thread can be fetching an instruction or reading data, but not
>>> both.
>>
>> Fine, as lon
At 00:06 +0100 on 05 Mar (1425510383), Tamas K Lengyel wrote:
> Let's assume we trap an instruction that only performs data accesses
> on pages other than the one the instruction was fetched from. Since
> the instruction fetch is repeated after a failed data access due to
> EPT violation, the page
On 03/04/2015 03:06 PM, Tamas K Lengyel wrote:
>> Right. The key observation is that at any single point in time, a given
>> hardware thread can be fetching an instruction or reading data, but not
>> both.
>
> Fine, as long as an instruction reading itself isn't going to lead to
> Right. The key observation is that at any single point in time, a given
> hardware thread can be fetching an instruction or reading data, but not
> both.
Fine, as long as an instruction reading itself isn't going to lead to
a live lock.
>>>
>>> That's not how the h
On 01/22/2015 07:42 AM, Tim Deegan wrote:
> At 13:54 -0800 on 19 Jan (1421672054), Ed White wrote:
>>> Or: declare in the interface that the altp2ms are soft state that can
>>> be dropped on migration, with some suitable callback (#VE injection?)
>>> to the guest when an altp2m 'view' is not availa
At 13:54 -0800 on 19 Jan (1421672054), Ed White wrote:
> > Or: declare in the interface that the altp2ms are soft state that can
> > be dropped on migration, with some suitable callback (#VE injection?)
> > to the guest when an altp2m 'view' is not available. That depends on
> > whether the in-gue
On 01/20/2015 12:47 AM, Jan Beulich wrote:
On 19.01.15 at 22:54, wrote:
>> There's also the issue that access permissions
>> are soft state and can be reverted to default in certain cases.
>
> Some instances of which have got removed during the 4.5 cycle,
> and at least some of the remaining
>>> On 19.01.15 at 22:54, wrote:
> There's also the issue that access permissions
> are soft state and can be reverted to default in certain cases.
Some instances of which have got removed during the 4.5 cycle,
and at least some of the remaining ones are deemed at least
questionable too. I.e. if
> Or: declare in the interface that the altp2ms are soft state that can
> be dropped on migration, with some suitable callback (#VE injection?)
> to the guest when an altp2m 'view' is not available. That depends on
> whether the in-guest agent can reconstruct the state it needs from
> scratch.
>
On 01/17/2015 01:49 AM, Tim Deegan wrote:
> At 13:43 -0800 on 16 Jan (1421412191), Ed White wrote:
>> I've tried to make all my work consistent with existing code
>> and design in the same vein or same source file, regardless of my
>> opinion of that existing content, unless I had some compelling r
Hi,
At 15:01 + on 17 Jan (1421503283), Andrew Cooper wrote:
> With this altp2m code, I have been thinking about migration and passthrough.
>
> Migration and passthrough are themselves mutually exclusive features, as
> logdirty cant identify DMA writes (and the toolstack can probably be
> forg
On 17/01/2015 09:31, Tim Deegan wrote:
> Hi,
>
> At 19:33 +0100 on 16 Jan (1421433186), Tim Deegan wrote:
- Feature compatibilty/completeness. You pointed out yourself that
it doesn't work with nested HVM or migration. I think I'd have to
add mem_event/access/paging and PCI pas
At 13:43 -0800 on 16 Jan (1421412191), Ed White wrote:
> I've tried to make all my work consistent with existing code
> and design in the same vein or same source file, regardless of my
> opinion of that existing content, unless I had some compelling reason
> not to. I've also tried not to touch an
At 12:32 -0800 on 16 Jan (1421407932), Ed White wrote:
> >
> >> As I said in discussion with Andrew, my aim was to make it possible
> >> for these same changes to be extensible to AMD processors if they
> >> support multiple copies of whatever their EPT equivalent is, by
> >> simply emulating VMFU
Hi,
At 19:33 +0100 on 16 Jan (1421433186), Tim Deegan wrote:
> > > - Feature compatibilty/completeness. You pointed out yourself that
> > > it doesn't work with nested HVM or migration. I think I'd have to
> > > add mem_event/access/paging and PCI passthrough to the list of
> > > features
>
> I would have thought, from the tone of your earlier comments, that
> you were aiming for a bar somewhat higher than "as good as
> nestedp2m". :) I hope you'll also understand that given how well that
> has turned out, we shouldn't necessarily apply the same standard to
> new code as we did t
>
>> As I said in discussion with Andrew, my aim was to make it possible
>> for these same changes to be extensible to AMD processors if they
>> support multiple copies of whatever their EPT equivalent is, by
>> simply emulating VMFUNC and #VE. That's why there are some wrappers
>> in the implemen
Hi,
At 10:23 -0800 on 15 Jan (1421313824), Ed White wrote:
> On 01/15/2015 08:15 AM, Tim Deegan wrote:
> > I see there's been some discussion of how this would be useful for an
> > out-of-domain inspection tool, but could you talk some more about the
> > usefulness of the in-VM callers? I'm not s
On 01/16/2015 02:43 AM, Tamas K Lengyel wrote:
> On Thu, Jan 15, 2015 at 6:31 PM, Ed White wrote:
>> On 01/15/2015 02:39 AM, Tamas K Lengyel wrote:
There are ways of avoiding the
single-step too, although I don't think that falls within the scope
of this conversation.
Ed
>
On 01/16/2015 12:12 AM, Jan Beulich wrote:
On 15.01.15 at 19:23, wrote:
>> On 01/15/2015 08:15 AM, Tim Deegan wrote:
>>> - Feature compatibilty/completeness. You pointed out yourself that
>>> it doesn't work with nested HVM or migration. I think I'd have to
>>> add mem_event/access/pagi
On 01/15/2015 11:35 PM, Jan Beulich wrote:
On 15.01.15 at 18:28, wrote:
>> On 01/15/2015 12:16 AM, Jan Beulich wrote:
>> On 14.01.15 at 18:35, wrote:
Right. The key observation is that at any single point in time, a given
hardware thread can be fetching an instruction or readin
On Thu, Jan 15, 2015 at 6:31 PM, Ed White wrote:
> On 01/15/2015 02:39 AM, Tamas K Lengyel wrote:
>>> There are ways of avoiding the
>>> single-step too, although I don't think that falls within the scope
>>> of this conversation.
>>>
>>> Ed
>>
>> I would be very interested in knowing how we can a
>>> On 15.01.15 at 19:23, wrote:
> On 01/15/2015 08:15 AM, Tim Deegan wrote:
>> - Feature compatibilty/completeness. You pointed out yourself that
>> it doesn't work with nested HVM or migration. I think I'd have to
>> add mem_event/access/paging and PCI passthrough to the list of
>> featu
>>> On 15.01.15 at 18:28, wrote:
> On 01/15/2015 12:16 AM, Jan Beulich wrote:
> On 14.01.15 at 18:35, wrote:
>>> Right. The key observation is that at any single point in time, a given
>>> hardware thread can be fetching an instruction or reading data, but not
>>> both.
>>
>> Fine, as long a
On 01/15/2015 09:45 AM, Tim Deegan wrote:
> At 09:28 -0800 on 15 Jan (1421310487), Ed White wrote:
>> On 01/15/2015 12:16 AM, Jan Beulich wrote:
>> On 14.01.15 at 18:35, wrote:
On 01/14/2015 03:28 AM, Tamas K Lengyel wrote:
> At the mem_access trap point you can swap in an altp2m wher
On 01/15/2015 08:15 AM, Tim Deegan wrote:
> Hello,
>
> Thanks for sending this series - in particular, thank you for sending
> it early in the release cycle! I'll review some of the patches
> individually but since I expect there will be some changes to come in
> future versions I'm not going to
At 09:28 -0800 on 15 Jan (1421310487), Ed White wrote:
> On 01/15/2015 12:16 AM, Jan Beulich wrote:
> On 14.01.15 at 18:35, wrote:
> >> On 01/14/2015 03:28 AM, Tamas K Lengyel wrote:
> >>> At the mem_access trap point you can swap in an altp2m where the
> >>> gfn->mfn mapping is the one where
On 01/15/2015 02:39 AM, Tamas K Lengyel wrote:
>> There are ways of avoiding the
>> single-step too, although I don't think that falls within the scope
>> of this conversation.
>>
>> Ed
>
> I would be very interested in knowing how we can avoid the singlestep
> phase. Are you envisioning using thi
On 01/15/2015 12:16 AM, Jan Beulich wrote:
On 14.01.15 at 18:35, wrote:
>> On 01/14/2015 03:28 AM, Tamas K Lengyel wrote:
>>> At the mem_access trap point you can swap in an altp2m where the
>>> gfn->mfn mapping is the one where the breakpoints are hidden,
>>> singlestep, then swap the origin
Hello,
Thanks for sending this series - in particular, thank you for sending
it early in the release cycle! I'll review some of the patches
individually but since I expect there will be some changes to come in
future versions I'm not going to go into too much detail.
I see there's been some disc
> There are ways of avoiding the
> single-step too, although I don't think that falls within the scope
> of this conversation.
>
> Ed
I would be very interested in knowing how we can avoid the singlestep
phase. Are you envisioning using this with a split-TLB? IMHO this is a
pretty critical compone
>>> On 14.01.15 at 18:35, wrote:
> On 01/14/2015 03:28 AM, Tamas K Lengyel wrote:
>> At the mem_access trap point you can swap in an altp2m where the
>> gfn->mfn mapping is the one where the breakpoints are hidden,
>> singlestep, then swap the original p2m back. While this approach still
>> has so
On 01/14/2015 03:28 AM, Tamas K Lengyel wrote:
> On Wed, Jan 14, 2015 at 12:09 PM, Jan Beulich wrote:
> On 14.01.15 at 11:31, wrote:
>>> On Wed, Jan 14, 2015 at 8:04 AM, Jan Beulich wrote:
>>> Ed White 01/13/15 10:32 PM >>>
> On 01/13/2015 12:45 PM, Andrew Cooper wrote:
>> On 13
On Wed, Jan 14, 2015 at 12:09 PM, Jan Beulich wrote:
On 14.01.15 at 11:31, wrote:
>> On Wed, Jan 14, 2015 at 8:04 AM, Jan Beulich wrote:
>> Ed White 01/13/15 10:32 PM >>>
On 01/13/2015 12:45 PM, Andrew Cooper wrote:
> On 13/01/15 20:02, Ed White wrote:
>> The set of mfn's i
>>> On 14.01.15 at 11:31, wrote:
> On Wed, Jan 14, 2015 at 8:04 AM, Jan Beulich wrote:
> Ed White 01/13/15 10:32 PM >>>
>>>On 01/13/2015 12:45 PM, Andrew Cooper wrote:
On 13/01/15 20:02, Ed White wrote:
> The set of mfn's is the same, but I do allow gfn->mfn mappings to be
> mod
On Wed, Jan 14, 2015 at 8:04 AM, Jan Beulich wrote:
Ed White 01/13/15 10:32 PM >>>
>>On 01/13/2015 12:45 PM, Andrew Cooper wrote:
>>> On 13/01/15 20:02, Ed White wrote:
The set of mfn's is the same, but I do allow gfn->mfn mappings to be
modified under certain circumstances. One us
>>> Ed White 01/13/15 10:32 PM >>>
>On 01/13/2015 12:45 PM, Andrew Cooper wrote:
>> On 13/01/15 20:02, Ed White wrote:
>>> The set of mfn's is the same, but I do allow gfn->mfn mappings to be
>>> modified under certain circumstances. One use of this is to point the
>>> same VA to different physica
>>> Ed White 01/13/15 9:03 PM >>>
>On 01/13/2015 11:01 AM, Andrew Cooper wrote:
>> One thing I have noticed while looking at the #VE stuff that EPT also
>> supports A/D tracking, which might be quite a nice optimisation and
>> forgo the need for p2m_ram_logdirty, but I think this should be treated
On 01/13/2015 12:45 PM, Andrew Cooper wrote:
> On 13/01/15 20:02, Ed White wrote:
>> On 01/13/2015 11:01 AM, Andrew Cooper wrote:
>>> On 09/01/15 21:26, Ed White wrote:
This set of patches adds support to hvm domains for EPTP switching by
creating
multiple copies of the host p2m (cu
On 13/01/15 20:02, Ed White wrote:
> On 01/13/2015 11:01 AM, Andrew Cooper wrote:
>> On 09/01/15 21:26, Ed White wrote:
>>> This set of patches adds support to hvm domains for EPTP switching by
>>> creating
>>> multiple copies of the host p2m (currently limited to 10 copies).
>>>
>>> The primary u
On 01/13/2015 11:01 AM, Andrew Cooper wrote:
> On 09/01/15 21:26, Ed White wrote:
>> This set of patches adds support to hvm domains for EPTP switching by
>> creating
>> multiple copies of the host p2m (currently limited to 10 copies).
>>
>> The primary use of this capability is expected to be in
On 09/01/15 21:26, Ed White wrote:
> This set of patches adds support to hvm domains for EPTP switching by creating
> multiple copies of the host p2m (currently limited to 10 copies).
>
> The primary use of this capability is expected to be in scenarios where access
> to memory needs to be monitore
On 01/13/2015 02:21 AM, Tamas K Lengyel wrote:
> On Mon, Jan 12, 2015 at 7:31 PM, Ed White wrote:
>> On 01/12/2015 10:00 AM, Ian Jackson wrote:
>>> Ed White writes ("Re: [PATCH 00/11] Alternate p2m: support multiple copies
>>> of host p2m"):
The hypercalls are all there. My testing is all do
On 01/13/2015 12:56 AM, Jan Beulich wrote:
On 12.01.15 at 18:36, wrote:
>> On 01/12/2015 02:00 AM, Jan Beulich wrote:
>> On 10.01.15 at 00:04, wrote:
On 01/09/2015 02:41 PM, Andrew Cooper wrote:
> Having some non-OS part of the guest swap the EPT tables and
> accidentally tu
Jan Beulich writes ("Re: [Xen-devel] [PATCH 00/11] Alternate p2m: support
multiple copies of host p2m"):
> On 12.01.15 at 18:36, wrote:
> > Should some version of this patch series be accepted, my hope is that
> > someone who does understand xsm policies would put the
Ed White writes ("Re: [PATCH 00/11] Alternate p2m: support multiple copies of
host p2m"):
> On 01/12/2015 10:00 AM, Ian Jackson wrote:
> > To support this code in-tree, I think we will need Open Source code
> > for exercising it, surely ?
>
> I'm hoping that, as Andrew says, there will be people
On Mon, Jan 12, 2015 at 7:31 PM, Ed White wrote:
> On 01/12/2015 10:00 AM, Ian Jackson wrote:
>> Ed White writes ("Re: [PATCH 00/11] Alternate p2m: support multiple copies
>> of host p2m"):
>>> The hypercalls are all there. My testing is all done in a Windows
>>> domU with the tests running insid
>>> On 12.01.15 at 18:36, wrote:
> On 01/12/2015 02:00 AM, Jan Beulich wrote:
> On 10.01.15 at 00:04, wrote:
>>> On 01/09/2015 02:41 PM, Andrew Cooper wrote:
Having some non-OS part of the guest swap the EPT tables and
accidentally turn a DMA buffer read-only is not going to end wel
On 01/12/2015 10:00 AM, Ian Jackson wrote:
> Ed White writes ("Re: [PATCH 00/11] Alternate p2m: support multiple copies of
> host p2m"):
>> The hypercalls are all there. My testing is all done in a Windows
>> domU with the tests running inside that domain, so I couldn't use
>> tools support even i
Ed White writes ("Re: [PATCH 00/11] Alternate p2m: support multiple copies of
host p2m"):
> The hypercalls are all there. My testing is all done in a Windows
> domU with the tests running inside that domain, so I couldn't use
> tools support even if I had it.
To support this code in-tree, I think
On 12/01/15 17:43, Ian Jackson wrote:
> Ed White writes ("Re: [PATCH 00/11] Alternate p2m: support multiple copies of
> host p2m"):
>> On 01/12/2015 04:17 AM, Ian Jackson wrote:
>>> Are there tools parts to come later ?
>> I copied you because get_maintainer picked you. There is scope for tools
>>
On 01/12/2015 09:43 AM, Ian Jackson wrote:
> Ed White writes ("Re: [PATCH 00/11] Alternate p2m: support multiple copies of
> host p2m"):
>> On 01/12/2015 04:17 AM, Ian Jackson wrote:
>>> Are there tools parts to come later ?
>>
>> I copied you because get_maintainer picked you. There is scope for
Ed White writes ("Re: [PATCH 00/11] Alternate p2m: support multiple copies of
host p2m"):
> On 01/12/2015 04:17 AM, Ian Jackson wrote:
> > Are there tools parts to come later ?
>
> I copied you because get_maintainer picked you. There is scope for tools
> parts, but I don't have the relevant subj
On 01/12/2015 04:17 AM, Ian Jackson wrote:
> Ed White writes ("[PATCH 00/11] Alternate p2m: support multiple copies of
> host p2m"):
>> This set of patches adds support to hvm domains for EPTP switching
>> by creating multiple copies of the host p2m (currently limited to 10
>> copies).
>
> Thanks
On 01/12/2015 02:00 AM, Jan Beulich wrote:
On 10.01.15 at 00:04, wrote:
>> On 01/09/2015 02:41 PM, Andrew Cooper wrote:
>>> Having some non-OS part of the guest swap the EPT tables and
>>> accidentally turn a DMA buffer read-only is not going to end well.
>>>
>>
>> The agent can certainly do
Ed White writes ("[PATCH 00/11] Alternate p2m: support multiple copies of host
p2m"):
> This set of patches adds support to hvm domains for EPTP switching
> by creating multiple copies of the host p2m (currently limited to 10
> copies).
Thanks for this. Did you CC me in my capacity as tools main
>>> On 10.01.15 at 00:04, wrote:
> On 01/09/2015 02:41 PM, Andrew Cooper wrote:
>> Having some non-OS part of the guest swap the EPT tables and
>> accidentally turn a DMA buffer read-only is not going to end well.
>>
>
> The agent can certainly do bad things, and at some level you have to assume
On 01/09/2015 02:41 PM, Andrew Cooper wrote:
> On 09/01/2015 22:21, Ed White wrote:
>> On 01/09/2015 02:06 PM, Andrew Cooper wrote:
>>> On 09/01/2015 21:26, Ed White wrote:
This set of patches adds support to hvm domains for EPTP switching by
creating
multiple copies of the host p2m
On 09/01/2015 22:21, Ed White wrote:
> On 01/09/2015 02:06 PM, Andrew Cooper wrote:
>> On 09/01/2015 21:26, Ed White wrote:
>>> This set of patches adds support to hvm domains for EPTP switching by
>>> creating
>>> multiple copies of the host p2m (currently limited to 10 copies).
>>>
>>> The prima
On 01/09/2015 02:06 PM, Andrew Cooper wrote:
> On 09/01/2015 21:26, Ed White wrote:
>> This set of patches adds support to hvm domains for EPTP switching by
>> creating
>> multiple copies of the host p2m (currently limited to 10 copies).
>>
>> The primary use of this capability is expected to be i
On 09/01/2015 21:26, Ed White wrote:
> This set of patches adds support to hvm domains for EPTP switching by creating
> multiple copies of the host p2m (currently limited to 10 copies).
>
> The primary use of this capability is expected to be in scenarios where access
> to memory needs to be monito
This set of patches adds support to hvm domains for EPTP switching by creating
multiple copies of the host p2m (currently limited to 10 copies).
The primary use of this capability is expected to be in scenarios where access
to memory needs to be monitored and/or restricted below the level at which
68 matches
Mail list logo
