WARNING - OLD ARCHIVES

This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-ia64-devel

[Xen-ia64-devel] Notes about driver domains

To: xen-ia64-devel@xxxxxxxxxxxxxxxxxxx, "Magenheimer, Dan (HP Labs Fort Collins)" <dan.magenheimer@xxxxxx>
Subject: [Xen-ia64-devel] Notes about driver domains
From: Tristan Gingold <Tristan.Gingold@xxxxxxxx>
Date: Tue, 25 Jul 2006 08:59:47 +0200
Delivery-date: Mon, 24 Jul 2006 23:55:25 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
List-help: <mailto:xen-ia64-devel-request@lists.xensource.com?subject=help>
List-id: Discussion of the ia64 port of Xen <xen-ia64-devel.lists.xensource.com>
List-post: <mailto:xen-ia64-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-ia64-devel>, <mailto:xen-ia64-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-ia64-devel>, <mailto:xen-ia64-devel-request@lists.xensource.com?subject=unsubscribe>
Sender: xen-ia64-devel-bounces@xxxxxxxxxxxxxxxxxxx
User-agent: KMail/1.5
Hi,

I have started to work on driver domains.  Here are a few notes on the issues:

* pci backend compiles without any change (good !)

* pci frontend integration is not easy.  From my understanding, linux/ia64 pci 
code really wants its own 'struct pci_controller', while pcifront.h provides 
its own.  I have slightly changes pcifront.h and pci_op.c to use the ia64 
pci.h  This makes a very few #ifdef __ia64__ (2 in fact).  I don't know how 
to improve this, I am definitly not a linux/ia64-pci expert!

* Memory attributes have to be handled (if you want to avoid mca!).  The 
current method (dom0 uses its attribute, domU always use WB) doesn't work 
anymore.  Xen has to merge domain attributes with MADT attributes.

* Currently any domain can do ioremap.  Access checks have to be done.

* IO port entry should be added in the MADT of every domain.  Access checks 
have to be performed.  I don't know wether we should use a per page control, 
a global control (yes/no) or a per port control (slow!).  Disabled port 
should either crash the domain or be silently rejected.  This issue has 
already been discussed and silent rejection was agreed.

* IRQ should be access controled.

* memory mapped IO pages should belongs to dom_io pseudo-domain.  At least 
work is required here to avoid crash when a domain is destroyed.

* More issues ?

At this time I was able to see an ethernet card in a domU.

Tristan.

_______________________________________________
Xen-ia64-devel mailing list
Xen-ia64-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-ia64-devel

<Prev in Thread] Current Thread [Next in Thread>