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.
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
