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
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 h
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.
>
>
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 allo
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'
