All of lore.kernel.org
 help / color / mirror / Atom feed
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Jan Beulich <JBeulich@suse.com>
Cc: george.dunlap@eu.citrix.com,
	xen-devel <xen-devel@lists.xenproject.org>,
	keir.xen@gmail.com, tim@xen.org
Subject: Re: [V7 PATCH 3/7] pvh dom0: implement XENMEM_add_to_physmap_range for x86
Date: Tue, 17 Dec 2013 15:34:06 +0000	[thread overview]
Message-ID: <1387294446.27441.74.camel@kazak.uk.xensource.com> (raw)
In-Reply-To: <52B0779B020000780010E366@nat28.tlf.novell.com>

On Tue, 2013-12-17 at 15:11 +0000, Jan Beulich wrote:
> >>> On 17.12.13 at 15:40, Ian Campbell <Ian.Campbell@citrix.com> wrote:
> > On Tue, 2013-12-17 at 14:36 +0000, Jan Beulich wrote:
> >> >>> On 17.12.13 at 14:59, Ian Campbell <Ian.Campbell@citrix.com> wrote:
> >> > We could change the code but we could also tighten the interface
> >> > requirements, either by explicit specifying that the range is handled in
> >> > reverse order or by mandating that index/gpfn must not be repeated
> >> > (whether or not we actively try and detect such cases).
> >> 
> >> Specifying that this gets processed backwards would be, well,
> >> backwards. Requiring no duplicates (or else getting undefined
> >> behavior) would be possible. But processing the operation in the
> >> conventional order doesn't seem all that hard.
> > 
> > The reason I thought it would be tricky was finding somewhere to stash
> > the progress over the continuation. Do you have a cunning plan?
> 
> Just like we do in other cases - in the struct that was passed to
> us by the caller (incrementing the handles and decrementing the
> count as needed).

Ah right, forgot we were allowed to fiddle with the handle...

  reply	other threads:[~2013-12-17 15:34 UTC|newest]

Thread overview: 52+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-12-17  2:38 [V7 PATCH 0/7]: PVH dom0 Mukesh Rathor
2013-12-17  2:38 ` [V7 PATCH 1/7] pvh dom0: move some pv specific code to static functions Mukesh Rathor
2013-12-17  2:38 ` [V7 PATCH 2/7] pvh dom0: construct_dom0 changes Mukesh Rathor
2013-12-17  2:38 ` [V7 PATCH 3/7] pvh dom0: implement XENMEM_add_to_physmap_range for x86 Mukesh Rathor
2013-12-17 13:07   ` Jan Beulich
2013-12-17 13:59     ` Ian Campbell
2013-12-17 14:36       ` Jan Beulich
2013-12-17 14:40         ` Ian Campbell
2013-12-17 15:11           ` Jan Beulich
2013-12-17 15:34             ` Ian Campbell [this message]
2013-12-18  7:55             ` Jan Beulich
2013-12-18 10:07               ` Ian Campbell
2013-12-18 10:34                 ` Jan Beulich
2013-12-18 10:41                   ` Ian Campbell
2013-12-18 10:55                     ` Jan Beulich
2013-12-17 23:57     ` Mukesh Rathor
2013-12-18 10:00       ` Ian Campbell
2013-12-17 16:56   ` Jan Beulich
2013-12-17  2:38 ` [V7 PATCH 4/7] pvh dom0: Introduce p2m_map_foreign Mukesh Rathor
2013-12-17  2:38 ` [V7 PATCH 5/7] pvh: change xsm_add_to_physmap Mukesh Rathor
2013-12-17  8:32   ` Jan Beulich
2013-12-18  0:19     ` Mukesh Rathor
2013-12-18  8:07       ` Jan Beulich
2013-12-19 15:50   ` Daniel De Graaf
2013-12-19 19:55     ` Mukesh Rathor
2014-01-28  1:55   ` Mukesh Rathor
2014-01-28 10:31     ` Jan Beulich
2014-01-29  2:08       ` Mukesh Rathor
2014-01-29 10:40         ` Ian Campbell
2014-01-29 11:38           ` Tim Deegan
2014-01-29 11:41             ` Ian Campbell
2014-01-29 11:48               ` Tim Deegan
2014-01-29 11:51                 ` Ian Campbell
2014-01-30  1:33                   ` Mukesh Rathor
2014-02-09 16:51                     ` Julien Grall
2014-02-10 13:42                       ` Ian Campbell
2014-02-10 15:16                         ` Julien Grall
2014-02-10 15:27                           ` Ian Campbell
2014-02-10 15:33                             ` Julien Grall
2014-02-10 15:37                               ` Ian Campbell
2014-02-20  2:37                               ` Mukesh Rathor
2014-02-20  8:31                                 ` Jan Beulich
2014-02-12 16:47   ` Julien Grall
2014-02-20  2:22     ` Mukesh Rathor
2014-02-20 13:49       ` Julien Grall
2014-02-21  1:22         ` Mukesh Rathor
2014-02-21 23:53           ` Mukesh Rathor
2014-02-22  0:20             ` Julien Grall
2013-12-17  2:38 ` [V7 PATCH 6/7] pvh dom0: Add and remove foreign pages Mukesh Rathor
2013-12-17  2:38 ` [V7 PATCH 7/7] pvh dom0: add opt_dom0pvh to setup.c Mukesh Rathor
2013-12-17 14:46 ` [V7 PATCH 0/7]: PVH dom0 Konrad Rzeszutek Wilk
2013-12-18  0:14   ` Mukesh Rathor

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=1387294446.27441.74.camel@kazak.uk.xensource.com \
    --to=ian.campbell@citrix.com \
    --cc=JBeulich@suse.com \
    --cc=george.dunlap@eu.citrix.com \
    --cc=keir.xen@gmail.com \
    --cc=tim@xen.org \
    --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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.