frame buffer shared by domains on arch arm linux

frame buffer shared by domains on arch arm linux

[Mao Mingy]

I am trying to run the PVHVM guest on omap5 (arm arch) so that I can get 
the frame buffer shared by Domains. my setup are:
1. run xen4.5 after the u-boot.
2. start the dom0 (on linux kernel 3.12) on xen.
3. run the qemu (from xen 4.5) and HVM backend on xen.
4. run the guest domain as "Machine: Dummy Virtual Machine, model: 
XENVM-4.5"
5. try to build a frame buffer on guest domain by
     CONFIG_XEN_FBDEV_FRONTEND = y
     CONFIG_FB_VIRTUAL=y

after change to domain checking in the first list of xenfb_init(...) in 
xen-fbfront.c from
     if (!xen_pv_domain()) --->    if (!xen_domain())
the /dev/fb0 is built up on guest domain. However, writing to this fb 
has no response from screen.

Why xenfb_init limited to PV domain only?

Is the PVHVM mode supported by xen4.5 and linux3.12?

Looks at the xen.h at the linux kernel source:
enum xen_domain_type {
     XEN_NATIVE,        /* running on bare hardware    */
     XEN_PV_DOMAIN,        /* running in a PV domain      */
     XEN_HVM_DOMAIN,        /* running in a Xen hvm domain */
};
seems PVHVM is not there yet?

Kindly enlighten me what could be the solution to get the frame buffer 
shared by Domains?

Regards,
Mao Mingya

Re: frame buffer shared by domains on arch arm linux

[Stefano Stabellini]

On Wed, 21 Jan 2015, Mao Mingy wrote:
> I am trying to run the PVHVM guest on omap5 (arm arch) so that I can get the
> frame buffer shared by Domains. my setup are:
> 1. run xen4.5 after the u-boot.
> 2. start the dom0 (on linux kernel 3.12) on xen.

3.12 is pretty old now


> 3. run the qemu (from xen 4.5) and HVM backend on xen.

Is this the QEMU binary that gets compiled as part of the Xen 4.5 build
and started automatically by xl if you configure the VM with a
framebuffer?


> 4. run the guest domain as "Machine: Dummy Virtual Machine, model: XENVM-4.5"
> 5. try to build a frame buffer on guest domain by
>     CONFIG_XEN_FBDEV_FRONTEND = y
>     CONFIG_FB_VIRTUAL=y
> 
> after change to domain checking in the first list of xenfb_init(...) in
> xen-fbfront.c from
>     if (!xen_pv_domain()) --->    if (!xen_domain())
> the /dev/fb0 is built up on guest domain. However, writing to this fb has no
> response from screen.
> 
> Why xenfb_init limited to PV domain only?

No it is not. In fact if you use a more recent Linux kernel, you won't
need to make any modifications and it should work out of the box.


> Is the PVHVM mode supported by xen4.5 and linux3.12?

We don't call "PVHVM" guests on ARM: on ARM we only have one type of
guest. From the Linux kernel perspective, they are HVM domains.


> Looks at the xen.h at the linux kernel source:
> enum xen_domain_type {
>     XEN_NATIVE,        /* running on bare hardware    */
>     XEN_PV_DOMAIN,        /* running in a PV domain      */
>     XEN_HVM_DOMAIN,        /* running in a Xen hvm domain */
> };
> seems PVHVM is not there yet?

In this context PVHVM would just be XEN_PV_DOMAIN.


> Kindly enlighten me what could be the solution to get the frame buffer shared
> by Domains?

It should work out of the box with the latest Linux kernel and Xen 4.5,
if you add

vfb=['vnc=1']

to the VM config file.

Re: frame buffer shared by domains on arch arm linux

[Mao Mingy]

On 21/01/2015 18:51, Stefano Stabellini wrote:
> On Wed, 21 Jan 2015, Mao Mingy wrote:
>> I am trying to run the PVHVM guest on omap5 (arm arch) so that I can get the
>> frame buffer shared by Domains. my setup are:
>> 1. run xen4.5 after the u-boot.
>> 2. start the dom0 (on linux kernel 3.12) on xen.
> 3.12 is pretty old now
>
>
>> 3. run the qemu (from xen 4.5) and HVM backend on xen.
> Is this the QEMU binary that gets compiled as part of the Xen 4.5 build
> and started automatically by xl if you configure the VM with a
> framebuffer?
Yes. it's compiled from Xen 4.5. exact location @ " 
./xen_4.5/dist/install/usr/local/lib/xen/bin/qemu-system-i386 "
>> 4. run the guest domain as "Machine: Dummy Virtual Machine, model: XENVM-4.5"
>> 5. try to build a frame buffer on guest domain by
>>      CONFIG_XEN_FBDEV_FRONTEND = y
>>      CONFIG_FB_VIRTUAL=y
>>
>> after change to domain checking in the first list of xenfb_init(...) in
>> xen-fbfront.c from
>>      if (!xen_pv_domain()) --->    if (!xen_domain())
>> the /dev/fb0 is built up on guest domain. However, writing to this fb has no
>> response from screen.
>>
>> Why xenfb_init limited to PV domain only?
> No it is not. In fact if you use a more recent Linux kernel, you won't
> need to make any modifications and it should work out of the box.
Thanks. Check the latest kernel source. it's already modified to if 
(!xen_domain())
>> Is the PVHVM mode supported by xen4.5 and linux3.12?
> We don't call "PVHVM" guests on ARM: on ARM we only have one type of
> guest. From the Linux kernel perspective, they are HVM domains.
>
>
>> Looks at the xen.h at the linux kernel source:
>> enum xen_domain_type {
>>      XEN_NATIVE,        /* running on bare hardware    */
>>      XEN_PV_DOMAIN,        /* running in a PV domain      */
>>      XEN_HVM_DOMAIN,        /* running in a Xen hvm domain */
>> };
>> seems PVHVM is not there yet?
> In this context PVHVM would just be XEN_PV_DOMAIN.
>
>
>> Kindly enlighten me what could be the solution to get the frame buffer shared
>> by Domains?
> It should work out of the box with the latest Linux kernel and Xen 4.5,
> if you add
>
> vfb=['vnc=1']
>
> to the VM config file.
Unfortunately, It's still no work after add the vfb=[ 'vnc=1' ]. fb 
open/write/ioctl/close from guest
linux user space program return no error. However, just the screen do 
NOT display the contents wrote to vfb.
Here is the configuration file when create the guest linux

