On Thu, Apr 27, 2017 at 1:00 PM, Boris Ostrovsky
wrote:
> On 04/27/2017 12:46 PM, Andy Lutomirski wrote:
>> On Thu, Apr 27, 2017 at 6:21 AM, Boris Ostrovsky
>> wrote:
Also, this code in drop_other_mm_ref() looks dubious to me:
/* If this cpu still has a stale cr3 re
On 04/27/2017 12:46 PM, Andy Lutomirski wrote:
> On Thu, Apr 27, 2017 at 6:21 AM, Boris Ostrovsky
> wrote:
>>> Also, this code in drop_other_mm_ref() looks dubious to me:
>>>
>>> /* If this cpu still has a stale cr3 reference, then make sure
>>>it has been flushed. */
>
On Thu, Apr 27, 2017 at 6:21 AM, Boris Ostrovsky
wrote:
>
>
>> Also, this code in drop_other_mm_ref() looks dubious to me:
>>
>> /* If this cpu still has a stale cr3 reference, then make sure
>>it has been flushed. */
>> if (this_cpu_read(xen_current_cr3) ==
> Also, this code in drop_other_mm_ref() looks dubious to me:
>
> /* If this cpu still has a stale cr3 reference, then make sure
>it has been flushed. */
> if (this_cpu_read(xen_current_cr3) == __pa(mm->pgd))
> load_cr3(swapper_pg_dir);
>
>>
>>> On 27.04.17 at 02:55, wrote:
> The point of CR3 loading here, I believe, is to make sure the hypervisor
> knows that the (v)CPU is no longer using the the mm's cr3 (we are
> loading swapper_pgdir here).
Correct, or else there would still be a non-zero refcount for the
page tables hanging of
* Boris Ostrovsky wrote:
> > xen_mc_issue() does:
> >
> > if ((paravirt_get_lazy_mode() & mode) == 0)
> > xen_mc_flush();
> >
> > I assume the load_cr3() is intended to deal with the case where we're
> > in lazy mode, but we'll still be in lazy mode, right? Or does it
On Wed, Apr 26, 2017 at 5:55 PM, Boris Ostrovsky
wrote:
>
>
> On 04/26/2017 06:49 PM, Andy Lutomirski wrote:
>>
>> On Wed, Apr 26, 2017 at 3:45 PM, Boris Ostrovsky
>> wrote:
>>>
>>> On 04/26/2017 04:52 PM, Andy Lutomirski wrote:
I was trying to understand xen_drop_mm_ref() to update it
On 04/26/2017 06:49 PM, Andy Lutomirski wrote:
On Wed, Apr 26, 2017 at 3:45 PM, Boris Ostrovsky
wrote:
On 04/26/2017 04:52 PM, Andy Lutomirski wrote:
I was trying to understand xen_drop_mm_ref() to update it for some
changes I'm working on, and I'm wondering whether we need
xen_exit_mmap() a
On Wed, Apr 26, 2017 at 3:45 PM, Boris Ostrovsky
wrote:
> On 04/26/2017 04:52 PM, Andy Lutomirski wrote:
>> I was trying to understand xen_drop_mm_ref() to update it for some
>> changes I'm working on, and I'm wondering whether we need
>> xen_exit_mmap() at all.
>>
>> AFAICS the intent is to force
On 04/26/2017 04:52 PM, Andy Lutomirski wrote:
> I was trying to understand xen_drop_mm_ref() to update it for some
> changes I'm working on, and I'm wondering whether we need
> xen_exit_mmap() at all.
>
> AFAICS the intent is to force all CPUs to drop their lazy uses of the
> mm being destroyed so
I was trying to understand xen_drop_mm_ref() to update it for some
changes I'm working on, and I'm wondering whether we need
xen_exit_mmap() at all.
AFAICS the intent is to force all CPUs to drop their lazy uses of the
mm being destroyed so it can be unpinned before tearing down the page
tables, t
11 matches
Mail list logo
