RE: asterisk, ztdummy, and usb (and HZ = 100 under xen ???)

classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

RE: asterisk, ztdummy, and usb (and HZ = 100 under xen ???)

James Harper
> On 21 May 2005, at 08:53, James Harper wrote:
>
> We're going to rip the fixed ticker out of Xen and allow domains to
> specify a background ticker at a rate of their choice, which ought to
> fix this for you.

So I could have a domain with 100HZ, and another with 1000HZ? That would
be nice.

> Of course, you're pretty screwed running this kind of
> thing on Xen unless you dedicate a whole CPU to the relevant domain.

Which would be the clicks and pops I hear :)

I'm only testing VoIP as a proof of concept idea, and have been doing
some coding on kernel stuff, which is where xen is great. Even though
it's remote I can reboot a crashed domain easily, and have yet to
completely hose the domain by doing something stupid with a pci device
mapped to the domain.

Just on that subject, under what conditions would a domain with
permissions to access a pci device be able to bring down the machine if
I did something stupid in the kernel driver?

Thanks

James

_______________________________________________
Xen-devel mailing list
[hidden email]
http://lists.xensource.com/xen-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: asterisk, ztdummy, and usb (and HZ = 100 under xen ???)

Keir Fraser

On 22 May 2005, at 03:15, James Harper wrote:

> Just on that subject, under what conditions would a domain with
> permissions to access a pci device be able to bring down the machine if
> I did something stupid in the kernel driver?

Assuming you have restricted the domain to just accessing registers and
IRQs belonging to the device it controls, I think the only way would be
by programming the device to wreak havoc on its behalf (by DMAing
arbitrary memory). It also has control of an interrupt line, so if that
is shared it might be possible for the domain to arrange an interrupt
storm that either you mask, affecting servicing of other devices on
that line, or you end up in interrupt livelock. This could be fixed by
masking the interrupt, terminating the domain, clearing the enable bits
in the device's PCI space, then unmasking the interrupt. In any case,
legacy interrupts are on their way out, replaced with message-based
interrupts.

  -- Keir


_______________________________________________
Xen-devel mailing list
[hidden email]
http://lists.xensource.com/xen-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

RE: asterisk, ztdummy, and usb (and HZ = 100 under xen ???)

James Harper
In reply to this post by James Harper
> Assuming you have restricted the domain to just accessing registers
and
> IRQs belonging to the device it controls, I think the only way would
be
> by programming the device to wreak havoc on its behalf (by DMAing
> arbitrary memory).

Is there a way to protect against rogue DMA writes (without knowing the
details of every particular piece of hardware) or is it just the price
to be paid for direct hardware access?

James

_______________________________________________
Xen-devel mailing list
[hidden email]
http://lists.xensource.com/xen-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: asterisk, ztdummy, and usb (and HZ = 100 under xen ???)

Keir Fraser

On 22 May 2005, at 08:56, James Harper wrote:

>> Assuming you have restricted the domain to just accessing registers
> and
>> IRQs belonging to the device it controls, I think the only way would
> be
>> by programming the device to wreak havoc on its behalf (by DMAing
>> arbitrary memory).
>
> Is there a way to protect against rogue DMA writes (without knowing the
> details of every particular piece of hardware) or is it just the price
> to be paid for direct hardware access?

You need an IOMMU. Then the 'bus addresses' you program into the device
are checked and translated by the IOMMU when it attempts to access
memory.

Chipset extensions to support protection from rogue devices is likely
to appear for commodity x86 systems in the next couple of years, I
think.

  -- Keir


_______________________________________________
Xen-devel mailing list
[hidden email]
http://lists.xensource.com/xen-devel
Loading...