Re: [Xen-devel] PML (Page Modification Logging) design for Xen

[George Dunlap <George.Dunlap@xxxxxxxxxxxxx>]

On Wed, Mar 11, 2015 at 11:11 AM, Andrew Cooper
<andrew.cooper3@xxxxxxxxxx> wrote:
> On 11/03/15 10:59, George Dunlap wrote:
>> On Tue, Feb 17, 2015 at 10:19 AM, Jan Beulich <JBeulich@xxxxxxxx> wrote:
>>>>>> On 12.02.15 at 03:39, <kai.huang@xxxxxxxxxxxxxxx> wrote:
>>>> On 02/11/2015 07:52 PM, Andrew Cooper wrote:
>>>>> On 11/02/15 08:28, Kai Huang wrote:
>>>>>> Design
>>>>>> ======
>>>>>>
>>>>>> - PML feature is used globally
>>>>>>
>>>>>> A new Xen boot parameter, say 'opt_enable_pml', will be introduced to
>>>>>> control PML feature detection, and PML feature will only be detected
>>>>>> if opt_enable_pml = 1. Once PML feature is detected, it will be used
>>>>>> for dirty logging for all domains globally. Currently we don't support
>>>>>> to use PML on basis of per-domain as it will require additional
>>>>>> control from XL tool.
>>>>> Rather than adding in a new top level command line option for an ept
>>>>> subfeature, it would be preferable to add an "ept=" option which has
>>>>> "pml" as a sub boolean.
>>>> Which is good to me, if Jan agrees.
>>>>
>>>> Jan, which do you prefer here?
>>> A single "ept=" option as Andrew suggested.
>> Sorry to be coming late to this party -- what's the logic behind
>> having this enabled with "ept="? You're not changing anything about
>> how EPT itself works; you're adding a secondary feature which happens
>> to depend on ept.  Is there another hypervisor command-line option you
>> had in mind that works this way?
>
> iommu=

Every option in iommu actually changes something about the way the
IOMMU actually works.  Analogous options for ept might be enabling /
disabling, setting a maximum entry size (1G, 2M, 4k), enabling the
no-execute bit, &c.

AFAICT PMT is a completely separate functionality.  Enabling it as an
option behind ept would be like saying you should enable BTS
(branch-trace-store) behind an option called "mmu=", since the
addresses in the BTS go through the MMU.

That's my $0.02 anyway...

>
>>
>> It might also be nice to be able to enable or disable this feature
>> with a sysctl call; but that's just a nice-to-have.
>
> This feature should either be used or not.  It is impractical to
> enable/disable at runtime.
>
> However, it absolutely wants a knob for tweaking.  The likely
> consequence of a bug in the implementation is VM memory corruption on
> migrate, and you can get away with missing a large amount of a domains
> memory before it blows up noticeably.

Those paragraphs sound to me like they say the opposite things.

And in any case, it's being enabled and disabled for particular
domains when they enable or disable logdirty mode, right?  It
shouldn't be hard at all to just fallback to the non-PML case if it's
been disabled.

Handling the case of enabling or disabling PML on domains that are
already in logdirty mode is, I agree, probably more trouble than it's
worth.  We can just document it to say that it will only have an
effect on domains that start logdirty in the future.

 -George

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