thr3ads.net - Xen devel - AW: [Xen-devel] PCI bus emulation? [Aug 2005]

If this information is useful, please help other people find it:
Share via:

Retzki, Sascha [Xplain]

2005-Aug-04 08:18 UTC

AW: [Xen-devel] PCI bus emulation?

I don''t get the purpose. What is wrong with hiding certain PCI devices
from
DomO and thus make them available in domU?

Btw, you are sure all OSes "find an empty bus"?


-----Ursprüngliche Nachricht-----
Von: Stefan Berger [mailto:stefanb@us.ibm.com] 
Gesendet: Mittwoch, 3. August 2005 22:47
An: xen-devel@lists.xensource.com
Betreff: [Xen-devel] PCI bus emulation?

Hello!

  I have seen that the Qemu code contains some nice code for PCI bus 
emulation. I wonder whether this code could be reused in XEN to fake a PCI 
bus by running the PCI emulation code in an exception handler in the 
hypervisor and setting a user domain''s IO privilege level appropriately
to
have all inb/outb''s intercepted. This could have potential benefits on
the
build process of user domains which could include the PCI code when built, 
but that code when probing the PCI bus would only find an empty bus and 
the probing of the drivers in the kernel would not start. Maybe this code 
could also be used to support driver domains. Is this a good idea? :-)

  Stefan




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

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

Mark Williamson

2005-Aug-04 14:48 UTC

head link

Re: AW: [Xen-devel] PCI bus emulation?

Something similar to this is done already: domains are forced to access the 
PCI configuration spaces (which describes what cards are present and how 
they''re configured) through hypercalls to Xen.  The hiding / revealing
stuff
just tells Xen what devices to let the domains see through this interface.

This is broken now because the PCI probing code has moved out of Xen, so dom0 
can always see all of the PCI devices and will grab them for itself.  What is 
needed is:
a) a way of dom0 initialising the bus but not grabbing all the devices
b) a way of allowing other domains to probe PCI config space via dom0 so it 
can control what devices they see

a) will require some tweaks to the PCI code in dom0.  b) will require some 
kind of virtualised PCI device (as Stefan described) that can control what 
the guest is allowed to see.

Using emulation to implement b) would have the advantage that the current 
probing code shouldn''t need changing.  OTOH, the overall system may be 
simpler if the guest detects it''s not allowed to access the hardware
directly
and explicitly talks to dom0 e.g. using Xenstore to probe its devices.

Cheers,
Mark
> I don''t get the purpose. What is wrong with hiding certain PCI
devices from
> DomO and thus make them available in domU?
>
> Btw, you are sure all OSes "find an empty bus"?
>
>
> -----Ursprüngliche Nachricht-----
> Von: Stefan Berger [mailto:stefanb@us.ibm.com]
> Gesendet: Mittwoch, 3. August 2005 22:47
> An: xen-devel@lists.xensource.com
> Betreff: [Xen-devel] PCI bus emulation?
>
> Hello!
>
>   I have seen that the Qemu code contains some nice code for PCI bus
> emulation. I wonder whether this code could be reused in XEN to fake a PCI
> bus by running the PCI emulation code in an exception handler in the
> hypervisor and setting a user domain''s IO privilege level
appropriately to
> have all inb/outb''s intercepted. This could have potential
benefits on the
> build process of user domains which could include the PCI code when built,
> but that code when probing the PCI bus would only find an empty bus and
> the probing of the drivers in the kernel would not start. Maybe this code
> could also be used to support driver domains. Is this a good idea? :-)
>
>   Stefan
>
>
>
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

Stefan Berger

2005-Aug-04 15:33 UTC

head link

Re: AW: [Xen-devel] PCI bus emulation?

