From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:36908) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1T4rBj-0003Dy-Gr for qemu-devel@nongnu.org; Fri, 24 Aug 2012 06:32:33 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1T4rBi-0006Np-DC for qemu-devel@nongnu.org; Fri, 24 Aug 2012 06:32:27 -0400 Received: from smtp02.citrix.com ([66.165.176.63]:2623) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1T4rBi-0006Nj-8b for qemu-devel@nongnu.org; Fri, 24 Aug 2012 06:32:26 -0400 Message-ID: <5037586C.5000902@citrix.com> Date: Fri, 24 Aug 2012 11:33:16 +0100 From: Julien Grall MIME-Version: 1.0 References: In-Reply-To: Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [Xen-devel] [XEN][RFC PATCH V2 01/17] hvm: Modify interface to support multiple ioreq server List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Keir Fraser Cc: "qemu-devel@nongnu.org" , "christian.limpach@gmail.com" , Stefano Stabellini , Ian Campbell , "xen-devel@lists.xen.org" On 08/23/2012 02:26 PM, Keir Fraser wrote: > On 23/08/2012 14:18, "Ian Campbell" wrote: > > >>> diff --git a/xen/include/public/hvm/ioreq.h b/xen/include/public/hvm/ioreq.h >>> index 4022a1d..87aacd3 100644 >>> --- a/xen/include/public/hvm/ioreq.h >>> +++ b/xen/include/public/hvm/ioreq.h >>> @@ -34,6 +34,7 @@ >>> >>> #define IOREQ_TYPE_PIO 0 /* pio */ >>> #define IOREQ_TYPE_COPY 1 /* mmio ops */ >>> +#define IOREQ_TYPE_PCI_CONFIG 2 /* pci config space ops */ >>> #define IOREQ_TYPE_TIMEOFFSET 7 >>> #define IOREQ_TYPE_INVALIDATE 8 /* mapcache */ >>> >> I wonder why we skip 2-6 now -- perhaps they used to be something else >> and we are avoiding them to avoid strange errors? In which case adding >> the new on as 9 might be a good idea. >> > They were almost certainly used for representing R-M-W ALU operations back > in the days of the old IO emulator, very long ago. Still, there's no harm in > leaving them unused. > Ok. So I will use number 9 for IOREQ_TYPE_PCI_CONFIG.