Re: A set of "standard" virtual devices?

On Tuesday 03 April 2007, Cornelia Huck wrote:
On s390, it would be more than strangeness. There's no implementation
of PCI at all, someone would have to cook it up - and it wouldn't have
any use beyond those special devices. Since there isn't any bus type
that is available on *all* architectures, a generic "virtual" bus with
very simple probing seems much saner...

I think we need to separate two problems here:

1. Probing:
That's really what triggered the discussion, PCI probing is well-understood
and implemented on _most_ platforms, so there is some value in reusing it.
When you talk about 'very simple probing', I'm not sure what the most simple
approach could be. Ideas that have been implemented before include:
a) have a limited set of device IDs (e.g. 65535 devices, or a hierarchic tree),
and try to access each one of them in order to find out if it's there. We
do that for PCI or CCW, for instance.
b) Have an iterator in the hypervisor (or firmware), to return a handle to
the first, next or child of a device. We do that for open firmware.
c) ask the hypervisor for an unused device of a given class, which needs to
be returned to the hypervisor when no longer used. This is how the PS3
hypervisor works, but it does not play well with the Linux driver model.

2. Device access:
When talking to a virtual device, you want to have at least a way to give
commands to it and a way to get interrupts back. Again, multiple ideas
have been used in the past, and we should choose a subset:
a) PCI-like: mmio using memory and/or I/O space BAR setup, interrupt
numbers and DMA to guest physical addresses.
b) Channel-like: use an hcall to give commands to the hypervisor, passing
down a device handle command code and data areas in guest physical space.
Interrupts return the device handle or a OS-defined per-device value.
c) Minimalistic: Every device is mapped into the guest address space and
can potentially be remapped into user space. The device memory can be
shared between guests and/or with the host if that uses the same driver.
The guest is able to signal the receiving end using an hcall and gets
interrupts like in b)
d) UNIX-like: devices appear like file descriptors, the guest can do
operations like read/write/sync/mmap, potentially ioctl on them to talk
to the host.

Arnd <><
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

Relevant Pages

  • Re: A set of "standard" virtual devices?
    ... That's really what triggered the discussion, PCI probing is well-understood ... But that probing mechanism will depend on the actual interface ... ask the hypervisor for an unused device of a given class, ...
    (Linux-Kernel)
  • VMI Interface Proposal Documentation for I386, Part 2.1
    ... standard structures in memory that are provided by a native ROM ... The guest kernel must be modified to run at a dynamic privilege ... CPL 1-2, and with the hypervisor running at CPL0, and user code at ... the hypervisor must combine segment protection to ensure that the ...
    (Linux-Kernel)
  • Re: [RFC PATCH 25/33] Implement timekeeping for Xen
    ... In addition to this, we would also like to be able to absolutely slave the guest time to the hypervisor time, so that even if the hypervisor time changes there still a very small skew between the guest time. ... It may also choose to use the hypervisor as a clock source, or it can use any other clock. ... It would never make sense to use ntp or a non-hypervisor clocksource in a dependent-time guest. ...
    (Linux-Kernel)
  • Re: [RFC PATCH 0/3] generic hypercall support
    ... The hypervisor agnostic driver can then use ... Consider nested virtualization where the host runs a guest which is itself a hypervisor, ... Host H traps the hypercall, sees it originated in G1 while in guest mode, so it injects it into G1. ... If this were done using mmio or pio, ...
    (Linux-Kernel)
  • Re: [RFC PATCH 00/17] virtual-bus
    ... need it for proper guest support. ... a virtio server in the kernel would know nothing about PCI. ... Userspace would handle the PCI interface and configure the kernel. ...
    (Linux-Kernel)