kernel = "/xen/images/zImage"
memory = "128"
name = "omap5"
bootargs = "mem=128M vram=16M xencons=hvc"
vcpus = 1
extra ="console=hvc0 xencons=hvc root=/dev/xvda ro"
disk = [ 'phy:/dev/loop0,xvda,w' ]
vfb=['vnc=1']

Kindly advise what could be the reason?

Re: frame buffer shared by domains on arch arm linux

[Stefano Stabellini]

On Thu, 22 Jan 2015, Mao Mingy wrote:
> On 21/01/2015 18:51, Stefano Stabellini wrote:
> > On Wed, 21 Jan 2015, Mao Mingy wrote:
> > > I am trying to run the PVHVM guest on omap5 (arm arch) so that I can get
> > > the
> > > frame buffer shared by Domains. my setup are:
> > > 1. run xen4.5 after the u-boot.
> > > 2. start the dom0 (on linux kernel 3.12) on xen.
> > 3.12 is pretty old now
> > 
> > 
> > > 3. run the qemu (from xen 4.5) and HVM backend on xen.
> > Is this the QEMU binary that gets compiled as part of the Xen 4.5 build
> > and started automatically by xl if you configure the VM with a
> > framebuffer?
> Yes. it's compiled from Xen 4.5. exact location @ "
> ./xen_4.5/dist/install/usr/local/lib/xen/bin/qemu-system-i386 "
> > > 4. run the guest domain as "Machine: Dummy Virtual Machine, model:
> > > XENVM-4.5"
> > > 5. try to build a frame buffer on guest domain by
> > >      CONFIG_XEN_FBDEV_FRONTEND = y
> > >      CONFIG_FB_VIRTUAL=y
> > > 
> > > after change to domain checking in the first list of xenfb_init(...) in
> > > xen-fbfront.c from
> > >      if (!xen_pv_domain()) --->    if (!xen_domain())
> > > the /dev/fb0 is built up on guest domain. However, writing to this fb has
> > > no
> > > response from screen.
> > > 
> > > Why xenfb_init limited to PV domain only?
> > No it is not. In fact if you use a more recent Linux kernel, you won't
> > need to make any modifications and it should work out of the box.
> Thanks. Check the latest kernel source. it's already modified to if
> (!xen_domain())
> > > Is the PVHVM mode supported by xen4.5 and linux3.12?
> > We don't call "PVHVM" guests on ARM: on ARM we only have one type of
> > guest. From the Linux kernel perspective, they are HVM domains.
> > 
> > 
> > > Looks at the xen.h at the linux kernel source:
> > > enum xen_domain_type {
> > >      XEN_NATIVE,        /* running on bare hardware    */
> > >      XEN_PV_DOMAIN,        /* running in a PV domain      */
> > >      XEN_HVM_DOMAIN,        /* running in a Xen hvm domain */
> > > };
> > > seems PVHVM is not there yet?
> > In this context PVHVM would just be XEN_PV_DOMAIN.
> > 
> > 
> > > Kindly enlighten me what could be the solution to get the frame buffer
> > > shared
> > > by Domains?
> > It should work out of the box with the latest Linux kernel and Xen 4.5,
> > if you add
> > 
> > vfb=['vnc=1']
> > 
> > to the VM config file.
> Unfortunately, It's still no work after add the vfb=[ 'vnc=1' ]. fb
> open/write/ioctl/close from guest
> linux user space program return no error. However, just the screen do NOT
> display the contents wrote to vfb.
> Here is the configuration file when create the guest linux
> 
> kernel = "/xen/images/zImage"
> memory = "128"
> name = "omap5"
> bootargs = "mem=128M vram=16M xencons=hvc"
> vcpus = 1
> extra ="console=hvc0 xencons=hvc root=/dev/xvda ro"

You might want to use console=tty0 if you want to see the kernel output on the framebuffer.

> disk = [ 'phy:/dev/loop0,xvda,w' ]
> vfb=['vnc=1']
> 
> Kindly advise what could be the reason?

Do you have

CONFIG_XEN_FBDEV_FRONTEND=y
CONFIG_INPUT_XEN_KBDDEV_FRONTEND=y
CONFIG_FRAMEBUFFER_CONSOLE=y

in your guest kernel config?

Could you please post the output of xenstore-ls, executing the command
after creating the VM?

Re: frame buffer shared by domains on arch arm linux

[Mao Mingy]

