[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] [PATCH v2 3/3] tools: introduce parameter max_wp_ram_ranges.

>>> On 27.01.16 at 16:23, <yu.c.zhang@xxxxxxxxxxxxxxx> wrote:

> On 1/27/2016 11:12 PM, Jan Beulich wrote:
>>>>> On 27.01.16 at 15:56, <yu.c.zhang@xxxxxxxxxxxxxxx> wrote:
>>> On 1/27/2016 10:32 PM, Jan Beulich wrote:
>>>>>>> On 27.01.16 at 15:13, <yu.c.zhang@xxxxxxxxxxxxxxx> wrote:
>>>>> About the truncation issue:
>>>>>      I do not quite follow. Will this hurt if the value configured does
>>>>> not exceed 4G? What about a type cast?
>>>> A typecast would not alter behavior in any way. And of course
>>>> a problem only arises if the value was above 4 billion. You either
>>>> need to refuse such values while the attempt is made to set it.
>>>> or you need to deal with the full range of possible values. Likely
>>>> the former is the better (and I wonder whether the upper
>>>> bound shouldn't be forced even lower than 4 billion).
>>> Oh, I see. A check with the upper bound sounds better. Using 4G as the
>>> upper bound is a little conservative, but I do not have any better
>>> criteria right now. :)
>> But when making that decision keep security in mind: How much
>> memory would it take to populate 4G rangeset nodes?
> Well, for XenGT, one extreme case I can imagine would be half of all
> the guest ram is used as the GPU page table, and page frames containing
> these page tables are discontinuous (rangeset can combine continuous
> ranges). For other virtual devices to leverage the write-protected gfn
> rangeset, I believe the same idea applies. :)
> Is this logic OK?

I can follow it, yes, but 4G ranges mean 16Tb of memory put
in page tables, which to be honest doesn't seem reasonable to


Xen-devel mailing list



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.