Mark Williamson <mark.williamson@cl.cam.ac.uk> wrote on 08/04/2005 
09:48:05 AM:
> Something similar to this is done already: domains are forced to access 
the > PCI configuration spaces (which describes what cards are present and how 
> they''re configured) through hypercalls to Xen.  The hiding /
revealing
stuff > just tells Xen what devices to let the domains see through this 
interface.> 
> This is broken now because the PCI probing code has moved out of Xen, so 
dom0 > can always see all of the PCI devices and will grab them for itself. 
What is > needed is:
> a) a way of dom0 initialising the bus but not grabbing all the devices
> b) a way of allowing other domains to probe PCI config space via dom0 so 
it > can control what devices they see
> 
> a) will require some tweaks to the PCI code in dom0.  b) will require 
some > kind of virtualised PCI device (as Stefan described) that can control 
what > the guest is allowed to see.
It shuld be possible for domain 0 to read all devices from the bus and 
build its list. Then domain 0 could take the to-be-hidden devices out of 
that list and maybe ''program'' the virtualized PCI bus of a
driver domain
to show these devices (through sending a message to the HV about what to 
present). A driver domain would still have to be co-operative in that 
sense that it first starts out with a low privilege level (by default a 
domain would be created that way) to run into the exception handler and 
request to have its privilege level raised once it wants to access the raw 
hardware. Setting the individual privilege bits for a driver domain might 
be another possibility, but you''d  need to know the list of ioports for
each possible device.
> 
> Using emulation to implement b) would have the advantage that the 
current > probing code shouldn''t need changing.  OTOH, the overall system
may be
> simpler if the guest detects it''s not allowed to access the 
hardwaredirectly > and explicitly talks to dom0 e.g. using Xenstore to probe its devices.
I also think that it would have the advantage of being able to build a 
user domain independently of whether it will become a driver domain or 
not. All the difference would be in the virtualized PCI bus presenting 
devices or being empty.

 Stefan> 
> Cheers,
> Mark
> 
> > I don''t get the purpose. What is wrong with hiding certain
PCI devices
from> > DomO and thus make them available in domU?
> >
> > Btw, you are sure all OSes "find an empty bus"?
> >
> >
> > -----Ursprüngliche Nachricht-----
> > Von: Stefan Berger [mailto:stefanb@us.ibm.com]
> > Gesendet: Mittwoch, 3. August 2005 22:47
> > An: xen-devel@lists.xensource.com
> > Betreff: [Xen-devel] PCI bus emulation?
> >
> > Hello!
> >
> >   I have seen that the Qemu code contains some nice code for PCI bus
> > emulation. I wonder whether this code could be reused in XEN to fake a
PCI> > bus by running the PCI emulation code in an exception handler in the
> > hypervisor and setting a user domain''s IO privilege level 
appropriately to> > have all inb/outb''s intercepted. This could have potential
benefits on
the> > build process of user domains which could include the PCI code when 
built,> > but that code when probing the PCI bus would only find an empty bus 
and> > the probing of the drivers in the kernel would not start. Maybe this 
code> > could also be used to support driver domains. Is this a good idea? :-)
> >
> >   Stefan
> >
> >
> >
> >
> > _______________________________________________
> > Xen-devel mailing list
> > Xen-devel@lists.xensource.com
> > http://lists.xensource.com/xen-devel
> >
> > _______________________________________________
> > Xen-devel mailing list
> > Xen-devel@lists.xensource.com
> > http://lists.xensource.com/xen-devel

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

Mark Williamson

2005-Aug-04 15:42 UTC

head link

Re: AW: [Xen-devel] PCI bus emulation?

