xen-devel.lists.xenproject.org archive mirror
 help / color / mirror / Atom feed
From: Paul Durrant <Paul.Durrant@citrix.com>
To: Jan Beulich <JBeulich@suse.com>
Cc: Wei Liu <wei.liu2@citrix.com>,
	Andrew Cooper <Andrew.Cooper3@citrix.com>,
	"Tim (Xen.org)" <tim@xen.org>,
	George Dunlap <George.Dunlap@citrix.com>,
	Ian Jackson <Ian.Jackson@citrix.com>,
	"xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>,
	Daniel De Graaf <dgdegra@tycho.nsa.gov>
Subject: Re: [PATCH v2 3/8] dm_op: convert HVMOP_track_dirty_vram
Date: Thu, 15 Dec 2016 16:23:49 +0000	[thread overview]
Message-ID: <861f248f6a204d6ea52d6de261a3c046@AMSPEX02CL03.citrite.net> (raw)
In-Reply-To: <5852C8880200007800129BD9@prv-mh.provo.novell.com>

> -----Original Message-----
> From: Jan Beulich [mailto:JBeulich@suse.com]
> Sent: 15 December 2016 15:45
> To: Paul Durrant <Paul.Durrant@citrix.com>
> Cc: Andrew Cooper <Andrew.Cooper3@citrix.com>; Wei Liu
> <wei.liu2@citrix.com>; George Dunlap <George.Dunlap@citrix.com>; Ian
> Jackson <Ian.Jackson@citrix.com>; xen-devel@lists.xenproject.org; Daniel
> De Graaf <dgdegra@tycho.nsa.gov>; Tim (Xen.org) <tim@xen.org>
> Subject: Re: [PATCH v2 3/8] dm_op: convert HVMOP_track_dirty_vram
> 
> >>> On 06.12.16 at 14:46, <paul.durrant@citrix.com> wrote:
> > @@ -68,6 +70,35 @@ static int
> copy_buf_to_guest(XEN_GUEST_HANDLE_PARAM(xen_dm_op_buf_t)
> bufs,
> >      return copy_to_guest(buf.h, src, size) ? -EFAULT : 0;
> >  }
> >
> > +static int track_dirty_vram(struct domain *d,
> > +                            unsigned int nr_bufs,
> > +                            XEN_GUEST_HANDLE_PARAM(xen_dm_op_buf_t) bufs,
> > +                            xen_pfn_t first_pfn, unsigned int nr)
> > +{
> > +    struct xen_dm_op_buf buf;
> > +    int rc;
> > +
> > +    if ( nr > (GB(1) >> PAGE_SHIFT) )
> > +        return -EINVAL;
> > +
> > +    if ( d->is_dying )
> > +        return -ESRCH;
> > +
> > +    if ( !d->vcpu || !d->vcpu[0] )
> 
> It may not have been this patch, but I think we had settled on the left
> side here wanting to be !d->max_vcpus for consistency with other
> (modern) code.

Oh sorry, I must have missed that.

> 
> > --- a/xen/arch/x86/mm/hap/hap.c
> > +++ b/xen/arch/x86/mm/hap/hap.c
> > @@ -68,7 +68,7 @@
> >  int hap_track_dirty_vram(struct domain *d,
> >                           unsigned long begin_pfn,
> >                           unsigned long nr,
> > -                         XEN_GUEST_HANDLE_64(uint8) guest_dirty_bitmap)
> > +                         XEN_GUEST_HANDLE_PARAM(void) guest_dirty_bitmap)
> >  {
> >      long rc = 0;
> >      struct sh_dirty_vram *dirty_vram;
> > --- a/xen/arch/x86/mm/shadow/common.c
> > +++ b/xen/arch/x86/mm/shadow/common.c
> > @@ -3677,7 +3677,7 @@ static void sh_clean_dirty_bitmap(struct domain
> *d)
> >  int shadow_track_dirty_vram(struct domain *d,
> >                              unsigned long begin_pfn,
> >                              unsigned long nr,
> > -                            XEN_GUEST_HANDLE_64(uint8) guest_dirty_bitmap)
> > +                            XEN_GUEST_HANDLE_PARAM(void) guest_dirty_bitmap)
> >  {
> >      int rc = 0;
> >      unsigned long end_pfn = begin_pfn + nr;
> > --- a/xen/include/asm-x86/hap.h
> > +++ b/xen/include/asm-x86/hap.h
> > @@ -43,7 +43,7 @@ void  hap_vcpu_init(struct vcpu *v);
> >  int   hap_track_dirty_vram(struct domain *d,
> >                             unsigned long begin_pfn,
> >                             unsigned long nr,
> > -                           XEN_GUEST_HANDLE_64(uint8) dirty_bitmap);
> > +                           XEN_GUEST_HANDLE_PARAM(void) dirty_bitmap);
> >
> >  extern const struct paging_mode *hap_paging_get_mode(struct vcpu *);
> >  int hap_set_allocation(struct domain *d, unsigned int pages, bool
> *preempted);
> > --- a/xen/include/asm-x86/shadow.h
> > +++ b/xen/include/asm-x86/shadow.h
> > @@ -63,7 +63,7 @@ int shadow_enable(struct domain *d, u32 mode);
> >  int shadow_track_dirty_vram(struct domain *d,
> >                              unsigned long first_pfn,
> >                              unsigned long nr,
> > -                            XEN_GUEST_HANDLE_64(uint8) dirty_bitmap);
> > +                            XEN_GUEST_HANDLE_PARAM(void) dirty_bitmap);
> 
> I think all of these will go away with the type change required in the
> earlier patch.
> 

