From mboxrd@z Thu Jan 1 00:00:00 1970 From: Andrew Cooper Subject: Re: [PATCH v3 1/2] Differentiate IO/mem resources tracked by ioreq server Date: Mon, 10 Aug 2015 11:56:06 +0100 Message-ID: <55C88346.2020001@citrix.com> References: <1439177621-22061-1-git-send-email-yu.c.zhang@linux.intel.com> <1439177621-22061-2-git-send-email-yu.c.zhang@linux.intel.com> <20150810082612.GC8857@zion.uk.xensource.com> <9AAE0902D5BC7E449B7C8E4E778ABCD02F57C72E@AMSPEX01CL01.citrite.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <9AAE0902D5BC7E449B7C8E4E778ABCD02F57C72E@AMSPEX01CL01.citrite.net> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Paul Durrant , Wei Liu , Yu Zhang Cc: Kevin Tian , "Keir (Xen.org)" , Ian Campbell , "xen-devel@lists.xen.org" , Stefano Stabellini , "zhiyuan.lv@intel.com" , "jbeulich@suse.com" , Ian Jackson List-Id: xen-devel@lists.xenproject.org On 10/08/15 09:33, Paul Durrant wrote: >> -----Original Message----- >> From: Wei Liu [mailto:wei.liu2@citrix.com] >> Sent: 10 August 2015 09:26 >> To: Yu Zhang >> Cc: xen-devel@lists.xen.org; Paul Durrant; Ian Jackson; Stefano Stabellini; Ian >> Campbell; Wei Liu; Keir (Xen.org); jbeulich@suse.com; Andrew Cooper; >> Kevin Tian; zhiyuan.lv@intel.com >> Subject: Re: [PATCH v3 1/2] Differentiate IO/mem resources tracked by ioreq >> server >> >> On Mon, Aug 10, 2015 at 11:33:40AM +0800, Yu Zhang wrote: >>> Currently in ioreq server, guest write-protected ram pages are >>> tracked in the same rangeset with device mmio resources. Yet >>> unlike device mmio, which can be in big chunks, the guest write- >>> protected pages may be discrete ranges with 4K bytes each. >>> >>> This patch uses a seperate rangeset for the guest ram pages. >>> And a new ioreq type, IOREQ_TYPE_MEM, is defined. >>> >>> Note: Previously, a new hypercall or subop was suggested to map >>> write-protected pages into ioreq server. However, it turned out >>> handler of this new hypercall would be almost the same with the >>> existing pair - HVMOP_[un]map_io_range_to_ioreq_server, and there's >>> already a type parameter in this hypercall. So no new hypercall >>> defined, only a new type is introduced. >>> >>> Signed-off-by: Yu Zhang >>> --- >>> tools/libxc/include/xenctrl.h | 39 +++++++++++++++++++++++--- >>> tools/libxc/xc_domain.c | 59 >> ++++++++++++++++++++++++++++++++++++++-- >> >> FWIW the hypercall wrappers look correct to me. >> >>> diff --git a/xen/include/public/hvm/hvm_op.h >> b/xen/include/public/hvm/hvm_op.h >>> index 014546a..9106cb9 100644 >>> --- a/xen/include/public/hvm/hvm_op.h >>> +++ b/xen/include/public/hvm/hvm_op.h >>> @@ -329,8 +329,9 @@ struct xen_hvm_io_range { >>> ioservid_t id; /* IN - server id */ >>> uint32_t type; /* IN - type of range */ >>> # define HVMOP_IO_RANGE_PORT 0 /* I/O port range */ >>> -# define HVMOP_IO_RANGE_MEMORY 1 /* MMIO range */ >>> +# define HVMOP_IO_RANGE_MMIO 1 /* MMIO range */ >>> # define HVMOP_IO_RANGE_PCI 2 /* PCI segment/bus/dev/func range >> */ >>> +# define HVMOP_IO_RANGE_MEMORY 3 /* MEMORY range */ >> This looks problematic. Maybe you can get away with this because this is >> a toolstack-only interface? >> > Indeed, the old name is a bit problematic. Presumably re-use like this would require an interface version change and some if-defery. I assume it is an interface used by qemu, so this patch in its currently state will break things. ~Andrew