> It shuld be possible for domain 0 to read all devices from the bus and
> build its list. Then domain 0 could take the to-be-hidden devices out of
> that list
Yep.  Do you think it''s possible to simply chop these devices out of
the list
after initialisation but before passing up to the generic PCI layer? 
That''d
be excellent.
> and maybe ''program'' the virtualized PCI bus of a driver
domain
> to show these devices (through sending a message to the HV about what to
> present).
I''d be inclined to have this purely implemented at kernel level using 
interdomain comms, rather than having Xen know anything about it.
> A driver domain would still have to be co-operative in that 
> sense that it first starts out with a low privilege level (by default a
> domain would be created that way) to run into the exception handler and
> request to have its privilege level raised once it wants to access the raw
> hardware. Setting the individual privilege bits for a driver domain might 
> be another possibility, but you''d  need to know the list of
ioports for
> each possible device.
Right now we do just that: domains never get access to the PCI controller, so 
config space accesses must always be mediated by Xen.  Domains are assigned 
direct access to the devices they control using IO port bits (although
I''m
not entirely happy with that, since it allows applications in the domain 
access to the device - fine for a driver domain but not good for partitioning 
the hardware) and controlled mapping of IO memory.

This works now because Xen can read the required IO port / memory ranges out 
of PCI config space and enable them as appropriate.  To make this work with 
the unstable tree, we''d need to have dom0''s kernel somehow get
this
information out...
> > Using emulation to implement b) would have the advantage that the
>
> current
>
> > probing code shouldn''t need changing.  OTOH, the overall
system may be
> > simpler if the guest detects it''s not allowed to access the
>
> hardwaredirectly
>
> > and explicitly talks to dom0 e.g. using Xenstore to probe its devices.
>
> I also think that it would have the advantage of being able to build a
> user domain independently of whether it will become a driver domain or
> not. All the difference would be in the virtualized PCI bus presenting
> devices or being empty.
I definitely think we should retain the ability to build one kernel that works 
in all possible domains.  The startinfo does contain flags that tell the 
domain if it''s dom0 (and therefore controls the PCI bus) or not.

Cheers,
Mark
>  Stefan
>
> > Cheers,
> > Mark
> >
> > > I don''t get the purpose. What is wrong with hiding
certain PCI devices
>
> from
>
> > > DomO and thus make them available in domU?
> > >
> > > Btw, you are sure all OSes "find an empty bus"?
> > >
> > >
> > > -----Ursprüngliche Nachricht-----
> > > Von: Stefan Berger [mailto:stefanb@us.ibm.com]
> > > Gesendet: Mittwoch, 3. August 2005 22:47
> > > An: xen-devel@lists.xensource.com
> > > Betreff: [Xen-devel] PCI bus emulation?
> > >
> > > Hello!
> > >
> > >   I have seen that the Qemu code contains some nice code for PCI
bus
> > > emulation. I wonder whether this code could be reused in XEN to
fake a
>
> PCI
>
> > > bus by running the PCI emulation code in an exception handler in
the
> > > hypervisor and setting a user domain''s IO privilege
level
>
> appropriately to
>
> > > have all inb/outb''s intercepted. This could have
potential benefits on
>
> the
>
> > > build process of user domains which could include the PCI code
when
>
> built,
>
> > > but that code when probing the PCI bus would only find an empty
bus
>
> and
>
> > > the probing of the drivers in the kernel would not start. Maybe
this
>
> code
>
> > > could also be used to support driver domains. Is this a good
idea? :-)
> > >
> > >   Stefan
> > >
> > >
> > >
> > >
> > > _______________________________________________
> > > Xen-devel mailing list
> > > Xen-devel@lists.xensource.com
> > > http://lists.xensource.com/xen-devel
> > >
> > > _______________________________________________
> > > Xen-devel mailing list
> > > Xen-devel@lists.xensource.com
> > > http://lists.xensource.com/xen-devel
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

Neugebauer, Rolf

2005-Aug-04 22:51 UTC

head link

RE: AW: [Xen-devel] PCI bus emulation?

