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

[Tim Deegan <tim@xxxxxxx>]

Hi,

At 22:01 +0800 on 16 Feb (1424120474), Kai Huang wrote:
> On Fri, Feb 13, 2015 at 10:50 AM, Kai Huang <kai.huang@xxxxxxxxxxxxxxx> wrote:
> >
> > On 02/12/2015 08:34 PM, Tim Deegan wrote:
> >>
> >> Hi,
> >>
> >> Thanks for posting this design!
> >>
> >> At 16:28 +0800 on 11 Feb (1423668493), 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.
> >>
> >> Sounds good.  I agree that there's no point in making this a per-VM
> >> feature.
> >>
> >>> - PML enable/disable for particular Domain
> >>>
> >>> PML needs to be enabled (allocate PML buffer, initialize PML index, PML
> >>> base address, turn PML on VMCS, etc) for all vcpus of the domain, as PML
> >>> buffer and PML index are per-vcpu, but EPT table may be shared by vcpus.
> >>> Enabling PML on partial vcpus of the domain won't work. Also PML will only
> >>> be enabled for the domain when it is switched to dirty logging mode, and 
> >>> it
> >>> will be disabled when domain is switched back to normal mode. As looks 
> >>> vcpu
> >>> number won't be changed dynamically during guest is running (correct me 
> >>> if I
> >>> am wrong here), so we don't have to consider enabling PML for new created
> >>> vcpu when guest is in dirty logging mode.
> >>>
> >> No - you really ought to handle enabling this for new VCPUs.  There
> >> have been cases in the past where VMs are put into log-dirty mode
> >> before their VCPUs are assigned, and there might be again.
> >
> > "Assigned" here means created?

Yes.

> >> It ought to be easy to handle, though - just one more check and
> >> function call on the vcpu setup path.
> >
> > I think "check and function call" means check function call to enable PML on
> > this vcpu? Then what if enabling PML for vcpu fails (possible as it needs to
> > allocate 4K PML buffer)? It's better to choose to roll back to use write
> > protection instead of indicating failure of creating the vcpu. But in this
> > case there will be problem if the domain has already been in log dirty mode
> > as we might already have EPT table setup with D-bit clear for logdirty
> > range, which means we need to re-check the logdirty ranges and re-set EPT
> > table to be read-only.  Does this sound reasonable?

If PML init fails for some reason, you can just fail the vcpu
init.  That's what we do for other things, and it avoids having to
deal with a half-PML domain. 

> If my above understanding is true, to me it's a little bit complicated
> to enable PML for domain on demand when it switches to log-dirty mode.
> Another approach is we  enable PML for vcpu unconditionally (if PML
> feature is detected of course) when vcpu is created, and if enabling
> PML failed, vcpu will just  not be created.

Nearly.  You should enable PML on vcpu creation _if_ the VM is
already in log-dirty mode.  If it is not, then do nothing and the
code that enables log-dirty later can set up PML for all existing VCPUs. 

Cheers,

Tim.

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