Re: [Xen-devel] [PATCH v5.99.1 RFC 1/4] xen/arm: Duplicate gic-v2.c file to support hip04 platform version

[Julien Grall <julien.grall@xxxxxxxxxx>]

Hi Ian,

On 26/02/15 12:44, Ian Campbell wrote:
> The set of hardware which Xen needs to be able to drive (rather than
> give to a hardware domain) is:
> 
>       * CPUs
>       * Host interrupt controllers
>       * Host timers
>       * A UART
>       * Second-state MMUs
>       * Second-stage SMMUs/IOMMU (First-stage used by domains)
>       * PCI host bridges (in the near future)
> 
> (did I forget any?)

I think everything is there.

> NB: I'm only considering host level stuff here. Our virtualised hardware
> as exposed to the guest is well defined right now and any conversation
> about deviating from the set of hardware (e.g. providing a guest view to
> a non-GIC compliant virtual interrupt controller) would be part of a
> separate larger conversation about "hvm" style guests (and I'd, as you
> might imagine, be very reluctant to code to Xen itself to support
> non-standard vGICs in particular).

That would mean on platform such as Hisilicon, Guest (including DOM0)
won't be able to use more than 8 CPUs. But I guess this is a fair trade
for having a GIC which differs from the spec.

> From a "what does 'standards compliant' mean" PoV we have:
> 
> CPUs:
> 
>         Specified in the ARM ARM (v7=ARM DDI 0406, v8=ARM DDI 0487).
>         
>         Uncontroversial, I hope!
>         
> Host interrupt controllers:
> 
>         Defined in "ARM Generic Interrupt Controller Architecture
>         Specification" (v2=ARM IHI 0048B, v3=???).

AFAICT, for GICv3 there is a hardware spec available (though not
publicly) but no developer spec.

>         Referenced from ARMv8 ARM (but not required AFAICT) but
>         nonetheless this is what we consider when we talk about the
>         "standard interrupt controller".
>         
> Host timers:
> 
>         Defined in the ARMv8 ARM "Generic Timers" chapter.
>         
>         Defined as an extension to ARMv7 (don't have doc ref handy). For
>         our purposes such extensions are considered standardized[*].

It's worth to mention that we don't support generic memory mapped timer
for now. I don't know if we aim to support it.

> UARTS:
> 
>         SBSA defines some (pl011 only?), but there are lots, including
>         8250-alike ones (ns16550 etc) which is a well established
>         standard (from x86).
>         
>         Given that UART drivers are generally small and pretty trivial I
>         think we can tolerate "non-standard" (i.e. non-SBSA, non-8250)
>         ones, so long as they are able to support our vuart interface.
>         
>         I think the non-{pl011,8250} ones should be subject to non-core
>         (i.e. community) maintenance as I mentioned previously, i.e
>         should be listed in MAINTAINERS other than under the core ARM
>         entry. If we decide to go ahead with this approach I'll ask the
>         appropriate people to update MAINTAINERS.

At that time we have 3 "non-compliant" UART in Xen: exynos4210, scif and
omap.

Having maintainers per non-compliant UART would make some generic more
complicate to upstream. Indeed, it would require all the ack.

> 
> Second stage MMU:
> 
>         Defined in the ARMv8 ARM, or the ARMv7 LPAE extensions[*, **].
>         
> Second stage SMMU/IOMMU:
> 
>         Defined in "ARM System Memory Management Unit Architecture
>         Specification" (ARM IHI 0062D?)

The D is the revision, so this would be ARM IHI 0062 for all the SMMUs.

[..]

> I think the above is a workable definition of what it is reasonable to
> expect the core Xen/ARM maintainers to look after (with that particular
> hat on) vs. what it should be expected for interested members of the
> community to step up and maintain (where the people who happen to be
> core Xen/ARM maintainers may occasionally chose to have such a hat too.)

I got few questions about it:
        -  What happen if the maintainers of a specific driver (UART/IRQ
controller) doesn't answer?
        - How do we handle possible security issue related to a specific
driver? Is it even considered as a security one?
        - As a new drivers would tight to a new set of maintainers, how do we
decide that a new drivers is accepted in Xen?

Given the governance spec [1], we may decide to reject a maintainers for
some reason. Does it mean the drivers is rejected too?

Overall, I think we should clearly define the condition of
acceptance/maintenance of a specific driver.

[..]

> [**] The LPAE extensions include/are mixed with the hyp mode page table
> format, so we pretty certainly need it.

Rigth, the ARM spec required LPAE extensions when virtualization is
supported.

Regards,

-- 
Julien Grall

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel