From: Razvan Cojocaru <rcojocaru@bitdefender.com>
To: Jan Beulich <JBeulich@suse.com>,
George Dunlap <George.Dunlap@eu.citrix.com>
Cc: Andrew Cooper <andrew.cooper3@citrix.com>,
xen-devel <xen-devel@lists.xenproject.org>,
Wei Liu <wei.liu2@citrix.com>,
george.dunlap@citrix.com, Roger Pau Monne <roger.pau@citrix.com>
Subject: Re: [PATCH V11 4/5] p2m: Always use hostp2m when clipping rangesets
Date: Thu, 13 Dec 2018 12:22:55 +0200 [thread overview]
Message-ID: <5e22ea77-26f9-be55-c30f-8a598cd35218@bitdefender.com> (raw)
In-Reply-To: <5C07FD4302000078002033AF@prv1-mh.provo.novell.com>
On 12/5/18 6:30 PM, Jan Beulich wrote:
>>>> On 05.12.18 at 10:18, <rcojocaru@bitdefender.com> wrote:
>> --- a/xen/arch/x86/mm/p2m.c
>> +++ b/xen/arch/x86/mm/p2m.c
>> @@ -1002,30 +1002,43 @@ int p2m_change_type_one(struct domain *d, unsigned long gfn_l,
>> return rc;
>> }
>>
>> -/* Modify the p2m type of a range of gfns from ot to nt. */
>> +/* Modify the p2m type of [start, end) from ot to nt. */
>> static void change_type_range(struct p2m_domain *p2m,
>> unsigned long start, unsigned long end,
>> p2m_type_t ot, p2m_type_t nt)
>> {
>> - unsigned long gfn = start;
>> struct domain *d = p2m->domain;
>> + const unsigned long host_max_pfn = p2m_get_hostp2m(d)->max_mapped_pfn;
>> int rc = 0;
>>
>> - if ( unlikely(end > p2m->max_mapped_pfn) )
>> - {
>> - if ( !gfn )
>> - {
>> - p2m->change_entry_type_global(p2m, ot, nt);
>> - gfn = end;
>> - }
>> - end = p2m->max_mapped_pfn + 1;
>> - }
>> - if ( gfn < end )
>> - rc = p2m->change_entry_type_range(p2m, ot, nt, gfn, end - 1);
>> + --end;
>> +
>> + if ( start >= host_max_pfn )
>> + printk(XENLOG_G_WARNING "Dom%d logdirty rangeset clipped to max_mapped_pfn\n",
>> + d->domain_id);
>> +
>> + /* Always clip the rangeset down to the host p2m. */
>> + if ( unlikely(end > host_max_pfn) )
>> + end = host_max_pfn;
>> +
>> + /* If the requested range is out of scope, return doing nothing. */
>> + if ( start > end )
>> + return;
>
> My prior comment remains: Even if there's no change in behavior
> (and you avoid the assertion), especially due to the comment the
> impression results (at least to me) that all is well here, when it
> really is a (latent) bug to "do nothing" in this case. George, so far
> this was a discussion between Razvan and me - do you have an
> opinion either way here?
Obviously I can't speak for George, but to reiterate my previous
analysis, it looks like this patch has added the clipping:
http://xenbits.xen.org/gitweb/?p=xen.git;a=commitdiff;h=437f54d3a33d3787a7cc485eb2b3451e8be49ca7
and this patch has added the global_logdirty ranges code:
http://xenbits.xen.org/gitweb/?p=xen.git;a=commitdiff;h=90ac32559bfbd08127638ba13f99b5ed565cfc2b
but left the clipping code in (possibly accidentally). You may have some
insight into that, being their author, although it's been a few years
since then.
For my own part, I see no reason why not clipping end should not work
when updating the ranges only (as long as start continues to be <=
unclipped_end).
Would that modification + testing of it help this series continue?
Thanks,
Razvan
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
next prev parent reply other threads:[~2018-12-13 10:23 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-12-05 9:18 [PATCH V11 0/5] Fix VGA logdirty related display freezes with altp2m Razvan Cojocaru
2018-12-05 9:18 ` [PATCH V11 1/5] x86/p2m: allocate logdirty_ranges for altp2ms Razvan Cojocaru
2018-12-05 9:18 ` [PATCH V11 2/5] x86/p2m: refactor p2m_reset_altp2m() Razvan Cojocaru
2018-12-05 9:18 ` [PATCH V11 3/5] x86/altp2m: fix display frozen when switching to a new view early Razvan Cojocaru
2018-12-20 15:31 ` George Dunlap
2018-12-05 9:18 ` [PATCH V11 4/5] p2m: Always use hostp2m when clipping rangesets Razvan Cojocaru
2018-12-05 16:30 ` Jan Beulich
2018-12-13 10:22 ` Razvan Cojocaru [this message]
2018-12-13 10:43 ` Jan Beulich
2018-12-19 17:26 ` George Dunlap
2018-12-20 8:20 ` Jan Beulich
2018-12-20 12:59 ` George Dunlap
2018-12-20 13:52 ` Jan Beulich
2018-12-20 14:38 ` George Dunlap
2018-12-20 14:49 ` Jan Beulich
2018-12-20 15:14 ` Razvan Cojocaru
2018-12-20 15:22 ` George Dunlap
2018-12-20 15:01 ` Jan Beulich
2018-12-20 16:09 ` George Dunlap
2018-12-20 16:25 ` Razvan Cojocaru
2018-12-20 16:31 ` George Dunlap
2018-12-20 16:46 ` Razvan Cojocaru
2018-12-05 9:18 ` [PATCH V11 5/5] p2m: change_type_range: Only invalidate mapped gfns Razvan Cojocaru
2018-12-20 16:17 ` George Dunlap
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=5e22ea77-26f9-be55-c30f-8a598cd35218@bitdefender.com \
--to=rcojocaru@bitdefender.com \
--cc=George.Dunlap@eu.citrix.com \
--cc=JBeulich@suse.com \
--cc=andrew.cooper3@citrix.com \
--cc=george.dunlap@citrix.com \
--cc=roger.pau@citrix.com \
--cc=wei.liu2@citrix.com \
--cc=xen-devel@lists.xenproject.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).