Couldn''t we approach it from a different perspective - the host drivers
that
we can modify could be changed to start with a higher memory address, like
(if we had a 512MB card) 256MB-xx and the unmodified drivers could use
0-256MB and be "told" that they have 256 MB. In other words, we could
let
the drivers work unmodified but use less memory so that we have some still
available for the host.
>* -----Original Message-----*
>* From: xen-users-bounces@xxxxxxxxxxxxxxxxxxx *
>* [mailto:xen-users-bounces@xxxxxxxxxxxxxxxxxxx
<xen-users-bounces@xxxxxxxxxxxxxxxxxxx>] On Behalf Of
*>* David Shirley*
>* Sent: 08 August 2006 06:14*
>* To: xen-users@xxxxxxxxxxxxxxxxxxx*
>* Subject: RE: [Xen-users] 3D acceleration*
>* *
>* Very clear explanation there - :)*
>* *
>* However could this all be solved if the graphics card driver just*
>* asked for the correct address?*
>* *
>* ie if Nvidia added Xen Aware windows drivers and you
"passthroughed"*
>* your VGA card to domU then it *should just work*?*
Assuming we first implement the necessary features for a Xen-aware
driver to talk to Xen, yes, it can be done. There is some work right now
to support Linux drivers that are Xen-aware in an otherwise unmodified
Linux. As far as I''m aware, no work yet for Windows. And the drivers
that have been worked on so far are relatively easy drivers, Network and
Disk drivers, that have Back-end/Front-end drivers.
Note that it''s not just a case of asking for the base of the memory
once
either. My example below is very much simplified. In a real Xen system,
you could very well have every single 4KB page come from a different
place in memory. So it''s not as simple as "memory starts at
256MB" -
that''s just to illustrate that the memory of DomU isn''t quite
where it
thinks itself to be. [It''s still true that the guest thinks that memory
starts at 0 and goes to whatever size we''ve given it - it''s
just that
that memory behind the scenes could be just ANYWHERE].
To further complicate things, a graphics driver will often send complex
commands that contain addresses of main memory inside the command. So
for example, a bitblt command to copy pixels to the screen from main
memory would contain the address of the source bitmap to copy. There are
probably hundreds if not thousands of places where the graphics driver
needs to know the REAL physical address and pass it along to a the
graphics card - of course, it already has some sort of call to the OS to
do this, so replacing that should do the trick [at least, we presume
they are well-behaved programmers and they don''t go walking the
page-table by hand!]
--
Mats>* *
>* Cheers*
>* Dave*
>* *
>* --snip--*
>* You don''t have to have a Xenified driver if there is an IOMMU in
the*
>* system. But those don''t exist today in most systems (IBM has one,
but*
>* it''s only used in LARGE multiprocessor systems - and
there''s no*
>* support in Xen for it anyways - yet at least).*
>* *
>* So to explain why:*
>* *
>* Let''s say you have a Dom0 that has 256MB of memory, and a DomU
that*
>* also has 256MB of memory.*
>* *
>* The DomU will think that the memory starts at zero, because Xen will*
>* fake the memory configuration for the domain when it''s starting.
There*
>* are mechanisms (called shadow-paging) to hide the actual memory*
>* configuration from the guest, and the guest _WILL_ believe that
it''s*
>* got memory from 0 ... 256MB.*
>* *
>* Now, the driver for the graphics card will be given a bitmap in*
>* user-memory to draw to the video-card. Since we assume this is a*
>* "fancy" graphics card, it can do direct memory access (DMA) from
the*
>* main memory into the video-memory. So the driver will just say "at*
>* address XXXXX you can find a bitmap, please DMA it into video memory*
>* at address YYYYY". However, XXXXX is a PHYSICAL address within the*
>* guest memory - but the ACTUAL physical address that the guest
doesn''t*
>* know about is 256MB + XXXXX. But neither the guest, nor the graphcis*
>* card knows that the Guest address is not ACTUAL physical address... So*
>* what gets drawn to your screen in this case, would be whatever is at*
>* physical address XXXXX - not the INTENDED XXXXX+256MB - and
you''ll*
>* probably find that at XXXXX is some completely different type of data,*
>* so the screen will look like someone spilt a bunch of mixed pixels and*
>* swept them up into a pile... Or put another way, rubbish will appear*
>* on the screen.*
>* *
>* Does that make it clear?*
>* *
>* --*
>* Mats*
>* *
>* _______________________________________________*
>* Xen-users mailing list*
>* Xen-users@xxxxxxxxxxxxxxxxxxx*
>* http://lists.xensource.com/xen-users*
>* *
>* *
>* *
_______________________________________________
Xen-users mailing list
Xen-users@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-users
_______________________________________________
Xen-users mailing list
Xen-users@lists.xensource.com
http://lists.xensource.com/xen-users