> -----Original Message-----
> From: xen-devel-bounces@lists.xensource.com [mailto:xen-devel-
> bounces@lists.xensource.com] On Behalf Of Mark Williamson
> Sent: 04 August 2005 16:42
> To: Stefan Berger
> Cc: Retzki, Sascha [Xplain]; xen-devel@lists.xensource.com
> Subject: Re: AW: [Xen-devel] PCI bus emulation?
> 
> > It shuld be possible for domain 0 to read all devices from the bus and
> > build its list. Then domain 0 could take the to-be-hidden devices out
of
> > that list
> 
> Yep.  Do you think it''s possible to simply chop these devices out
of the
> list
> after initialisation but before passing up to the generic PCI layer?
> That''d
> be excellent.
A while back I had a look at this and it didn''t look as if it would be
very straight forward by just using arch specific code but probably doable using
the hooks provided.
> 
> > and maybe ''program'' the virtualized PCI bus of a
driver domain
> > to show these devices (through sending a message to the HV about what
to
> > present).
> 
> I''d be inclined to have this purely implemented at kernel level
using
> interdomain comms, rather than having Xen know anything about it.
I''m not entirely convinced that this is the right way to do. Once the
devices are set up by dom0 xen wouldn''t have to do that much and
intercepting pci config read/writes in xen using the instruction emulator might
be better and create less dependencies on Dom0.

The code in Xen 2.x dealing with PCI config reads/writes by device driver
domains is actually quite small. Extending this to use the instruction decoder
should be quite straight forward and less complex than doing a PCI config space
frontend/backend type thing. And it would make changes to guests smaller than
they already are in 2.x

rolf
> > A driver domain would still have to be co-operative in that
> > sense that it first starts out with a low privilege level (by default
a
> > domain would be created that way) to run into the exception handler
and
> > request to have its privilege level raised once it wants to access the
> raw
> > hardware. Setting the individual privilege bits for a driver domain
> might
> > be another possibility, but you''d  need to know the list of
ioports for
> > each possible device.
> 
> Right now we do just that: domains never get access to the PCI controller,
> so
> config space accesses must always be mediated by Xen.  Domains are
> assigned
> direct access to the devices they control using IO port bits (although
I''m
> not entirely happy with that, since it allows applications in the domain
> access to the device - fine for a driver domain but not good for
> partitioning
> the hardware) and controlled mapping of IO memory.
> 
> This works now because Xen can read the required IO port / memory ranges
> out
> of PCI config space and enable them as appropriate.  To make this work
> with
> the unstable tree, we''d need to have dom0''s kernel
somehow get this
> information out...
> 
> > > Using emulation to implement b) would have the advantage that the
> >
> > current
> >
> > > probing code shouldn''t need changing.  OTOH, the overall
system may be
> > > simpler if the guest detects it''s not allowed to access
the
> >
> > hardwaredirectly
> >
> > > and explicitly talks to dom0 e.g. using Xenstore to probe its
devices.
> >
> > I also think that it would have the advantage of being able to build a
> > user domain independently of whether it will become a driver domain or
> > not. All the difference would be in the virtualized PCI bus presenting
> > devices or being empty.
> 
> I definitely think we should retain the ability to build one kernel that
> works
> in all possible domains.  The startinfo does contain flags that tell the
> domain if it''s dom0 (and therefore controls the PCI bus) or not.
> 
> Cheers,
> Mark
> 
> >  Stefan
> >
> > > Cheers,
> > > Mark
> > >
> > > > I don''t get the purpose. What is wrong with hiding
certain PCI
> devices
> >
> > from
> >
> > > > DomO and thus make them available in domU?
> > > >
> > > > Btw, you are sure all OSes "find an empty bus"?
> > > >
> > > >
> > > > -----Ursprüngliche Nachricht-----
> > > > Von: Stefan Berger [mailto:stefanb@us.ibm.com]
> > > > Gesendet: Mittwoch, 3. August 2005 22:47
> > > > An: xen-devel@lists.xensource.com
> > > > Betreff: [Xen-devel] PCI bus emulation?
> > > >
> > > > Hello!
> > > >
> > > >   I have seen that the Qemu code contains some nice code for
PCI bus
> > > > emulation. I wonder whether this code could be reused in XEN
to fake
> a
> >
> > PCI
> >
> > > > bus by running the PCI emulation code in an exception
handler in the
> > > > hypervisor and setting a user domain''s IO privilege
level
> >
> > appropriately to
> >
> > > > have all inb/outb''s intercepted. This could have
potential benefits
> on
> >
> > the
> >
> > > > build process of user domains which could include the PCI
code when
> >
> > built,
> >
> > > > but that code when probing the PCI bus would only find an
empty bus
> >
> > and
> >
> > > > the probing of the drivers in the kernel would not start.
Maybe this
> >
> > code
> >
> > > > could also be used to support driver domains. Is this a good
idea?
> :-)
> > > >
> > > >   Stefan
> > > >
> > > >
> > > >
> > > >
> > > > _______________________________________________
> > > > Xen-devel mailing list
> > > > Xen-devel@lists.xensource.com
> > > > http://lists.xensource.com/xen-devel
> > > >
> > > > _______________________________________________
> > > > Xen-devel mailing list
> > > > Xen-devel@lists.xensource.com
> > > > http://lists.xensource.com/xen-devel
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

Mark Williamson

2005-Aug-05 00:11 UTC

head link

Re: AW: [Xen-devel] PCI bus emulation?

[hiding PCI devices]> A while back I had a look at this and it didn''t look as if it
would be very
> straight forward by just using arch specific code but probably doable using
> the hooks provided.
OK.  I personally think we could (one day) argue its utility to the PCI core 
but we probably don''t want to try and merge changes to that upstream at
the
same time.
> > > and maybe ''program'' the virtualized PCI bus of
a driver domain
> > > to show these devices (through sending a message to the HV about
what
> > > to present).
> >
> > I''d be inclined to have this purely implemented at kernel
level using
> > interdomain comms, rather than having Xen know anything about it.
>
> I''m not entirely convinced that this is the right way to do. Once
the
> devices are set up by dom0 xen wouldn''t have to do that much and
> intercepting pci config read/writes in xen using the instruction emulator
> might be better and create less dependencies on Dom0.
How would config space writes work?  Does Xen 3 understand enough about PCI to 
implement those itself?
> The code in Xen 2.x dealing with PCI config reads/writes by device driver
> domains is actually quite small. Extending this to use the instruction
> decoder should be quite straight forward and less complex than doing a PCI
> config space frontend/backend type thing. And it would make changes to
> guests smaller than they already are in 2.x
I did wonder if the PCI back/front could be implemented entirely using 
communications in the store - that could make them simpler.  Requiring no 
modifications to the read / write code would be a nice feature to have, 
though.

Cheers,
Mark
> rolf
>
> > > A driver domain would still have to be co-operative in that
> > > sense that it first starts out with a low privilege level (by
default a
> > > domain would be created that way) to run into the exception
handler and
> > > request to have its privilege level raised once it wants to
access the
> >
> > raw
> >
> > > hardware. Setting the individual privilege bits for a driver
domain
> >
> > might
> >
> > > be another possibility, but you''d  need to know the list
of ioports for
> > > each possible device.
> >
> > Right now we do just that: domains never get access to the PCI
> > controller, so
> > config space accesses must always be mediated by Xen.  Domains are
> > assigned
> > direct access to the devices they control using IO port bits (although
> > I''m not entirely happy with that, since it allows
applications in the
> > domain access to the device - fine for a driver domain but not good
for
> > partitioning
> > the hardware) and controlled mapping of IO memory.
> >
> > This works now because Xen can read the required IO port / memory
ranges
> > out
> > of PCI config space and enable them as appropriate.  To make this work
> > with
> > the unstable tree, we''d need to have dom0''s kernel
somehow get this
> > information out...
> >
> > > > Using emulation to implement b) would have the advantage
that the
> > >
> > > current
> > >
> > > > probing code shouldn''t need changing.  OTOH, the
overall system may
> > > > be simpler if the guest detects it''s not allowed to
access the
> > >
> > > hardwaredirectly
> > >
> > > > and explicitly talks to dom0 e.g. using Xenstore to probe
its
> > > > devices.
> > >
> > > I also think that it would have the advantage of being able to
build a
> > > user domain independently of whether it will become a driver
domain or
> > > not. All the difference would be in the virtualized PCI bus
presenting
> > > devices or being empty.
> >
> > I definitely think we should retain the ability to build one kernel
that
> > works
> > in all possible domains.  The startinfo does contain flags that tell
the
> > domain if it''s dom0 (and therefore controls the PCI bus) or
not.
> >
> > Cheers,
> > Mark
> >
> > >  Stefan
> > >
> > > > Cheers,
> > > > Mark
> > > >
> > > > > I don''t get the purpose. What is wrong with
hiding certain PCI
> >
> > devices
> >
> > > from
> > >
> > > > > DomO and thus make them available in domU?
> > > > >
> > > > > Btw, you are sure all OSes "find an empty
bus"?
> > > > >
> > > > >
> > > > > -----Ursprüngliche Nachricht-----
> > > > > Von: Stefan Berger [mailto:stefanb@us.ibm.com]
> > > > > Gesendet: Mittwoch, 3. August 2005 22:47
> > > > > An: xen-devel@lists.xensource.com
> > > > > Betreff: [Xen-devel] PCI bus emulation?
> > > > >
> > > > > Hello!
> > > > >
> > > > >   I have seen that the Qemu code contains some nice
code for PCI
> > > > > bus emulation. I wonder whether this code could be
reused in XEN to
> > > > > fake
> >
> > a
> >
> > > PCI
> > >
> > > > > bus by running the PCI emulation code in an exception
handler in
> > > > > the hypervisor and setting a user domain''s IO
privilege level
> > >
> > > appropriately to
> > >
> > > > > have all inb/outb''s intercepted. This could
have potential benefits
> >
> > on
> >
> > > the
> > >
> > > > > build process of user domains which could include the
PCI code when
> > >
> > > built,
> > >
> > > > > but that code when probing the PCI bus would only find
an empty bus
> > >
> > > and
> > >
> > > > > the probing of the drivers in the kernel would not
start. Maybe
> > > > > this
> > >
> > > code
> > >
> > > > > could also be used to support driver domains. Is this a
good idea?
> > :
> > :-)
> > :
> > > > >   Stefan
> > > > >
> > > > >
> > > > >
> > > > >
> > > > > _______________________________________________
> > > > > Xen-devel mailing list
> > > > > Xen-devel@lists.xensource.com
> > > > > http://lists.xensource.com/xen-devel
> > > > >
> > > > > _______________________________________________
> > > > > Xen-devel mailing list
> > > > > Xen-devel@lists.xensource.com
> > > > > http://lists.xensource.com/xen-devel
> >
> > _______________________________________________
> > Xen-devel mailing list
> > Xen-devel@lists.xensource.com
> > http://lists.xensource.com/xen-devel
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

Neugebauer, Rolf

2005-Aug-05 00:33 UTC

head link

RE: AW: [Xen-devel] PCI bus emulation?

