Re: [Xen-devel] Re: [Qemu-devel] Recursion in cpu_physical_memory_rw

2007-03-25 Thread Keir Fraser
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

Re: [Xen-devel] Re: [Qemu-devel] Recursion in cpu_physical_memory_rw

2007-03-25 Thread Keir Fraser
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

Re: [Qemu-devel] Recursion in cpu_physical_memory_rw

2007-03-25 Thread Anthony Liguori
Herbert Xu wrote: On Wed, Nov 15, 2006 at 12:57:24AM +, Paul Brook 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

Re: [Xen-devel] Re: [Qemu-devel] Recursion in cpu_physical_memory_rw

2007-03-25 Thread Keir Fraser
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

Re: [Xen-devel] Re: [Qemu-devel] Recursion in cpu_physical_memory_rw

2006-11-16 Thread Herbert Xu
On Thu, Nov 16, 2006 at 07:52:45AM +, Keir Fraser wrote: Each qemu 'stub domain' will be dedicated to a single guest. Adding a You're right of course. Somehow I was thinking of having the physical NIC in the qemu domain which obviously isn't the case. recursion counter to the memory

Re: [Xen-devel] Re: [Qemu-devel] Recursion in cpu_physical_memory_rw

2006-11-15 Thread Herbert Xu
On Wed, Nov 15, 2006 at 07:55:48AM +, Keir Fraser wrote: 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

Re: [Xen-devel] Re: [Qemu-devel] Recursion in cpu_physical_memory_rw

2006-11-15 Thread Paul Brook
However, chips such as rtl8139 should never do MMIO in this case (the real hardware would never allow that to occur) Really? Why wouldn't it work on real hardware? Paul ___ Qemu-devel mailing list Qemu-devel@nongnu.org

Re: [Xen-devel] Re: [Qemu-devel] Recursion in cpu_physical_memory_rw

2006-11-15 Thread Herbert Xu
On Wed, Nov 15, 2006 at 03:02:02PM +, Paul Brook wrote: However, chips such as rtl8139 should never do MMIO in this case (the real hardware would never allow that to occur) Really? Why wouldn't it work on real hardware? For rtl8139 it would cause a Master Abort. Cheers, -- Visit

Re: [Qemu-devel] Recursion in cpu_physical_memory_rw

2006-11-15 Thread Herbert Xu
On Wed, Nov 15, 2006 at 01:03:34PM -0600, Anthony Liguori wrote: The scenario here is a compromised guest attempting to harm a host such as Xen. 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

[Qemu-devel] Recursion in cpu_physical_memory_rw

2006-11-14 Thread Herbert Xu
Hi: A number of qemu driver backends (such as rtl8139) call the function cpu_physical_memory_rw to read/write guest memory. The target guest memory address is often supplied by the guest. This opens up the possibility of a guest giving an address which happens to be an MMIO address which can

Re: [Qemu-devel] Recursion in cpu_physical_memory_rw

2006-11-14 Thread Paul Brook
On Wednesday 15 November 2006 00:43, Herbert Xu wrote: Hi: A number of qemu driver backends (such as rtl8139) call the function cpu_physical_memory_rw to read/write guest memory. The target guest memory address is often supplied by the guest. This opens up the possibility of a guest giving