On Fri, Apr 5, 2019 at 1:36 AM Jan Beulich wrote:
>
> >>> On 04.04.19 at 16:54, wrote:
> >> On Apr 4, 2019, at 3:36 PM, Jan Beulich wrote:
> > On 04.04.19 at 15:09, wrote:
> >>> I agree that it is confusing. It would be fine to UNSHARE here as well
> >>> to keep things consistent but otherw
>>> On 04.04.19 at 16:54, wrote:
>> On Apr 4, 2019, at 3:36 PM, Jan Beulich wrote:
> On 04.04.19 at 15:09, wrote:
>>> I agree that it is confusing. It would be fine to UNSHARE here as well
>>> to keep things consistent but otherwise it's not really an issue as
>>> the entry type is checked l
On Thu, Apr 4, 2019 at 8:51 AM Jan Beulich wrote:
>
> >>> On 04.04.19 at 16:43, wrote:
> > On Thu, Apr 4, 2019 at 8:36 AM Jan Beulich wrote:
> >>
> >> >>> On 04.04.19 at 15:09, wrote:
> >> > I agree that it is confusing. It would be fine to UNSHARE here as well
> >> > to keep things consistent
> On Apr 4, 2019, at 3:36 PM, Jan Beulich wrote:
>
On 04.04.19 at 15:09, wrote:
>> I agree that it is confusing. It would be fine to UNSHARE here as well
>> to keep things consistent but otherwise it's not really an issue as
>> the entry type is checked later to ensure that this is a p2m_
>>> On 04.04.19 at 16:43, wrote:
> On Thu, Apr 4, 2019 at 8:36 AM Jan Beulich wrote:
>>
>> >>> On 04.04.19 at 15:09, wrote:
>> > I agree that it is confusing. It would be fine to UNSHARE here as well
>> > to keep things consistent but otherwise it's not really an issue as
>> > the entry type is
On Thu, Apr 4, 2019 at 8:36 AM Jan Beulich wrote:
>
> >>> On 04.04.19 at 15:09, wrote:
> > I agree that it is confusing. It would be fine to UNSHARE here as well
> > to keep things consistent but otherwise it's not really an issue as
> > the entry type is checked later to ensure that this is a p2
>>> On 04.04.19 at 15:09, wrote:
> I agree that it is confusing. It would be fine to UNSHARE here as well
> to keep things consistent but otherwise it's not really an issue as
> the entry type is checked later to ensure that this is a p2m_ram_rw
> entry. We are simply trying to keep mem_sharing an
>>> On 04.04.19 at 14:50, wrote:
> On 4/4/19 3:46 PM, Razvan Cojocaru wrote:
>> Before going into that, are we now certain that ALLOC is sufficient? I
>> believe it should be for _our_ use-cases, but we don't want to break
>> anyone's code. Maybe Tamas knows more about this.
>
> Sorry, I forgot
On Thu, Apr 4, 2019 at 6:49 AM Andrew Cooper wrote:
>
> On 04/04/2019 13:46, Razvan Cojocaru wrote:
> > On 4/3/19 6:30 PM, Jan Beulich wrote:
> > On 03.04.19 at 17:17, wrote:
> >>> On 4/3/19 5:58 PM, Jan Beulich wrote:
> >>> On 03.04.19 at 16:29, wrote:
> > --- a/xen/arch/x86/mm/p2m.
On Thu, Apr 4, 2019 at 6:50 AM Razvan Cojocaru
wrote:
>
> On 4/4/19 3:46 PM, Razvan Cojocaru wrote:
> > On 4/3/19 6:30 PM, Jan Beulich wrote:
> > On 03.04.19 at 17:17, wrote:
> >>> On 4/3/19 5:58 PM, Jan Beulich wrote:
> >>> On 03.04.19 at 16:29, wrote:
> > --- a/xen/arch/x86/mm/p2m.
On 4/4/19 3:46 PM, Razvan Cojocaru wrote:
On 4/3/19 6:30 PM, Jan Beulich wrote:
On 03.04.19 at 17:17, wrote:
On 4/3/19 5:58 PM, Jan Beulich wrote:
On 03.04.19 at 16:29, wrote:
--- a/xen/arch/x86/mm/p2m.c
+++ b/xen/arch/x86/mm/p2m.c
@@ -3011,8 +3011,16 @@ int p2m_set_suppress_ve(struct domai
On 04/04/2019 13:46, Razvan Cojocaru wrote:
> On 4/3/19 6:30 PM, Jan Beulich wrote:
> On 03.04.19 at 17:17, wrote:
>>> On 4/3/19 5:58 PM, Jan Beulich wrote:
>>> On 03.04.19 at 16:29, wrote:
> --- a/xen/arch/x86/mm/p2m.c
> +++ b/xen/arch/x86/mm/p2m.c
> @@ -3011,8 +3011,16 @@ in
On 4/3/19 6:30 PM, Jan Beulich wrote:
On 03.04.19 at 17:17, wrote:
On 4/3/19 5:58 PM, Jan Beulich wrote:
On 03.04.19 at 16:29, wrote:
--- a/xen/arch/x86/mm/p2m.c
+++ b/xen/arch/x86/mm/p2m.c
@@ -3011,8 +3011,16 @@ int p2m_set_suppress_ve(struct domain *d, gfn_t gfn,
bool suppress_ve,
>>> On 03.04.19 at 19:41, wrote:
> On 4/3/19 7:04 PM, Jan Beulich wrote:
> On 03.04.19 at 17:48, wrote:
>>> On 4/3/19 6:30 PM, Jan Beulich wrote:
>>> On 03.04.19 at 17:17, wrote:
> Changes to the hostp2m (also known as altp2m view 0) propagate to all
> existing altp2ms, but they
>>> On 03.04.19 at 18:16, wrote:
> On Wed, Apr 3, 2019 at 10:06 AM Jan Beulich wrote:
>> Then I still don't see why you would want to force propagation
>> in these cases: If it's generally demand-populate, it can't be right
>> to _fully_ populate that slot. You ought to be setting the access
>> t
On 4/3/19 7:04 PM, Jan Beulich wrote:
On 03.04.19 at 17:48, wrote:
>> On 4/3/19 6:30 PM, Jan Beulich wrote:
>> On 03.04.19 at 17:17, wrote:
Changes to the hostp2m (also known as altp2m view 0) propagate to all
existing altp2ms, but they do so in a lazy manner, and also that won
On Wed, Apr 3, 2019 at 11:08 AM Razvan Cojocaru
wrote:
>
> On 4/3/19 7:16 PM, Tamas K Lengyel wrote:
> > It is right to fully populate a slot when for example we want
> > different mem_access permissions in different altp2m views. We can't
> > wait for the domain to on-demand populate the altp2m v
On 4/3/19 7:16 PM, Tamas K Lengyel wrote:
> It is right to fully populate a slot when for example we want
> different mem_access permissions in different altp2m views. We can't
> wait for the domain to on-demand populate the altp2m view because we
> don't know when (and if) that will actually happe
On Wed, Apr 3, 2019 at 10:06 AM Jan Beulich wrote:
>
> >>> On 03.04.19 at 17:48, wrote:
> > On 4/3/19 6:30 PM, Jan Beulich wrote:
> > On 03.04.19 at 17:17, wrote:
> >>> Changes to the hostp2m (also known as altp2m view 0) propagate to all
> >>> existing altp2ms, but they do so in a lazy mann
>>> On 03.04.19 at 17:48, wrote:
> On 4/3/19 6:30 PM, Jan Beulich wrote:
> On 03.04.19 at 17:17, wrote:
>>> Changes to the hostp2m (also known as altp2m view 0) propagate to all
>>> existing altp2ms, but they do so in a lazy manner, and also that won't
>>> happen for altp2ms created after a w
On 4/3/19 6:30 PM, Jan Beulich wrote:
On 03.04.19 at 17:17, wrote:
Changes to the hostp2m (also known as altp2m view 0) propagate to all
existing altp2ms, but they do so in a lazy manner, and also that won't
happen for altp2ms created after a while. So altp2ms will not
necessarily know about a
>>> On 03.04.19 at 17:17, wrote:
> On 4/3/19 5:58 PM, Jan Beulich wrote:
> On 03.04.19 at 16:29, wrote:
>>> --- a/xen/arch/x86/mm/p2m.c
>>> +++ b/xen/arch/x86/mm/p2m.c
>>> @@ -3011,8 +3011,16 @@ int p2m_set_suppress_ve(struct domain *d, gfn_t gfn,
>>> bool suppress_ve,
>>> mfn = p2m->g
On 4/3/19 5:58 PM, Jan Beulich wrote:
On 03.04.19 at 16:29, wrote:
--- a/xen/arch/x86/mm/p2m.c
+++ b/xen/arch/x86/mm/p2m.c
@@ -3011,8 +3011,16 @@ int p2m_set_suppress_ve(struct domain *d, gfn_t gfn,
bool suppress_ve,
mfn = p2m->get_entry(p2m, gfn, &t, &a, 0, NULL, NULL);
if ( !mfn_
>>> On 03.04.19 at 16:29, wrote:
> --- a/xen/arch/x86/mm/p2m.c
> +++ b/xen/arch/x86/mm/p2m.c
> @@ -3011,8 +3011,16 @@ int p2m_set_suppress_ve(struct domain *d, gfn_t gfn,
> bool suppress_ve,
> mfn = p2m->get_entry(p2m, gfn, &t, &a, 0, NULL, NULL);
> if ( !mfn_valid(mfn) )
> {
> -
On a new altp2m view the p2m_set_suppress_ve() func will fail with invalid mfn
from p2m->get_entry() if the p2m->set_entry() was not called before.
This patch solves the problem by getting the mfn from __get_gfn_type_access()
and then returning error if the mfn is invalid.
Signed-off-by: Alexandr
25 matches
Mail list logo
