On 23/08/2012 14:18, Ian Campbell ian.campb...@citrix.com 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
On 27/01/2011 12:03, Stefano Stabellini stefano.stabell...@eu.citrix.com
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
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
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
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
