[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Does xen has driver for i2c / spi / gpio pin ?
Hi Sarah , Thanks a lot for these details & links .
- Ashish
On Sat, 8 Aug, 2020, 3:48 AM Sarah Newman, < srn@xxxxxxxxx> wrote: On 8/5/20 7:05 AM, AshishKumar Mishra wrote:
> Hi All ,
>
> With pointer from community i am able to find driver implementation
> for backend / frontend.
>
> But in Linux code base :
>
> 1) I can find backend for only pci / net / block .
> Does XEN doesn't have drivers for i2c / spi / gpio etc.
>
> 2) If we need to have an xen driver only to handle gpio as an interrupt ,
> what sections / driver will be required .
> ( In Linux an character driver with interrupt would be fine )
>
> 3) Is there any rules to decide if the device is supported or not by xen ?
> In Linux we could find if there is an specific controller driver .
> Assuming i I have two network controller IP from say different vendor
> ,
> how to confirm which one will be supported by XEN ?
>
> 4) How to confirm if some custom IP core is supply by xen ?
> ( Say a soc has new IP core for new functionality , how can we confirm
> if it will work in XEN (
>
>
> Apologies if the question are too obvious , but since I am starting with
> XEN
> I am trying to understand ( & relate with Linux code base )
In Xen, there's typically one or more domains that have at least some hardware drivers. Traditionally the "dom0" is the only domain with access to
hardware, though there are also driver domains https://wiki.xenproject.org/wiki/Driver_Domain. Then there are unprivileged guest domains that do not
talk directly to hardware.
The drivers you're talking about in 1) are to provide a paravirtualized interface to the unprivileged guest domains. See
https://wiki.xenproject.org/wiki/Xen_Networking for an example.
The dom0 is the default privileged domain. Otherwise, this may help explain how to pass through hardware to other domains that are not the dom0:
https://xenbits.xen.org/docs/4.14-testing/misc/arm/passthrough.txt
If you only need to control hardware without sharing it between domains, well-behaved drivers should Just Work. If instead you need shared use of a
resource that doesn't already have a paravirtualized driver, I would probably look at doing something custom via
https://xenbits.xen.org/docs/4.14-testing/man/xen-pv-channel.7.html or the under documented https://www.cs.uic.edu/~xzhang/vchan/
--Sarah
|