On Thu, Dec 11, David Vrabel wrote:
> Nothing special needs to be done with ballooned pages. If frames are
> not populated in the original domain, they will be unpopulated in the
> new domain.
>
> It's the responsibility of the guest to ensure it either doesn't kexec
> when it is ballooned or th
On 11/12/14 14:24, Olaf Hering wrote:
> On Wed, Dec 03, Vitaly Kuznetsov wrote:
>
>> When a PVHVM linux guest performs kexec there are lots of things which
>> require taking care of:
>> - shared info, vcpu_info
>> - grants
>> - event channels
>> - ...
>> Instead of taking care of all these things
On Wed, Dec 03, Vitaly Kuznetsov wrote:
> When a PVHVM linux guest performs kexec there are lots of things which
> require taking care of:
> - shared info, vcpu_info
> - grants
> - event channels
> - ...
> Instead of taking care of all these things we can rebuild the domain
> performing kexec from
On Thu, Dec 04, 2014 at 03:46:59PM +0100, Vitaly Kuznetsov wrote:
> Wei Liu writes:
>
> > On Wed, Dec 03, 2014 at 06:16:12PM +0100, Vitaly Kuznetsov wrote:
> >> Changes from RFCv3:
> >> This is the first non-RFC series as no major concerns were expressed. I'm
> >> trying
> >> to address Jan's co
Wei Liu writes:
> On Wed, Dec 03, 2014 at 06:16:12PM +0100, Vitaly Kuznetsov wrote:
>> Changes from RFCv3:
>> This is the first non-RFC series as no major concerns were expressed. I'm
>> trying
>> to address Jan's comments. Changes are:
>> - Move from XEN_DOMCTL_set_recipient to XEN_DOMCTL_devou
Olaf Hering writes:
> On Wed, Dec 03, Vitaly Kuznetsov wrote:
>
>> Original description:
>>
>> When a PVHVM linux guest performs kexec there are lots of things which
>> require taking care of:
>> - shared info, vcpu_info
>> - grants
>> - event channels
>> - ...
>> Instead of taking care of all t
On Wed, Dec 03, 2014 at 06:16:12PM +0100, Vitaly Kuznetsov wrote:
> Changes from RFCv3:
> This is the first non-RFC series as no major concerns were expressed. I'm
> trying
> to address Jan's comments. Changes are:
> - Move from XEN_DOMCTL_set_recipient to XEN_DOMCTL_devour (I don't really like
>
On Wed, Dec 03, Vitaly Kuznetsov wrote:
> Original description:
>
> When a PVHVM linux guest performs kexec there are lots of things which
> require taking care of:
> - shared info, vcpu_info
> - grants
> - event channels
> - ...
> Instead of taking care of all these things we can rebuild the dom
Changes from RFCv3:
This is the first non-RFC series as no major concerns were expressed. I'm trying
to address Jan's comments. Changes are:
- Move from XEN_DOMCTL_set_recipient to XEN_DOMCTL_devour (I don't really like
the name but nothing more appropriate came to my mind) which incorporates
f