Yes, they probably will.

> With all of this taken care of, hypervisor parts
> Reviewed-by: Jan Beulich <jbeulich@suse.com>
> 

Thanks,

  Paul

> Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

  reply	other threads:[~2016-12-15 16:26 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-12-06 13:46 [PATCH v2 0/8] New hypercall for device models Paul Durrant
2016-12-06 13:46 ` [PATCH v2 1/8] public / x86: Introduce __HYPERCALL_dm_op Paul Durrant
2016-12-12 13:27   ` Wei Liu
2016-12-15 15:22   ` Jan Beulich
2016-12-15 15:55     ` Paul Durrant
2016-12-06 13:46 ` [PATCH v2 2/8] dm_op: convert HVMOP_*ioreq_server* Paul Durrant
2016-12-12 13:30   ` Wei Liu
2016-12-15 15:37   ` Jan Beulich
2016-12-06 13:46 ` [PATCH v2 3/8] dm_op: convert HVMOP_track_dirty_vram Paul Durrant
2016-12-15 15:44   ` Jan Beulich
2016-12-15 16:23     ` Paul Durrant [this message]
2016-12-06 13:46 ` [PATCH v2 4/8] dm_op: convert HVMOP_set_pci_intx_level, HVMOP_set_isa_irq_level, and Paul Durrant
2016-12-15 15:51   ` Jan Beulich
2016-12-06 13:46 ` [PATCH v2 5/8] dm_op: convert HVMOP_modified_memory Paul Durrant
2016-12-15 16:05   ` Jan Beulich
2016-12-15 16:25     ` Paul Durrant
2016-12-06 13:46 ` [PATCH v2 6/8] dm_op: convert HVMOP_set_mem_type Paul Durrant
2016-12-15 16:11   ` Jan Beulich
2016-12-06 13:46 ` [PATCH v2 7/8] dm_op: convert HVMOP_inject_trap and HVMOP_inject_msi Paul Durrant
2016-12-15 16:23   ` Jan Beulich
2016-12-15 16:32     ` Paul Durrant
2016-12-06 13:46 ` [PATCH v2 8/8] x86/hvm: serialize trap injecting producer and consumer Paul Durrant

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=861f248f6a204d6ea52d6de261a3c046@AMSPEX02CL03.citrite.net \
    --to=paul.durrant@citrix.com \
    --cc=Andrew.Cooper3@citrix.com \
    --cc=George.Dunlap@citrix.com \
    --cc=Ian.Jackson@citrix.com \
    --cc=JBeulich@suse.com \
    --cc=dgdegra@tycho.nsa.gov \
    --cc=tim@xen.org \
    --cc=wei.liu2@citrix.com \
    --cc=xen-devel@lists.xenproject.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).