[-- Attachment #1.1: Type: text/plain, Size: 4966 bytes --]


On 22/01/2015 19:56, Stefano Stabellini wrote:
> On Thu, 22 Jan 2015, Mao Mingy wrote:
>> On 21/01/2015 18:51, Stefano Stabellini wrote:
>>> On Wed, 21 Jan 2015, Mao Mingy wrote:
>>>> I am trying to run the PVHVM guest on omap5 (arm arch) so that I can get
>>>> the
>>>> frame buffer shared by Domains. my setup are:
>>>> 1. run xen4.5 after the u-boot.
>>>> 2. start the dom0 (on linux kernel 3.12) on xen.
>>> 3.12 is pretty old now
>>>
>>>
>>>> 3. run the qemu (from xen 4.5) and HVM backend on xen.
>>> Is this the QEMU binary that gets compiled as part of the Xen 4.5 build
>>> and started automatically by xl if you configure the VM with a
>>> framebuffer?
>> Yes. it's compiled from Xen 4.5. exact location @ "
>> ./xen_4.5/dist/install/usr/local/lib/xen/bin/qemu-system-i386 "
>>>> 4. run the guest domain as "Machine: Dummy Virtual Machine, model:
>>>> XENVM-4.5"
>>>> 5. try to build a frame buffer on guest domain by
>>>>       CONFIG_XEN_FBDEV_FRONTEND = y
>>>>       CONFIG_FB_VIRTUAL=y
>>>>
>>>> after change to domain checking in the first list of xenfb_init(...) in
>>>> xen-fbfront.c from
>>>>       if (!xen_pv_domain()) --->    if (!xen_domain())
>>>> the /dev/fb0 is built up on guest domain. However, writing to this fb has
>>>> no
>>>> response from screen.
>>>>
>>>> Why xenfb_init limited to PV domain only?
>>> No it is not. In fact if you use a more recent Linux kernel, you won't
>>> need to make any modifications and it should work out of the box.
>> Thanks. Check the latest kernel source. it's already modified to if
>> (!xen_domain())
>>>> Is the PVHVM mode supported by xen4.5 and linux3.12?
>>> We don't call "PVHVM" guests on ARM: on ARM we only have one type of
>>> guest. From the Linux kernel perspective, they are HVM domains.
>>>
>>>
>>>> Looks at the xen.h at the linux kernel source:
>>>> enum xen_domain_type {
>>>>       XEN_NATIVE,        /* running on bare hardware    */
>>>>       XEN_PV_DOMAIN,        /* running in a PV domain      */
>>>>       XEN_HVM_DOMAIN,        /* running in a Xen hvm domain */
>>>> };
>>>> seems PVHVM is not there yet?
>>> In this context PVHVM would just be XEN_PV_DOMAIN.
>>>
>>>
>>>> Kindly enlighten me what could be the solution to get the frame buffer
>>>> shared
>>>> by Domains?
>>> It should work out of the box with the latest Linux kernel and Xen 4.5,
>>> if you add
>>>
>>> vfb=['vnc=1']
>>>
>>> to the VM config file.
>> Unfortunately, It's still no work after add the vfb=[ 'vnc=1' ]. fb
>> open/write/ioctl/close from guest
>> linux user space program return no error. However, just the screen do NOT
>> display the contents wrote to vfb.
>> Here is the configuration file when create the guest linux
>>
>> kernel = "/xen/images/zImage"
>> memory = "128"
>> name = "omap5"
>> bootargs = "mem=128M vram=16M xencons=hvc"
>> vcpus = 1
>> extra ="console=hvc0 xencons=hvc root=/dev/xvda ro"
> You might want to use console=tty0 if you want to see the kernel output on the framebuffer.
Thanks. I got the kernel trace output for my guest Linux.
>> disk = [ 'phy:/dev/loop0,xvda,w' ]
>> vfb=['vnc=1']
>>
>> Kindly advise what could be the reason?
> Do you have
>
> CONFIG_XEN_FBDEV_FRONTEND=y
> CONFIG_INPUT_XEN_KBDDEV_FRONTEND=y
> CONFIG_FRAMEBUFFER_CONSOLE=y
>
> in your guest kernel config?
>
> Could you please post the output of xenstore-ls, executing the command
> after creating the VM?
>
Yes. The CONFIG_XXX mentioned above is in my guest kernel config. I've 
attached the related CONFIG_XXX of the guest Linux.

Unfortunately, it's not an option for me to go for latest Linux kernel 
right now, so I debugged the problem by adding tracing information into 
the kernel and qemu source code to trace the issue.
On guest Linux, when writing to frame buffer, the call path is
xenfb_write()
     xenfb_refresh()
         xenfb_do_update() <---- here the XENFB_TYPE_UPDATE event is 
sent out.

However, in the QEMU size on Dom0,  There is NO XENFB_TYPE_UPDATE event 
is observed in xenfb_handle_events() of xenfb.c

Shoud the XENFB_TYPE_UPDATE event sent by guest Linux reach the QEMU and 
processed and write to real hardware by QEMU?
If so. why it's not received? any point to check?

So far, I checked the following two points
1. QEMU's start up parameter, changed the original from Xen4.5
/usr/local/lib/xen/bin/qemu-system-i386 -xen-domid 0 -xen-attach -name 
dom0 */-nographic/* -M xenpv -daemonize -monitor /dev/null -serial 
/dev/null -parallel /dev/null -pidfile /var/run/qemu-dom0.pid
to
/usr/local/lib/xen/bin/qemu-system-i386 -xen-domid 0 -xen-attach -name 
dom0 /*-vga xenfb */-M xenpv -daemonize -monitor /dev/null -serial 
/dev/null -parallel /dev/null -pidfile /var/run/qemu-dom0.pid
but it does NOT make any different for this aspect.

2. The return value of xen_be_register("vfb", &xen_framebuffer_ops) of 
xen_machine_pv.c of the QEMU
it's checked and return 0. Looks not a problem

The result of xenstore-ls are attached as well.

Regards,
Mao Mingya







[-- Attachment #1.2: Type: text/html, Size: 6949 bytes --]

[-- Attachment #2: xen_domu_config --]
[-- Type: text/plain, Size: 1459 bytes --]


#add for xen related config
CONFIG_HVC_XEN_FRONTEND=y
CONFIG_XEN_DEV_EVTCHN=y
CONFIG_XENFS=y
CONFIG_XEN_COMPAT_XENFS=y
CONFIG_XEN_SYS_HYPERVISOR=y
CONFIG_XEN_GNTDEV=y
CONFIG_XEN_GRANT_DEV_A

#From: http://wiki.xenproject.org/wiki/Mainline_Linux_Kernel_Configs#Configuring_the_Kernel_for_domU_Support
#Enable these core options (Processor type and features| Paravirtualized guest support] 
CONFIG_HYPERVISOR_GUEST=y 
CONFIG_PARAVIRT=y
CONFIG_XEN=y
CONFIG_PARAVIRT_GUEST=y
CONFIG_PARAVIRT_SPINLOCKS=y 

#And Xen pv console device support (Device Drivers|Character devices
CONFIG_HVC_DRIVER=y
CONFIG_HVC_XEN=y 

#And Xen disk and network support (Device Drivers|Block devices and Device Drivers|Network device support)
CONFIG_XEN_FBDEV_FRONTEND=y
CONFIG_XEN_BLKDEV_FRONTEND=y
CONFIG_XEN_NETDEV_FRONTEND=y 

#And the rest (Device Drivers|Xen driver support)
CONFIG_XEN_PCIDEV_FRONTEND=y
CONFIG_INPUT_XEN_KBDDEV_FRONTEND=y
CONFIG_XEN_FBDEV_FRONTEND=y
CONFIG_XEN_XENBUS_FRONTEND=y
CONFIG_XEN_SAVE_RESTORE=y
CONFIG_XEN_GRANT_DEV_ALLOC=m 
CONFIG_FB_VIRTUAL=y

#And for tmem support:
CONFIG_XEN_TMEM=y
CONFIG_CLEANCACHE=y
CONFIG_FRONTSWAP=y
CONFIG_XEN_SELFBALLOONING=y 

#xxxxwwww, add general virt machine, to be used as a domain U guest
CONFIG_ARCH_VIRT=y

#xxxxwwww. gc moudle give out exception, disable is first
# CONFIG_GCCORE is not set
# CONFIG_GCIOCTL is not set
# CONFIG_GCBV is not set

#xxxxwwww, to make frame buffer working
CONFIG_FRAMEBUFFER_CONSOLE=y

[-- Attachment #3: xenstore-ls_20150123.txt --]
[-- Type: text/plain, Size: 4377 bytes --]

root@dra7xx-evm:/xen/images# xenstore-ls 
tool = ""
 xenstored = ""
local = ""
 domain = ""
  0 = ""
   domid = "0"
   name = "Domain-0"
   device = ""
    vfb = ""
     0 = ""
      state = "1"
      backend-id = "0"
      backend = "/local/domain/0/backend/vfb/0/0"
    vkbd = ""
     0 = ""
      state = "1"
      backend-id = "0"
      backend = "/local/domain/0/backend/vkbd/0/0"
   backend = ""
    vfb = ""
     0 = ""
      0 = ""
       type = "vnc"
       domain = "dom0"
       online = "1"
       state = "2"
       frontend-id = "0"
       frontend = "/local/domain/0/device/vfb/0"
       feature-resize = "1"
       hotplug-status = "connected"
     1 = ""
      0 = ""
       frontend = "/local/domain/1/device/vfb/0"
       frontend-id = "1"
       online = "1"
       state = "4"
       vnc = "1"
       vnclisten = "127.0.0.1"
       vncdisplay = "0"
       vncunused = "1"
       sdl = "0"
       opengl = "0"
       feature-resize = "1"
       hotplug-status = "connected"
       type = "vnc"
       domain = "omap5_4"
       request-update = "1"
    vkbd = ""
     0 = ""
      0 = ""
       domain = "dom0"
       online = "1"
       state = "2"
       frontend-id = "0"
       frontend = "/local/domain/0/device/vkbd/0"
       feature-abs-pointer = "1"
       hotplug-status = "connected"
     1 = ""
      0 = ""
       frontend = "/local/domain/1/device/vkbd/0"
       frontend-id = "1"
       online = "1"
       state = "1"
       feature-abs-pointer = "1"
       hotplug-status = "connected"
       domain = "omap5_4"
    vbd = ""
     1 = ""
      51712 = ""
       frontend = "/local/domain/1/device/vbd/51712"
       params = "/dev/loop0"
       script = "/etc/xen/scripts/block"
       physical-device = "7:0"
       frontend-id = "1"
       online = "1"
       removable = "0"
       bootable = "1"
       state = "4"
       dev = "xvda"
       type = "phy"
       mode = "w"
       device-type = "disk"
       discard-enable = "1"
       feature-flush-cache = "1"
       feature-discard = "0"
       feature-barrier = "1"
       feature-persistent = "1"
       feature-max-indirect-segments = "256"
       sectors = "7615488"
       info = "0"
       sector-size = "512"
       physical-sector-size = "512"
    console = ""
     1 = ""
      0 = ""
       frontend = "/local/domain/1/console"
       frontend-id = "1"
       online = "1"
       state = "1"
       protocol = "vt100"
   device-model = ""
    0 = ""
     state = "running"
    1 = ""
     state = "running"
   memory = ""
    target = "262144"
    static-max = "4294967292"
    freemem-slack = "157286"
   libxl = ""
    disable_udev = "1"
  1 = ""
   vm = "/vm/c32df72b-0983-43f7-8b57-6190ab74482d"
   name = "omap5_4"
   cpu = ""
    0 = ""
     availability = "online"
   memory = ""
    static-max = "131072"
    target = "131072"
    videoram = "0"
   device = ""
    suspend = ""
     event-channel = ""
    vbd = ""
     51712 = ""
      backend = "/local/domain/0/backend/vbd/1/51712"
      backend-id = "0"
      state = "4"
      virtual-device = "51712"
      device-type = "disk"
      protocol = "arm-abi"
      ring-ref = "8"
      event-channel = "4"
      feature-persistent = "1"
    vfb = ""
     0 = ""
      backend = "/local/domain/0/backend/vfb/1/0"
      backend-id = "0"
      state = "4"
      page-ref = "285571"
      event-channel = "3"
      protocol = "arm-abi"
      feature-update = "1"
    vkbd = ""
     0 = ""
      backend = "/local/domain/0/backend/vkbd/1/0"
      backend-id = "0"
      state = "1"
   control = ""
    shutdown = ""
    platform-feature-multiprocessor-suspend = "1"
    platform-feature-xs_reset_watches = "1"
   data = ""
   domid = "1"
   store = ""
    port = "1"
    ring-ref = "233473"
   console = ""
    backend = "/local/domain/0/backend/console/1/0"
    backend-id = "0"
    limit = "1048576"
    type = "xenconsoled"
    output = "pty"
    tty = "/dev/pts/0"
    port = "2"
    ring-ref = "233472"
    vnc-listen = "127.0.0.1"
    vnc-port = "5901"
   image = ""
    device-model-pid = "1869"
vm = ""
 c32df72b-0983-43f7-8b57-6190ab74482d = ""
  name = "omap5_4"
  uuid = "c32df72b-0983-43f7-8b57-6190ab74482d"
  image = ""
   ostype = "linux"
   kernel = "/xen/images/zImage"
   cmdline = "console=hvc0 xencons=hvc root=/dev/xvda ro"
  start_time = "1388577612.84"
libxl = ""
 1 = ""
  dm-version = "qemu_xen"


[-- Attachment #4: Type: text/plain, Size: 126 bytes --]

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

Re: frame buffer shared by domains on arch arm linux

[Ian Campbell]

On Fri, 2015-01-23 at 17:14 +0800, Mao Mingy wrote:
> 1. QEMU's start up parameter, changed the original from Xen4.5 
> /usr/local/lib/xen/bin/qemu-system-i386 -xen-domid 0

Are you trying to use pvfb for dom0's own graphical output?

This qemu process you quote here is running against dom0 in order to
provide backend services for frontends running in dom0 itself, i.e.
things like loopback qdisk mounts to the toolstack.

For a domU the xl toolstack should be launching a new qemu process
specifically for that domain, e.g. with -xen-domid <domid> (for 
domid!=0).

Ian.

Re: frame buffer shared by domains on arch arm linux

[Mao Mingy]

On 23/01/2015 17:24, Ian Campbell wrote:
> On Fri, 2015-01-23 at 17:14 +0800, Mao Mingy wrote:
>> 1. QEMU's start up parameter, changed the original from Xen4.5
>> /usr/local/lib/xen/bin/qemu-system-i386 -xen-domid 0
> Are you trying to use pvfb for dom0's own graphical output?
No. I got it wrong. Right now writing to Dom0's frame buffer from Dom0 
is working.
I am trying to run the program on DomU to to write to frame buffer of 
guest DomU and it's not working
> This qemu process you quote here is running against dom0 in order to
> provide backend services for frontends running in dom0 itself, i.e.
> things like loopback qdisk mounts to the toolstack.
>
> For a domU the xl toolstack should be launching a new qemu process
> specifically for that domain, e.g. with -xen-domid <domid> (for
> domid!=0).
>
> Ian.
>
I modified the "-xen-domid" and "-name" of qemu-system-i386  to match 
the domain name and id of the guest Dom, the result is same.
The XENFB_TYPE_UPDATE event sent by guest Linux did NOT reach to QEMU 
side (xenfb_handle_events() of xenfb.c).
should it be processed here?

Thank you for the sharp thought and prompt reply.

Regards,
Mao Mingya

Re: frame buffer shared by domains on arch arm linux

[Ian Campbell]

On Fri, 2015-01-23 at 18:03 +0800, Mao Mingy wrote:
> I modified the "-xen-domid" and "-name" of qemu-system-i386  to match 
> the domain name and id of the guest Dom, the result is same.

Please just let the toolstack launch qemu instead of doing it yourself.
With Xen 4.5 you shouldn't need to be doing anything here manually at
all.

Ian.

Re: frame buffer shared by domains on arch arm linux

[Mao Mingy]

On 23/01/2015 18:11, Ian Campbell wrote:
> On Fri, 2015-01-23 at 18:03 +0800, Mao Mingy wrote:
>> I modified the "-xen-domid" and "-name" of qemu-system-i386  to match
>> the domain name and id of the guest Dom, the result is same.
> Please just let the toolstack launch qemu instead of doing it yourself.
> With Xen 4.5 you shouldn't need to be doing anything here manually at
> all.
>
> Ian.
>
Oh. I was referring to the QEMU instance started at the boot time ( 
/etc/init.d/xencommons start)
Do I still need call "/etc/init.d/xencommons start" when system start?

Regards,
Mao Mingya

Re: frame buffer shared by domains on arch arm linux

[Stefano Stabellini]

On Fri, 23 Jan 2015, Mao Mingy wrote:
> On 23/01/2015 18:11, Ian Campbell wrote:
> > On Fri, 2015-01-23 at 18:03 +0800, Mao Mingy wrote:
> > > I modified the "-xen-domid" and "-name" of qemu-system-i386  to match
> > > the domain name and id of the guest Dom, the result is same.
> > Please just let the toolstack launch qemu instead of doing it yourself.
> > With Xen 4.5 you shouldn't need to be doing anything here manually at
> > all.
> > 
> > Ian.
> > 
> Oh. I was referring to the QEMU instance started at the boot time (
> /etc/init.d/xencommons start)
> Do I still need call "/etc/init.d/xencommons start" when system start?

Of course you need to call "/etc/init.d/xencommons start", but that is
for system wide configuration.

Another per-VM QEMU is created by xl when needed. Just do:

xl create config_file

and afterwards you should see a second qemu-system-i386 running with the
right arguments.

Re: frame buffer shared by domains on arch arm linux

[Stefano Stabellini]

Please don't drop the mailing list from CC.

On Tue, 27 Jan 2015, Mao Mingy wrote:
> When I tried to set up the network in Dom0 using command:
>     xl network-attach 1

xl network-attach is not to setup the network in dom0.
Please use "man xl"!

network-attach domain-id network-device
    Creates a new network device in the domain specified by domain-id.  network-device describes
    the device to attach, using the same format as the vif string in the domain config file. See
    xl.cfg and http://xenbits.xen.org/docs/unstable/misc/xl-network-configuration.html
    <http://xenbits.xen.org/docs/unstable/misc/xl-network-configuration.html> for more
    informations.


> I got the following error message:
>     libxl: error: libxl_exec.c:118:libxl_report_child_exitstatus:
> /etc/xen/scripts/vif-bridge online [-1] exited with error status 1
>     libxl: error: libxl_device.c:1078:device_hotplug_child_death_cb: script:
> Could not find bridge device xenbr0
>     libxl: error: libxl.c:1915:device_addrm_aocomplete: unable to add vif with
> id 0
>     libxl_device_nic_add failed.
> 
> In my Dom0 the "/sys/devices/virtual/net/xenbr0" is NOT setup at all.
> 
> What could be the reason? I have
> CONFIG_XEN_NETDEV_FRONTEND=y
> CONFIG_XEN_NETDEV_BACKEND=y
> in Dom0's kernel config, Do I still miss something?
> 
> Regards,
> Mao Mingya
> 
> On 26/01/2015 18:53, Stefano Stabellini wrote:
> > Backends in Linux are: network and block
> > drivers/block/xen-blkback
> > drivers/net/xen-netback
> > 
> > Backends in QEMU are: block, console, framebuffer, mouse & keyboard
> > hw/block/xen_disk.c
> > hw/char/xen_console.c
> > hw/display/xenfb.c
> > 
> 

Re: frame buffer shared by domains on arch arm linux

[Ian Campbell]

On Tue, 2015-01-27 at 10:24 +0000, Stefano Stabellini wrote:
> Please don't drop the mailing list from CC.
> 
> On Tue, 27 Jan 2015, Mao Mingy wrote:
> > When I tried to set up the network in Dom0 using command:
> >     xl network-attach 1
> 
> xl network-attach is not to setup the network in dom0.
> Please use "man xl"!

... and the wiki, which has a wealth of information on how to setup a
Xen host, including how to configure networking in general and guides
for specific dom0 OSes etc.

Ian.

Re: frame buffer shared by domains on arch arm linux

[Ian Campbell]

On Fri, 2015-01-23 at 18:23 +0800, Mao Mingy wrote:
> On 23/01/2015 18:11, Ian Campbell wrote:
> > On Fri, 2015-01-23 at 18:03 +0800, Mao Mingy wrote:
> >> I modified the "-xen-domid" and "-name" of qemu-system-i386  to match
> >> the domain name and id of the guest Dom, the result is same.
> > Please just let the toolstack launch qemu instead of doing it yourself.
> > With Xen 4.5 you shouldn't need to be doing anything here manually at
> > all.
> >
> > Ian.
> >
> Oh. I was referring to the QEMU instance started at the boot time ( 
> /etc/init.d/xencommons start)
> Do I still need call "/etc/init.d/xencommons start" when system start?

Yes it should be run and it should be starting a qemu process for dom0.

In summary:
      * Leave xencommons alone, and arrange to run it on boot, so it
        starts a qemu for dom0
      * Allow the toolstack to launch a qemu process for the guest
        domain as and when it deems it necessary.

Ian.

Re: frame buffer shared by domains on arch arm linux

[Mao Mingy]

On 23/01/2015 18:34, Ian Campbell wrote:
> On Fri, 2015-01-23 at 18:23 +0800, Mao Mingy wrote:
>> On 23/01/2015 18:11, Ian Campbell wrote:
>>> On Fri, 2015-01-23 at 18:03 +0800, Mao Mingy wrote:
>>>> I modified the "-xen-domid" and "-name" of qemu-system-i386  to match
>>>> the domain name and id of the guest Dom, the result is same.
>>> Please just let the toolstack launch qemu instead of doing it yourself.
>>> With Xen 4.5 you shouldn't need to be doing anything here manually at
>>> all.
>>>
>>> Ian.
>>>
>> Oh. I was referring to the QEMU instance started at the boot time (
>> /etc/init.d/xencommons start)
>> Do I still need call "/etc/init.d/xencommons start" when system start?
> Yes it should be run and it should be starting a qemu process for dom0.
>
> In summary:
>        * Leave xencommons alone, and arrange to run it on boot, so it
>          starts a qemu for dom0
>        * Allow the toolstack to launch a qemu process for the guest
>          domain as and when it deems it necessary.
>
> Ian.
>
My system follows what you've mentioned above. I was using the following 
commands
"xl create files.cfg" to create the guest dom.

The files.cfg are as follows:
kernel = "/xen/images/zImage"
memory = "128"
name = "omap51"
bootargs = "mem=128M vram=16M xencons=hvc"
vcpus = 1
extra ="console=hvc0 xencons=hvc root=/dev/xvda ro"
disk = [ 'phy:/dev/loop0,xvda,w' ]
vfb=['vnc=1']

The QEMU instance for guest dom is observed on Dom0.

Everything seems fine,  writing to fb of guest dom returns no error.

Just physical screen do not display the contents of fb of guest dom.

Regards,
Mao Mingya

Re: frame buffer shared by domains on arch arm linux

[Ian Campbell]

On Fri, 2015-01-23 at 18:48 +0800, Mao Mingy wrote:
> On 23/01/2015 18:34, Ian Campbell wrote:
> > On Fri, 2015-01-23 at 18:23 +0800, Mao Mingy wrote:
> >> On 23/01/2015 18:11, Ian Campbell wrote:
> >>> On Fri, 2015-01-23 at 18:03 +0800, Mao Mingy wrote:
> >>>> I modified the "-xen-domid" and "-name" of qemu-system-i386  to match
> >>>> the domain name and id of the guest Dom, the result is same.
> >>> Please just let the toolstack launch qemu instead of doing it yourself.
> >>> With Xen 4.5 you shouldn't need to be doing anything here manually at
> >>> all.
> >>>
> >>> Ian.
> >>>
> >> Oh. I was referring to the QEMU instance started at the boot time (
> >> /etc/init.d/xencommons start)
> >> Do I still need call "/etc/init.d/xencommons start" when system start?
> > Yes it should be run and it should be starting a qemu process for dom0.
> >
> > In summary:
> >        * Leave xencommons alone, and arrange to run it on boot, so it
> >          starts a qemu for dom0
> >        * Allow the toolstack to launch a qemu process for the guest
> >          domain as and when it deems it necessary.
> >
> > Ian.
> >
> My system follows what you've mentioned above. I was using the following 
> commands
> "xl create files.cfg" to create the guest dom.
> 
> The files.cfg are as follows:
> kernel = "/xen/images/zImage"
> memory = "128"
> name = "omap51"
> bootargs = "mem=128M vram=16M xencons=hvc"
> vcpus = 1
> extra ="console=hvc0 xencons=hvc root=/dev/xvda ro"
> disk = [ 'phy:/dev/loop0,xvda,w' ]
> vfb=['vnc=1']
> 
> The QEMU instance for guest dom is observed on Dom0.
> 
> Everything seems fine,  writing to fb of guest dom returns no error.
> 
> Just physical screen do not display the contents of fb of guest dom.

The PVFB backend is outputting to vnc as you've requested ("vnc=1"). It
is not expected to just appear on any physical display.

You need to use a client of some sort, i.e. vncviewer, either remotely
over a network or from dom0 (if it has a suitable graphics stack). I
think there are vnc clients which can write direct to /dev/fb* too, but
I can't name one off hand.

If you are running X in dom0 then you could also use sdl instead of vnc,
which will put the guest display in a window or full screen.

If you are trying to get the guest framebuffer onto a physical graphics
device then PVFB is not what you need. Instead you need to do device
passthrough of that device to the guest (which means denying it to
dom0). Passthrough is still a work in progress on Xen on ARM (likely to
land for 4.6) and *requires* an SMMU to be present in the hardware.

Ian.

Re: frame buffer shared by domains on arch arm linux

[Mao Mingya]

[-- Attachment #1.1: Type: text/plain, Size: 3024 bytes --]

Thank you for the overall picture. a good lesson for me.

Will try to use the VNC next week.

On a second though, What mode is the serial port working now on ARM arch?
it is able to be shared by Dom0 and guest Dom

Regards,
Mao

On Fri, Jan 23, 2015 at 6:56 PM, Ian Campbell <Ian.Campbell@citrix.com>
wrote:

> On Fri, 2015-01-23 at 18:48 +0800, Mao Mingy wrote:
> > On 23/01/2015 18:34, Ian Campbell wrote:
> > > On Fri, 2015-01-23 at 18:23 +0800, Mao Mingy wrote:
> > >> On 23/01/2015 18:11, Ian Campbell wrote:
> > >>> On Fri, 2015-01-23 at 18:03 +0800, Mao Mingy wrote:
> > >>>> I modified the "-xen-domid" and "-name" of qemu-system-i386  to
> match
> > >>>> the domain name and id of the guest Dom, the result is same.
> > >>> Please just let the toolstack launch qemu instead of doing it
> yourself.
> > >>> With Xen 4.5 you shouldn't need to be doing anything here manually at
> > >>> all.
> > >>>
> > >>> Ian.
> > >>>
> > >> Oh. I was referring to the QEMU instance started at the boot time (
> > >> /etc/init.d/xencommons start)
> > >> Do I still need call "/etc/init.d/xencommons start" when system start?
> > > Yes it should be run and it should be starting a qemu process for dom0.
> > >
> > > In summary:
> > >        * Leave xencommons alone, and arrange to run it on boot, so it
> > >          starts a qemu for dom0
> > >        * Allow the toolstack to launch a qemu process for the guest
> > >          domain as and when it deems it necessary.
> > >
> > > Ian.
> > >
> > My system follows what you've mentioned above. I was using the following
> > commands
> > "xl create files.cfg" to create the guest dom.
> >
> > The files.cfg are as follows:
> > kernel = "/xen/images/zImage"
> > memory = "128"
> > name = "omap51"
> > bootargs = "mem=128M vram=16M xencons=hvc"
> > vcpus = 1
> > extra ="console=hvc0 xencons=hvc root=/dev/xvda ro"
> > disk = [ 'phy:/dev/loop0,xvda,w' ]
> > vfb=['vnc=1']
> >
> > The QEMU instance for guest dom is observed on Dom0.
> >
> > Everything seems fine,  writing to fb of guest dom returns no error.
> >
> > Just physical screen do not display the contents of fb of guest dom.
>
> The PVFB backend is outputting to vnc as you've requested ("vnc=1"). It
> is not expected to just appear on any physical display.
>
> You need to use a client of some sort, i.e. vncviewer, either remotely
> over a network or from dom0 (if it has a suitable graphics stack). I
> think there are vnc clients which can write direct to /dev/fb* too, but
> I can't name one off hand.
>
> If you are running X in dom0 then you could also use sdl instead of vnc,
> which will put the guest display in a window or full screen.
>
> If you are trying to get the guest framebuffer onto a physical graphics
> device then PVFB is not what you need. Instead you need to do device
> passthrough of that device to the guest (which means denying it to
> dom0). Passthrough is still a work in progress on Xen on ARM (likely to
> land for 4.6) and *requires* an SMMU to be present in the hardware.
>
> Ian.
>
>

[-- Attachment #1.2: Type: text/html, Size: 4130 bytes --]

[-- Attachment #2: Type: text/plain, Size: 126 bytes --]

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

Re: frame buffer shared by domains on arch arm linux

[Ian Campbell]

On Fri, 2015-01-23 at 21:13 +0800, Mao Mingya wrote:

> On a second though, What mode is the serial port working now on ARM
> arch? it is able to be shared by Dom0 and guest Dom

A given piece of hardware can only be accessed by one entity at a time.

Typically one serial port is given to Xen itself.

Dom0 then has access to the hvc (hypervisor console), which Xen routes
out of its own console (i.e. out of the serial port given to Xen).

Dom0 also has access to any additional serial ports in the system.

DomU only gets the virtual hvc console, unless you use device pass
through (again, coming in 4.6) to give it access to a real one (thereby
denying it to dom0.

Ian.

Re: frame buffer shared by domains on arch arm linux

[Mao Mingy]

[-- Attachment #1.1: Type: text/plain, Size: 450 bytes --]


On 23/01/2015 18:56, Ian Campbell wrote:
> If you are trying to get the guest framebuffer onto a physical graphics
> device then PVFB is not what you need. Instead you need to do device
> passthrough of that device to the guest (which means denying it to
> dom0). Passthrough is still a work in progress on Xen on ARM (likely to
> land for 4.6) and*requires*  an SMMU to be present in the hardware.
Do you have any time frame for xen 4.6 release?



[-- Attachment #1.2: Type: text/html, Size: 905 bytes --]

[-- Attachment #2: Type: text/plain, Size: 126 bytes --]

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

Re: frame buffer shared by domains on arch arm linux

[Stefano Stabellini]

On Mon, 26 Jan 2015, Mao Mingy wrote:
> On 23/01/2015 18:56, Ian Campbell wrote:
> 
> If you are trying to get the guest framebuffer onto a physical graphics
> device then PVFB is not what you need. Instead you need to do device
> passthrough of that device to the guest (which means denying it to
> dom0). Passthrough is still a work in progress on Xen on ARM (likely to
> land for 4.6) and *requires* an SMMU to be present in the hardware.
> 
> Do you have any time frame for xen 4.6 release?

We don't at the moment. But the 4.6 development cycle has just opened
and as a reference the 4.5 development cycle was 10 months.

Re: frame buffer shared by domains on arch arm linux

[Stefano Stabellini]

[-- Attachment #1: Type: text/plain, Size: 5173 bytes --]

Please don't use HTML in emails.

On Fri, 23 Jan 2015, Mao Mingy wrote:
> On 22/01/2015 19:56, Stefano Stabellini wrote:
> 
> On Thu, 22 Jan 2015, Mao Mingy wrote:
> 
> On 21/01/2015 18:51, Stefano Stabellini wrote:
> 
> On Wed, 21 Jan 2015, Mao Mingy wrote:
> 
> I am trying to run the PVHVM guest on omap5 (arm arch) so that I can get
> the
> frame buffer shared by Domains. my setup are:
> 1. run xen4.5 after the u-boot.
> 2. start the dom0 (on linux kernel 3.12) on xen.
> 
> 3.12 is pretty old now
> 
> 
> 3. run the qemu (from xen 4.5) and HVM backend on xen.
> 
> Is this the QEMU binary that gets compiled as part of the Xen 4.5 build
> and started automatically by xl if you configure the VM with a
> framebuffer?
> 
> Yes. it's compiled from Xen 4.5. exact location @ "
> ./xen_4.5/dist/install/usr/local/lib/xen/bin/qemu-system-i386 "
> 
> 4. run the guest domain as "Machine: Dummy Virtual Machine, model:
> XENVM-4.5"
> 5. try to build a frame buffer on guest domain by
>      CONFIG_XEN_FBDEV_FRONTEND = y
>      CONFIG_FB_VIRTUAL=y
> 
> after change to domain checking in the first list of xenfb_init(...) in
> xen-fbfront.c from
>      if (!xen_pv_domain()) --->    if (!xen_domain())
> the /dev/fb0 is built up on guest domain. However, writing to this fb has
> no
> response from screen.
> 
> Why xenfb_init limited to PV domain only?
> 
> No it is not. In fact if you use a more recent Linux kernel, you won't
> need to make any modifications and it should work out of the box.
> 
> Thanks. Check the latest kernel source. it's already modified to if
> (!xen_domain())
> 
> Is the PVHVM mode supported by xen4.5 and linux3.12?
> 
> We don't call "PVHVM" guests on ARM: on ARM we only have one type of
> guest. From the Linux kernel perspective, they are HVM domains.
> 
> 
> Looks at the xen.h at the linux kernel source:
> enum xen_domain_type {
>      XEN_NATIVE,        /* running on bare hardware    */
>      XEN_PV_DOMAIN,        /* running in a PV domain      */
>      XEN_HVM_DOMAIN,        /* running in a Xen hvm domain */
> };
> seems PVHVM is not there yet?
> 
> In this context PVHVM would just be XEN_PV_DOMAIN.
> 
> 
> Kindly enlighten me what could be the solution to get the frame buffer
> shared
> by Domains?
> 
> It should work out of the box with the latest Linux kernel and Xen 4.5,
> if you add
> 
> vfb=['vnc=1']
> 
> to the VM config file.
> 
> Unfortunately, It's still no work after add the vfb=[ 'vnc=1' ]. fb
> open/write/ioctl/close from guest
> linux user space program return no error. However, just the screen do NOT
> display the contents wrote to vfb.
> Here is the configuration file when create the guest linux
> 
> kernel = "/xen/images/zImage"
> memory = "128"
> name = "omap5"
> bootargs = "mem=128M vram=16M xencons=hvc"
> vcpus = 1
> extra ="console=hvc0 xencons=hvc root=/dev/xvda ro"
> 
> You might want to use console=tty0 if you want to see the kernel output on the framebuffer.
> 
> Thanks. I got the kernel trace output for my guest Linux.
> 
> disk = [ 'phy:/dev/loop0,xvda,w' ]
> vfb=['vnc=1']
> 
> Kindly advise what could be the reason?
> 
> Do you have
> 
> CONFIG_XEN_FBDEV_FRONTEND=y
> CONFIG_INPUT_XEN_KBDDEV_FRONTEND=y
> CONFIG_FRAMEBUFFER_CONSOLE=y
> 
> in your guest kernel config?
> 
> Could you please post the output of xenstore-ls, executing the command
> after creating the VM?
> 
> Yes. The CONFIG_XXX mentioned above is in my guest kernel config. I've attached the related CONFIG_XXX of
> the guest Linux.
> 
> Unfortunately, it's not an option for me to go for latest Linux kernel right now, so I debugged the
> problem by adding tracing information into the kernel and qemu source code to trace the issue.
> On guest Linux, when writing to frame buffer, the call path is
> xenfb_write()
>     xenfb_refresh()
>         xenfb_do_update() <---- here the XENFB_TYPE_UPDATE event is sent out.
> 
> However, in the QEMU size on Dom0,  There is NO XENFB_TYPE_UPDATE event is observed in
> xenfb_handle_events() of xenfb.c
> 
> Shoud the XENFB_TYPE_UPDATE event sent by guest Linux reach the QEMU and processed and write to real
> hardware by QEMU?
> If so. why it's not received? any point to check?
> 
> So far, I checked the following two points
> 1. QEMU's start up parameter, changed the original from Xen4.5
> /usr/local/lib/xen/bin/qemu-system-i386 -xen-domid 0 -xen-attach -name dom0 -nographic -M xenpv
> -daemonize -monitor /dev/null -serial /dev/null -parallel /dev/null -pidfile /var/run/qemu-dom0.pid
> to
> /usr/local/lib/xen/bin/qemu-system-i386 -xen-domid 0 -xen-attach -name dom0 -vga xenfb -M xenpv
> -daemonize -monitor /dev/null -serial /dev/null -parallel /dev/null -pidfile /var/run/qemu-dom0.pid
> but it does NOT make any different for this aspect.
> 
> 2. The return value of xen_be_register("vfb", &xen_framebuffer_ops) of xen_machine_pv.c of the QEMU
> it's checked and return 0. Looks not a problem

As a matter of fact the output of xenstore-ls that you posted looks
good: everything seems to be up and running.

[-- Attachment #2: Type: text/plain, Size: 126 bytes --]

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