[Xen-devel] [RFC] Introduting Xen PV block driver to OVMF

[Anthony PERARD <anthony.perard@xxxxxxxxxx>]

Hi all,

I've been working on writing a driver to use a Xen PV disk directly from
OVMF.  So far, I have a working prototype, a guest can boot from a PV
device.  The code can be found on a git repo:
git://xenbits.xen.org/people/aperard/ovmf.git  pv-disk
(http://xenbits.xen.org/gitweb/?p=people/aperard/ovmf.git;a=summary)

(I don't want to send yet the patchs to the mailing list since there is
lots of dead code and probably hard to read because of the absence of
coding style)

I would like your comment on the current design choice.

What I have:
  - Ovmf/XenbusDxe:
  This driver is the first to start, based on the presence of a PCI
  device, which will initialize plenty of stuff needed to access a PV
  device and discover every PV devices.
  It initializes the Grant Table and Xenstore.
  It provide XenbusProtocol to PV drivers.
  There are some hypercall, in assembly which will target GCC for now.

  It consumes PciIoProtocol.
  It provides XenbusProtocol.

  - Ovmf/XenPvBlkDxe:
  This is a block driver that use XenbusProtocol and provide BlockIO.
  Everything that the driver need go through the XenbusProtocol, which
  is Xenstore read/write, event channel initialization, Grant table
  access.

  - OvmfPkg/Include/IndustryStandard/Xen:
  This contains all the public includes from Xen Project. There are
  few modification to use function provided by Ovmf instead of POSIX
  one.


What are all this?
  - Xenstore: it's a key/value database.
  - Xenbus: It's a king a bus that is bluild on top of Xenstore, this is
    used to discover PV devices.
  - Event Channel: It provide event notification between the two sides
    of a PV devices, the frontend and backend. This normaly is an
    interrupt.
  - Grant Tables: To grant access to part of a guest memory to another
    guest.


Do I need to apply the coding style to the public includes that come
from Xen (which are store in Include/IndustryStandard)? I mean changing
all uint32_t to UINT32, change every struct name, ...
I will however comply to the coding style in Ovmf/XenbusDxe and
XenPvBlkDxe.

I'm not sure what I should do with the assembly code, is writing it for
GCC enough or should I use another format (.S + .asm)?

Regards,

-- 
Anthony PERARD

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