Re: [Xen-devel] frame buffer shared by domains on arch arm linux

[Mao Mingya <maomingya928@xxxxxxxxx>]

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@xxxxxxxxxx> 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.

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