On Thu, Feb 09, 2017 at 03:10:10AM -0700, Jan Beulich wrote:
> >>> On 07.02.17 at 18:35, wrote:
> > @@ -3178,9 +3179,9 @@ static enum hvm_copy_result __hvm_copy(
> > {
> > static unsigned long lastpage;
> > if ( xchg(&lastpage, gfn) != gfn )
> > -
>>> On 07.02.17 at 18:35, wrote:
> @@ -3178,9 +3179,9 @@ static enum hvm_copy_result __hvm_copy(
> {
> static unsigned long lastpage;
> if ( xchg(&lastpage, gfn) != gfn )
> -gdprintk(XENLOG_DEBUG, "guest attempted write to
> read-
> From: Jan Beulich [mailto:jbeul...@suse.com]
> Sent: Wednesday, February 08, 2017 9:37 PM
>
> >>> On 07.02.17 at 18:35, wrote:
> > Current __hvm_copy assumes that the destination memory belongs to the
> > current
> > vcpu, but this is not always the case since for PVHv2 Dom0 build hvm copy
> >
>>> On 07.02.17 at 18:35, wrote:
> Current __hvm_copy assumes that the destination memory belongs to the current
> vcpu, but this is not always the case since for PVHv2 Dom0 build hvm copy
> functions are used with current being the idle vcpu. Add a new vcpu
> parameter
> to hvm copy in order to
>>> On 07.02.17 at 18:35, wrote:
> Current __hvm_copy assumes that the destination memory belongs to the current
> vcpu, but this is not always the case since for PVHv2 Dom0 build hvm copy
> functions are used with current being the idle vcpu. Add a new vcpu parameter
> to hvm copy in order to sol
Current __hvm_copy assumes that the destination memory belongs to the current
vcpu, but this is not always the case since for PVHv2 Dom0 build hvm copy
functions are used with current being the idle vcpu. Add a new vcpu parameter
to hvm copy in order to solve that. Note that only hvm_copy_to_guest_
