Notes from Xen live-update design session

["Gul, Mahircan" <mahgul@xxxxxxxxxxxx>]

Hi all,

## Minutes from Xen live-update design session, 28th May

- The records are applied in Xen2 as if a hypercall was executed. We execute 
the hypercall on behalf of the domain, rather than the domain (i.e. dom0) 
calling the hypercall.
      - "How extensible is that approach? Things will change." As long as 
there's compatibility with future extensions, this is fine.
- One problem with creating domains and vCPUs is: there'll be a set_cpu 
hypercall between domain_create and vcpu_create. Plan is to enforce this as a 
hypercall dependency.
- Reducing the downtime to several hundred milliseconds with a bit of care.
- Potential issues that can arise due to differences between Intel and AMD:
      - Differences between VMCS and SVM.
      - EPT and MPT. Depending on how p2m is handled. However, we transfer it 
as is (pointer to the top) as the pages must be present (devices cannot be 
quiesced). So this must be okay.
      - On AMD, p2m has metadata in different places.
      - For shadow memory, pass p2m just as HVM guests.
- As a first step, it's okay to push the records to upstream even if they won't 
be used immediately. We know the end goal. This aligns with our idea of pushing 
the spec and the record headers first.
- As a follow up, upstream the patches to be able to LU dom0 only.
- IOMMU masking (what we do) is the correct way to proceed.
- As long as interrupts are masked as pending on the event channel, it should 
be okay on the restore side even if the IRQ was in-flight in Xen1.
- A separate monthly call on Xen LU (separate than the monthly call).

--
Mahir