[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 me. Jan _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx http://lists.xen.org/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |