Xen devel - Feb 2012 - [PATCH] Automatically select 0xe9 as default debug port if configured for Xen

As per Ian comment on previous commit 7123d9834d58287d43514d7799ed1a7b34eea243

Signed-off-by: Julian Pidancet <julian.pidancet@gmail.com>
---
 src/Kconfig |    1 +
 1 files changed, 1 insertions(+), 0 deletions(-)

diff --git a/src/Kconfig b/src/Kconfig
index cf0bff0..cee0005 100644
--- a/src/Kconfig
+++ b/src/Kconfig
@@ -361,6 +361,7 @@ menu "Debugging"
     config DEBUG_IO_PORT
         depends on DEBUG_IO
         hex "Debug IO port address"
+        default 0x00e9 if XEN
         default 0x0402
         help
             Bochs uses the 0x0402 address by default, whereas Xen
-- 
Julian Pidancet

On Sun, Feb 05, 2012 at 12:46:58AM +0000, Julian Pidancet
wrote:
> As per Ian comment on previous commit
7123d9834d58287d43514d7799ed1a7b34eea243
> 
> Signed-off-by: Julian Pidancet <julian.pidancet@gmail.com>
> ---
>  src/Kconfig |    1 +
>  1 files changed, 1 insertions(+), 0 deletions(-)
> 
> diff --git a/src/Kconfig b/src/Kconfig
> index cf0bff0..cee0005 100644
> --- a/src/Kconfig
> +++ b/src/Kconfig
> @@ -361,6 +361,7 @@ menu "Debugging"
>      config DEBUG_IO_PORT
>          depends on DEBUG_IO
>          hex "Debug IO port address"
> +        default 0x00e9 if XEN
>          default 0x0402
>          help
>              Bochs uses the 0x0402 address by default, whereas Xen
Setting of default values doesn''t work well when done this way.  To
test, run "make menuconfig" select a build without xen, and run make.
You''ll see out/autoconf.h has DEBUG_IO_PORT=0x402.  Then run "make
menuconfig" select xen, and run make.  You''ll still see
DEBUG_IO_PORT=0x402.

You can look at VGA_VID in vgasrc/Kconfig for one possible solution to
the above.

-Kevin

I recently read about Xen3D and the whole idea of API remoting for 
graphics is new to me, so that''s the level I''m coming from. 
My question
is as follows:
I understand that graphics passthrough only works for HVM DomUs, with 
that being said most of the driver domains I read about for networking 
are paravirtualized with a passed through NIC.  Is there any work being 
done to introduce the concept of a HVM-based Driver Domain, so that one 
can pass a GPU through?  If so, would it not be faster to remote the API 
through to the Driver Domain hosting the GPU with a Xenbus form of 
communication?  My concern, other than the fact that I don''t understand
a thing about how Xenbus and other drivers work, is that there wouldn''t
be the throughput needed to provide any better support than is currently 
handled by the virtual framebuffer.  I know that that kind of 
communication handles all block-level and network traffic, but the 
amount of data required to drive a GPU would be much more.  Am I barking 
up the wrong tree, or is this a project that would benefit the 
community?

Mike

On Sun, Feb 5, 2012 at 1:56 AM, Kevin O'Connor <kevin@koconnor.net>
wrote:
> On Sun, Feb 05, 2012 at 12:46:58AM +0000, Julian Pidancet wrote:
>> As per Ian comment on previous commit
7123d9834d58287d43514d7799ed1a7b34eea243
>>
>> Signed-off-by: Julian Pidancet <julian.pidancet@gmail.com>
>> ---
>>  src/Kconfig |    1 +
>>  1 files changed, 1 insertions(+), 0 deletions(-)
>>
>> diff --git a/src/Kconfig b/src/Kconfig
>> index cf0bff0..cee0005 100644
>> --- a/src/Kconfig
>> +++ b/src/Kconfig
>> @@ -361,6 +361,7 @@ menu "Debugging"
>>      config DEBUG_IO_PORT
>>          depends on DEBUG_IO
>>          hex "Debug IO port address"
>> +        default 0x00e9 if XEN
>>          default 0x0402
>>          help
>>              Bochs uses the 0x0402 address by default, whereas Xen
>
> Setting of default values doesn't work well when done this way.  To
> test, run "make menuconfig" select a build without xen, and run
make.
> You'll see out/autoconf.h has DEBUG_IO_PORT=0x402.  Then run "make
> menuconfig" select xen, and run make.  You'll still see
> DEBUG_IO_PORT=0x402.
>
> You can look at VGA_VID in vgasrc/Kconfig for one possible solution to
> the above.
>
> -Kevin
I tried to use the same technique as you used in vgasrc/Kconfig:

    config DEBUG_IO
        depends on !COREBOOT && DEBUG_LEVEL != 0
        bool "Special IO port debugging"
        default y
        help
            Some emulators or hypervisors provide with a way to output debug
            information by outputing strings in a special port present in the
            IO space.

    choice
        depends on DEBUG_IO
        prompt "Debug IO port address"
        default DEBUG_IO_PORT_XEN if XEN
        default DEBUG_IO_PORT_BOCHS

        config DEBUG_IO_PORT_BOCHS
            bool "0x402 (Bochs)"
        config DEBUG_IO_PORT_XEN
            bool "0xe9 (Xen)"
        config DEBUG_IO_PORT_CUSTOM
            bool "Custom"
    endchoice

    config DEBUG_IO_PORT
        hex
        prompt "Debug IO port address" if DEBUG_IO_PORT_CUSTOM
        default 0x0402 if DEBUG_IO_PORT_BOCHS
        default 0x00e9 if DEBUG_IO_PORT_XEN
        default 0x0000
        help
            Bochs uses the 0x0402 address by default, whereas Xen
            makes the 0xe9 IO address available for guests use.


Unfortunately, it still seem subject to the same issue. Is there
anything I am missing here ?

-- 
Julian

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

On Sun, Feb 5, 2012 at 3:38 AM, Michael A. Collins
<mike.a.collins@ark-net.org> wrote:
> I recently read about Xen3D and the whole idea of API remoting for graphics
> is new to me, so that''s the level I''m coming from.  My
question is as
> follows:
I''m not sure anyone here is currently working on API remoting.  It
sounds like you''re perhaps suggesting making a new PV frontend/backend
protocol, similar to blockback/front, netback/front, pvscsi, pvusb,
and so on, which would do 3D graphics processing on behalf of guests.
Is that correct?

It sounds like it could be useful to me.  Are you volunteering to
develop such a protocol? :-)
> I understand that graphics passthrough only works for HVM DomUs, with that
> being said most of the driver domains I read about for networking are
> paravirtualized with a passed through NIC.  Is there any work being done to
> introduce the concept of a HVM-based Driver Domain, so that one can pass a
> GPU through?
AIUI, there''s no Xen limitation for an HVM guest to be a driver
domain; the main limitation is for the guest to have backend support
when running in HVM mode.  I''m told the work for this has already been
done, and should be available in Linux 3.3 when it comes out.  But I''m
sure you can find the patch series if you''re interested.
>  If so, would it not be faster to remote the API through to the
> Driver Domain hosting the GPU with a Xenbus form of communication?
xenbus is not for transmitting bulk data, but configuration
parameters.  The standard method in Xen for transmitting bulk data is
to use xenbus to establish and tear down the communication channels
(shared rings and event channels); the shared rings are used to pass
requests, and the requests contain references to pages that the
frontend wants the backend to operate on directly (the PV equivalent
of DMA).  If you''re interested in developing a protocol, it might be
worth looking at the existing protocols, like the network and block
protocols.

 -George
>   My
> concern, other than the fact that I don''t understand a thing about
how
> Xenbus and other drivers work, is that there wouldn''t be the
throughput
> needed to provide any better support than is currently handled by the
> virtual framebuffer.  I know that that kind of communication handles all
> block-level and network traffic, but the amount of data required to drive a
> GPU would be much more.  Am I barking up the wrong tree, or is this a
> project that would benefit the community?
>
> Mike
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel

On 08.02.2012 06:53, George Dunlap wrote:
> On Sun, Feb 5, 2012 at 3:38 AM, Michael A. Collins
> <mike.a.collins@ark-net.org> wrote:
>> I recently read about Xen3D and the whole idea of API remoting for 
>> graphics
>> is new to me, so that's the level I'm coming from.  My question
is
>> as
>> follows:
>
> I'm not sure anyone here is currently working on API remoting.  It
> sounds like you're perhaps suggesting making a new PV 
> frontend/backend
> protocol, similar to blockback/front, netback/front, pvscsi, pvusb,
> and so on, which would do 3D graphics processing on behalf of guests.
> Is that correct?
>
> It sounds like it could be useful to me.  Are you volunteering to
> develop such a protocol? :-)
>
That I am.  Excuse me while I lock myself away for a while and ponder 
what I've just gotten myself into.
Mike

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