> > Provided this is v4 now of the series and no issues
> > were raised so far for these particular patches they can be merged
> > with your Reviewed-by.
>
> I don't think so, under the current (sufficiently) common
> understanding of the rules. See George's proposal to change to a
> model like
On Fri, Jan 17, 2020 at 4:15 AM Anthony PERARD
wrote:
>
> On Fri, Jan 17, 2020 at 10:12:14AM +0100, Jan Beulich wrote:
> > Please note that my previous mail was _to_ George, with you only
> > _cc_-ed. Hence the question was to George, not you. (It is a
> > common issue which I keep mentioning on
On Fri, Jan 17, 2020 at 10:12:14AM +0100, Jan Beulich wrote:
> Please note that my previous mail was _to_ George, with you only
> _cc_-ed. Hence the question was to George, not you. (It is a
> common issue which I keep mentioning on meetings that the
> distinction of To and Cc is often not being
On 16.01.2020 17:24, Tamas K Lengyel wrote:
> On Thu, Jan 16, 2020 at 8:47 AM Jan Beulich wrote:
>>
>> On 08.01.2020 18:13, Tamas K Lengyel wrote:
>>> Tamas K Lengyel (18):
>>> x86/hvm: introduce hvm_copy_context_and_params
>>> xen/x86: Make hap_get_allocation accessible
>>>
On Thu, Jan 16, 2020 at 8:47 AM Jan Beulich wrote:
>
> On 08.01.2020 18:13, Tamas K Lengyel wrote:
> > Tamas K Lengyel (18):
> > x86/hvm: introduce hvm_copy_context_and_params
> > xen/x86: Make hap_get_allocation accessible
> > x86/mem_sharing: make get_two_gfns take locks conditionally
> >
On 08.01.2020 18:13, Tamas K Lengyel wrote:
> Tamas K Lengyel (18):
> x86/hvm: introduce hvm_copy_context_and_params
> xen/x86: Make hap_get_allocation accessible
> x86/mem_sharing: make get_two_gfns take locks conditionally
> x86/mem_sharing: drop flags from mem_sharing_unshare_page
>
The following series implements VM forking for Intel HVM guests to allow for
the fast creation of identical VMs without the assosciated high startup costs
of booting or restoring the VM from a savefile.
JIRA issue: https://xenproject.atlassian.net/browse/XEN-89
The fork operation is implemented
