From mboxrd@z Thu Jan 1 00:00:00 1970 From: Mukesh Rathor Subject: Re: [PATCH 17/18 V2]: PVH xen: PVH dom0 creation... Date: Tue, 26 Mar 2013 17:34:57 -0700 Message-ID: <20130326173457.43722909@mantra.us.oracle.com> References: <20130315180645.59f8618e@mantra.us.oracle.com> <51471E3302000078000C65FD@nat28.tlf.novell.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <51471E3302000078000C65FD@nat28.tlf.novell.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Jan Beulich Cc: xen-devel List-Id: xen-devel@lists.xenproject.org On Mon, 18 Mar 2013 13:01:23 +0000 "Jan Beulich" wrote: > >>> On 16.03.13 at 02:06, Mukesh Rathor > >>> wrote: > > +static __init void copy_pvh(char *dest, char *src, int bytes) > > +{ > > + /* raw_copy_to_guest() -> copy_to_user_hvm -> __hvm_copy needs > > curr > > + * to point to the hvm/pvh vcpu. Hence for PVH dom0 we can't > > use that. > > + * So we just use dbg_rw_mem(). > > + */ > > + int rem = dbg_rw_mem((dbgva_t)dest, (unsigned char *)src, > > bytes, 0, 1, 0); > > Same comment as before: This is not acceptable for a submission > of a patch intended to be committed (i.e. non-RFC). You should > have worked out a suitable solution to this before posting. Well, the prev patch was RFC and I dind't hear anything on this, so (mis) understood this was acceptable. Ok, I will just implmement copy_pvh() here.