> -----Original Message-----
> From: Mark Williamson [mailto:mark.williamson@cl.cam.ac.uk]
> Sent: 05 August 2005 01:11
> To: Neugebauer, Rolf
> Cc: Stefan Berger; Retzki, Sascha [Xplain]; xen-devel@lists.xensource.com
> Subject: Re: AW: [Xen-devel] PCI bus emulation?
> 
> [hiding PCI devices]
> > A while back I had a look at this and it didn''t look as if it
would be
> very
> > straight forward by just using arch specific code but probably doable
> using
> > the hooks provided.
> 
> OK.  I personally think we could (one day) argue its utility to the PCI
> core
> but we probably don''t want to try and merge changes to that
upstream at
> the
> same time.
> 
> > > > and maybe ''program'' the virtualized PCI
bus of a driver domain
> > > > to show these devices (through sending a message to the HV
about
> what
> > > > to present).
> > >
> > > I''d be inclined to have this purely implemented at
kernel level using
> > > interdomain comms, rather than having Xen know anything about it.
> >
> > I''m not entirely convinced that this is the right way to do.
Once the
> > devices are set up by dom0 xen wouldn''t have to do that much
and
> > intercepting pci config read/writes in xen using the instruction
> emulator
> > might be better and create less dependencies on Dom0.
> 
> How would config space writes work?  Does Xen 3 understand enough about
> PCI to
> implement those itself?
If I remember correctly in 2.0 we don''t allow writes to the config
space bu emulate them through very simple state machine. For normal linux guests
the only writes done through probing was the code which figured out the size of
the io memory regions, ie, read base, write all 1s, read again to find zeroed
bits and write back original base value (or something along those lines).

Obviously for this to work in Xen 3 xen would have to know a little about the
config space but once set up this should be relatively easy.

The other thing the backend/xen emulation would have to do is fake out some bus
"hierarchy" for device driver domains. Some of that code already
exists in 2.x
> > The code in Xen 2.x dealing with PCI config reads/writes by device
> driver
> > domains is actually quite small. Extending this to use the instruction
> > decoder should be quite straight forward and less complex than doing a
> PCI
> > config space frontend/backend type thing. And it would make changes to
> > guests smaller than they already are in 2.x
> 
> I did wonder if the PCI back/front could be implemented entirely using
> communications in the store - that could make them simpler.  Requiring no
> modifications to the read / write code would be a nice feature to have,
> though.
It''s a tradeoff and I think you can easily argue either way. I think
the crucial bit is the to find a clean solution for the dom0 issue. The config
space virtualization is probably reasonably straight forward either way.

