Re: [PATCH v7 4/5] ix86/ioreq server: Asynchronously reset outstanding p2m_ioreq_server entries.

[Yu Zhang <yu.c.zhang@linux.intel.com>]

On 3/14/2017 9:11 PM, Jan Beulich wrote:
>>>> On 14.03.17 at 13:18, <yu.c.zhang@linux.intel.com> wrote:
>> On 3/14/2017 6:49 PM, Jan Beulich wrote:
>>>>>> On 14.03.17 at 08:42, <yu.c.zhang@linux.intel.com> wrote:
>>>> On 3/13/2017 7:24 PM, Jan Beulich wrote:
>>>>>>>> On 11.03.17 at 09:42, <yu.c.zhang@linux.intel.com> wrote:
>>>>>> On 3/11/2017 12:03 AM, Jan Beulich wrote:
>>>>>>> But there's a wider understanding issue I'm having here: What is
>>>>>>> an "entry" here? Commonly I would assume this to refer to an
>>>>>>> individual (4k) page, but it looks like you really mean table entry,
>>>>>>> i.e. possibly representing a 2M or 1G page.
>>>>>> Well, it should be an entry pointing to a 4K page(only).
>>>>>> For p2m_ioreq_server, we shall not meet huge page. Because they are
>>>>>> changed from p2m_ram_rw pages
>>>>>> in set_mem_type() -> p2m_change_type_one(), which calls p2m_set_entry()
>>>>>> with PAGE_ORDER_4K specified.
>>>>> And recombination of large pages won't ever end up hitting these?
>>>> Well, by recombination I guess you refer to the POD pages? I do not
>>>> think p2m_ioreq_server
>>>> pages will be combined now, which means we do not need to worry about
>>>> recounting the
>>>> p2m_ioreq_server entries while a split happens.
>>> No, I didn't think about PoD here. But indeed I was misremembering:
>>> We don't currently make any attempt to transparently recreate large
>>> pages.
>> Thanks Jan. So do you now think the current counting logic for
>> p2m_ioreq_server is correct? :-)
> Yes. But please make sure you mention the 4k page dependency
> at least in the commit message.

OK. Will do.

Thanks
Yu
> Jan
>
>


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel