Re: [Qemu-devel] [Xen-devel] [XEN][RFC PATCH V2 01/17] hvm: Modify interface to support multiple ioreq server
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. -- Keir
Re: [Xen-devel] Re: [Qemu-devel] [PATCH V9 04/16] xen: Support new libxc calls from xen unstable.
On 27/01/2011 12:03, "Stefano Stabellini" wrote: >> Really? There's no VERSION #define? Can please fix this upstream so we >> don't have to do this forever. > > Yeah, it is a bit of a shame but there isn't an #define VERSION in > xenctrl.h. > If we introduce it now, the first Xen release to have it is going to be > 4.1. We can add it for 4.1.0 and 4.0.2. Really that covers everyone who'll want to build newly upstreamed qemu bits. Gracefully failing to configure in the absence of the new define would be quite acceptable imo. -- Keir
Re: [Xen-devel] Re: [Qemu-devel] Recursion in cpu_physical_memory_rw
On 15/11/06 2:58 am, "Herbert Xu" <[EMAIL PROTECTED]> wrote: >> It isn't always system memory. Some DMA controllers deliberately write to >> device FIFOs. There are also several devices which map areas of onboard RAM. >> At minimum you need to make those to use RAM mappings rather than MMIO. > > I'm not suggesting that we change all existing users of cpu_physical_* > to a new interface that only accessed RAM. However, for cases where it > is obvious that only system RAM is intended (e.g., rtl8139), it makes > sense to bypass MMIO handlers. Could we add a recursion counter to the memory-access functions, and bail if it reaches some limit? -- Keir
Re: [Xen-devel] Re: [Qemu-devel] Recursion in cpu_physical_memory_rw
On 15/11/06 11:12, "Herbert Xu" <[EMAIL PROTECTED]> wrote: >> Could we add a recursion counter to the memory-access functions, and bail if >> it reaches some limit? > > Yes that would work too. However, chips such as rtl8139 should never > do MMIO in this case (the real hardware would never allow that to occur) > so we should do that accordingly. We'd take a patch for Xen to do it the 'proper way' with an extended memory-access API if that is also acceptable for the upstream Qemu maintainers. -- Keir
Re: [Xen-devel] Re: [Qemu-devel] Recursion in cpu_physical_memory_rw
On 16/11/06 5:11 am, "Herbert Xu" <[EMAIL PROTECTED]> wrote: >> The only "harm" done to a host is that the process will take as much CPU >> as it can get. This is really only a problem in Xen because the device >> model is in Domain-0. Once the device model is in a different domain, >> it doesn't matter anymore as the normal scheduler parameters can be used >> to ensure that no other hosts are harmed. > > Actually it'll still be a problem in a driver domain unless it (and the > hardware) is dedicated to a single guest. Each qemu 'stub domain' will be dedicated to a single guest. Adding a recursion counter to the memory access functions sounds possibly useful even just from a debugging p.o.v. though. -- Keir