rolf
> Cheers,
> Mark
> 
> > rolf
> >
> > > > A driver domain would still have to be co-operative in that
> > > > sense that it first starts out with a low privilege level
(by
> default a
> > > > domain would be created that way) to run into the exception
handler
> and
> > > > request to have its privilege level raised once it wants to
access
> the
> > >
> > > raw
> > >
> > > > hardware. Setting the individual privilege bits for a driver
domain
> > >
> > > might
> > >
> > > > be another possibility, but you''d  need to know the
list of ioports
> for
> > > > each possible device.
> > >
> > > Right now we do just that: domains never get access to the PCI
> > > controller, so
> > > config space accesses must always be mediated by Xen.  Domains
are
> > > assigned
> > > direct access to the devices they control using IO port bits
(although
> > > I''m not entirely happy with that, since it allows
applications in the
> > > domain access to the device - fine for a driver domain but not
good
> for
> > > partitioning
> > > the hardware) and controlled mapping of IO memory.
> > >
> > > This works now because Xen can read the required IO port / memory
> ranges
> > > out
> > > of PCI config space and enable them as appropriate.  To make this
work
> > > with
> > > the unstable tree, we''d need to have dom0''s
kernel somehow get this
> > > information out...
> > >
> > > > > Using emulation to implement b) would have the
advantage that the
> > > >
> > > > current
> > > >
> > > > > probing code shouldn''t need changing.  OTOH,
the overall system
> may
> > > > > be simpler if the guest detects it''s not
allowed to access the
> > > >
> > > > hardwaredirectly
> > > >
> > > > > and explicitly talks to dom0 e.g. using Xenstore to
probe its
> > > > > devices.
> > > >
> > > > I also think that it would have the advantage of being able
to build
> a
> > > > user domain independently of whether it will become a driver
domain
> or
> > > > not. All the difference would be in the virtualized PCI bus
> presenting
> > > > devices or being empty.
> > >
> > > I definitely think we should retain the ability to build one
kernel
> that
> > > works
> > > in all possible domains.  The startinfo does contain flags that
tell
> the
> > > domain if it''s dom0 (and therefore controls the PCI bus)
or not.
> > >
> > > Cheers,
> > > Mark
> > >
> > > >  Stefan
> > > >
> > > > > Cheers,
> > > > > Mark
> > > > >
> > > > > > I don''t get the purpose. What is wrong
with hiding certain PCI
> > >
> > > devices
> > >
> > > > from
> > > >
> > > > > > DomO and thus make them available in domU?
> > > > > >
> > > > > > Btw, you are sure all OSes "find an empty
bus"?
> > > > > >
> > > > > >
> > > > > > -----Ursprüngliche Nachricht-----
> > > > > > Von: Stefan Berger [mailto:stefanb@us.ibm.com]
> > > > > > Gesendet: Mittwoch, 3. August 2005 22:47
> > > > > > An: xen-devel@lists.xensource.com
> > > > > > Betreff: [Xen-devel] PCI bus emulation?
> > > > > >
> > > > > > Hello!
> > > > > >
> > > > > >   I have seen that the Qemu code contains some
nice code for PCI
> > > > > > bus emulation. I wonder whether this code could be
reused in XEN
> to
> > > > > > fake
> > >
> > > a
> > >
> > > > PCI
> > > >
> > > > > > bus by running the PCI emulation code in an
exception handler in
> > > > > > the hypervisor and setting a user
domain''s IO privilege level
> > > >
> > > > appropriately to
> > > >
> > > > > > have all inb/outb''s intercepted. This
could have potential
> benefits
> > >
> > > on
> > >
> > > > the
> > > >
> > > > > > build process of user domains which could include
the PCI code
> when
> > > >
> > > > built,
> > > >
> > > > > > but that code when probing the PCI bus would only
find an empty
> bus
> > > >
> > > > and
> > > >
> > > > > > the probing of the drivers in the kernel would not
start. Maybe
> > > > > > this
> > > >
> > > > code
> > > >
> > > > > > could also be used to support driver domains. Is
this a good
> idea?
> > > :
> > > :-)
> > > :
> > > > > >   Stefan
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > > _______________________________________________
> > > > > > Xen-devel mailing list
> > > > > > Xen-devel@lists.xensource.com
> > > > > > http://lists.xensource.com/xen-devel
> > > > > >
> > > > > > _______________________________________________
> > > > > > Xen-devel mailing list
> > > > > > Xen-devel@lists.xensource.com
> > > > > > http://lists.xensource.com/xen-devel
> > >
> > > _______________________________________________
> > > Xen-devel mailing list
> > > Xen-devel@lists.xensource.com
> > > http://lists.xensource.com/xen-devel
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

Mark Williamson

2005-Aug-05 00:40 UTC

head link

Re: AW: [Xen-devel] PCI bus emulation?

> > How would config space writes work?  Does Xen 3 understand enough
about
> > PCI to
> > implement those itself?
>
> If I remember correctly in 2.0 we don''t allow writes to the config
space bu
> emulate them through very simple state machine.
IIRC we only emulate those for those parts of config space that describe the 
locations of IO registers - other parts of the config space aren''t 
standardised so we have to pass them through.

Cheers,
Mark

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

Xen devel - Aug 2005 - AW: PCI bus emulation?

AW: [Xen-devel] PCI bus emulation?

Re: AW: [Xen-devel] PCI bus emulation?

Re: AW: [Xen-devel] PCI bus emulation?

Re: AW: [Xen-devel] PCI bus emulation?

RE: AW: [Xen-devel] PCI bus emulation?

Re: AW: [Xen-devel] PCI bus emulation?

RE: AW: [Xen-devel] PCI bus emulation?

Re: AW: [Xen-devel] PCI bus emulation?