Thank you very much - I guess I completly understand this now.
Then the para-virtual interface and a modified nvidia-driver (for example)
would be enough to make it possible to access the an nvidia graphic card on
hardware levels and use DirectX and OpenGL and all of it.
I heard nvidia has interesting on this, so one day we will get this ability?
Petersson, Mats wrote:
>> -----Original Message-----
>> From: Georg Bege [mailto:therion@xxxxxxxxxxxx]
>> Sent: 04 September 2006 12:44
>> To: Petersson, Mats
>> Subject: Re: [Xen-users] unmodified guests (VMX?) access PCI devices
>>
> Yeah ok I understand that - I already read about that.
> What do you think, isnt it possible to write a code/plugin/whatever
> which maps the real memory access to the guest OS?
> Kind of translator.
> Please understand I only speak of theoretics I've not enough C(++)
> knowledge
> to know if this could work out or is completly impossible.
>
> > Not trivially. If you have the source-code for the driver, then it's not
> > very hard (it's still driver-writing work, so it's Tricky Stuff(tm), but
> > not at the same level as if you don't have the source for the driver).
>
> > If you don't have the source for the driver (and not for the OS either,
> > obviously), then you'd have to patch the OS in runtime, which is neither
> > a good thing to do, nor is it reliable (it tends to break every time a
> > new OS comes out). Another problem would be the qualification of who
> > would get to see "machine physical" and "guest physical". If you change
> > the "GetPhysicalAddress()" in Windows so that it always returns machine
> > physical, the driver that does IDE access to the emulated IDE drive in
> > QEMU would stop working, since that relies on the address being guest
> > physical. Same with any other driver talking to QEMU, naturally. A
> > further complication would be if there are other uses of
> > GetPhysicalAddress() in the Windows kernel which are relying on getting
> > a guest-physical address.
>
> > It would probably be necessary to make a new system-call (which of
> > course isn't possible in Windows without lots of extra work).
>
> > With a para-virtual interface, which is in the works (in fact, I think
> > it is in Xen unstable/3.0.3), it would be possible to get the
> > information about machine physical address, but it would require access
> > to the driver(s) involved.
>
> > Note that for example SCSI and USB drivers are hierarchical (stacked),
> > so one driver sits on top of another that sits on top of a base-driver.
> > The entire stack needs to understand that the world "isn't what it
> > appears to be".
>
> > --
> > Mats
> thanks very much for your answer
>
> cheers
>
> Georg Bege
>
> Petersson, Mats wrote:
> >>>
> >>>> -----Original Message----- From:
> >>>> xen-users-bounces@xxxxxxxxxxxxxxxxxxx
> >>>> [mailto:xen-users-bounces@xxxxxxxxxxxxxxxxxxx] On Behalf Of Georg
> >>>> Bege Sent: 01 September 2006 19:39 To:
> >>>> xen-users@xxxxxxxxxxxxxxxxxxx Subject: [Xen-users] unmodified
> >>>> guests (VMX?) access PCI devices
> >>>>
> >>> Hello folks
> >>>
> >>> I played a lot with Xen last days, isnt it possible to access PCI
> >>> devices which are hidden from dom0?
> >>>
> >>>> There's no support currently for this. It's not TERRIBLY
> >>>> difficult to implement the bit that forwards the PCI device to
> >>>> the HVM domain.
> >>>> There's a but tho': it's non-trivial to make it work further on,
> >>> because
> >>>> drivers will (almost) always pass a physical address to the card.
> >>>>
> >>> But in
> >>>> a HVM domain the OS's view of a physical address isn't the
> >>>> Machine Physical Address but a "virtual physical address" (aka
> >>>> Guest Physical Address). If your PCI device is anything like a
> >>>> network card, SCSI controller or graphics card, it will do direct
> >>>> memory accesses
> >>> from the
> >>>> card to physical memory, and in the current model, that would
> >>> require a
> >>>> machine-physical address, which isn't available to the driver/OS
> >>> in HVM
> >>>> setup.
> >>>> I hope this is clear, but feel free to ask for further details if
> >>>> you wish.
> >>> I didnt get it - at least my windows domain didnt get it.
> >>>
> >>> Another question: Im using hvmloader but many pages also talk about
> >>> the vmxloader, was it prior the hvmloader coz it doesnt exist
> >>> anymore?
> >>>
> >>>> Yes, vmxloader used to be the name for hvmloader before HVM was
> >>> invented
> >>>> (i.e. at the time when Xen only had VT support and no SVM
> >>>> support).
> >>>> -- Mats
> >>> cheers
> >>>
> >>> -- Georg 'Therion' Bege http://coruscant.info
> >>> http://www.ninth-art.de therion@xxxxxxxxxxxx <therion at ninth
> >>> minus art dot de> GnuPG-Key-ID: 0x5717E214 FingerPrint: A8EC B4B2
> >>> C9A9 483B CC87 56EE 07A1 C78E 5717 E214
> >>>
> >>>>>
> >>> _______________________________________________ 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
> >>>
> >>>
> >>> -- Georg 'Therion' Bege http://coruscant.info
> >>> http://www.ninth-art.de therion@xxxxxxxxxxxx <therion at ninth
> >>> minus art dot de> GnuPG-Key-ID: 0x5717E214 FingerPrint: A8EC B4B2
> >>> C9A9 483B CC87 56EE 07A1 C78E 5717 E214
> >>>
> >>
> >>
> >>
> >>
>
> > !DSPAM:44fc2710116921572714296!
>
>
>
> --
> Georg 'Therion' Bege
> http://coruscant.info
> http://www.ninth-art.de
> therion@xxxxxxxxxxxx <therion at ninth minus art dot de>
> GnuPG-Key-ID: 0x5717E214
> FingerPrint: A8EC B4B2 C9A9 483B CC87 56EE 07A1 C78E 5717 E214
>
_______________________________________________
Xen-users mailing list
Xen-users@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-users
|
Home