Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 9 Next »

UIVM graphics

We managed to get the UIVM up and running. We can sshv4v to it using 1.0.0.x. The UIVM has xenfb2 loaded but it does not create a /dev/fb0 node. The problem is the backed is not created but surfman. The dmbus RPC to create the node and hook up the front back connection is never called:

surfman/src/rpc.c:rpc_connect(type=DEVICE_TYPE_XENFB)

It looks like the call should come from the dm-agent running in dom0 (not sure what that is even doing there).

Blktap dev passing to QEMU

We have deliberately disabled QEMU support for directly supplying a VHD as a drive. The proper way in OpenXT is by using a blktap device (such as tapdisk2). Even though one can signal to LibXL to use a tap device in the config file, LibXL will always pass a vhd as an argument to QEMU. 

Consider the configuration:

disk = [ "tap2:tapdisk:vhd:/storage/disks/debian-7.8-x64-clean.vhd,xvda,rw" ]

Unfortunately, XL will pass the following to QEMU:

libxl: debug: libxl_dm.c:1237:libxl__spawn_local_dm: -drive
libxl: debug: libxl_dm.c:1237:libxl__spawn_local_dm: file=/storage/disks/debian-7.8-x64-clean.vhd,if=ide,index=0,media=disk,format=vpc,cache=writeback

This will likely need to be patched against XL.

VIF naming in hotplug scripts

When supplied a VIF in the config file via:

vif = [ "bridge=xenbr0,script=vif-bridge" ]

The supplied hotplug script (vif-bridge in /etc/xen/scripts/) is being called with vif$VIF_ID-emu instead of vif$VIF_ID where $VIF_ID starts at zero and increments every time and instance requests a VIF. Currently, the "-emu" part is being removed by sed. It is not 100% clear why the -emu is being appended.

HVMLOADER not loading ROMS...no video

The ROM loading was being skipped due to a missing xenstore value.

        let local_stuff = [
                "serial/0/limit",    string_of_int 65536;
                "console/limit",     string_of_int 65536;
                "console/port",      string_of_int console_port;
                "console/ring-ref",  sprintf "%nu" console_mfn;
                "hvmloader/bios",    "seabios";
                "hvmloader/seabios-legacy-load-roms", "1";   <--- that guy
        ] in

VHD Compatibility

Certain VHDs that were created with an upstream version of Xen cannot be used in current OpenXT. At least we think that is the case - really the only one is the CentOS VHD that was created at some point with some version of Xen tools. In general it is now believed that even though we change the VHD meta structures, our VHDs are still compatible. This is why:

struct dd_batmap_hdr {
  char   cookie[8];       /* should contain "tdbatmap"                    */
  u64    batmap_offset;   /* byte offset to batmap                        */  <--- This is the offset to where the allocation tables reside after this struct
  u32    batmap_size;     /* batmap size in sectors                       */
  u32    batmap_version;  /* version of batmap                            */
  u32    checksum;        /* batmap checksum -- 1's complement of batmap  */
  /* We add extra stuffs here like the keyhash but the batmap_offset is adjusted to skip them */
};

GDB and QEMU

Running QEMU in GDB has proven to be very helpful. Simply copy the gdb binaries (gdb, gdbserver, and gdbtui) on to your OpenXT machine and replace the /usr/lib/xen/bin/qemu-system-i386 script with:

#!/bin/bash

DOMID=`cat /tmp/domid`
let "NEWID=$DOMID+1"
echo "$NEWID" > /tmp/domid

exec gdbserver 0.0.0.0:1234 /usr/bin/qemu-system-i386 -gdb stdio -xen-domid $DOMID -nodefaults -name qemu-3.0 -machine xenfv,max-ram-below-4g=0xf0000000 -m 1024 -drive file=/dev/xen/blktap-2/tapdev0,if=ide,index=0,media=disk,format=raw,readonly=off #-vnc 192.168.2.2:5900 $@

In another window, you can run gdb and do target remote localhost:1234.

TODO: QEMU mess and sv-interposer and qemu-dm-wrapper ... what is REALLY necessary?

VNC support in QEMU

In order for us to see what is happening inside the guest, we have to enable VNC. Per default, out QEMU does not enable VNC connections. The recipe for it, however, makes that easy to change. Instead of --disable-vnc, we write --enable-vnc. Now, QEMU has several new dependencies. 

  • libpng (already being built and pulled into dom0)
  • libgnutls (not being pulled into dom0)
  • libtasn1 (not being pulled into dom0)
     

The quick and dirty way is to copy the image directory onto your OpenXT machine and add the libraries manually.

Notes on blktap2 and tapdisk 

 

# Some notes on how how tapdevs and associated devices are created. It begins here:
 
libxl:libxl__blktap_devpath calls libblktapctl.so:tap_ctl_create directly.
xenops/device.ml:mount calls it indirectly by invoking tap-ctl with the create option (which calls tap-ctl:tap_cli_create)
  
# This function in libblktapctl.so does 4 important things that are listed below
tap_cli_create:
  tap_ctl_allocate
  tap_ctl_spawn
  tap_ctl_attach
  tap_ctl_open
  
tap_ctl_allocate:
  # Open the blktap driver
  # Allocate a ring device and an IO device using the BLKTAP2_IOCTL_ALLOC_TAP ioctl (see below).
  # tap_ctl_make_device then makes the ring device node /dev/xen/blktap-2/blktapX and an IO device node /devxen/blktap-2/tapdevX
  
tap_ctl_spawn:
  # Start a new tapdisk2 process that will be associated with the X tap devices.
  # tapdisk2 creates the listener socket for the new process.
  # tapdisk2 registers the tapdisk_control_handle_request
  
tap_ctl_attach:
  # Attach to the listening tapdisk2 process just started so now messages can be passed between libblktapctl.so and that process.
  
tap_ctl_open:
  # Send the TAPDISK_MESSAGE_OPEN to the new tapdisk2 process.
  
# In the new tapdisk2 process associated with the X devices allocated above.
tapdisk_control_handle_request:
  # Get message TAPDISK_MESSAGE_OPEN and call:
  tapdisk_control_open_image:
    # Send the BLKTAP2_IOCTL_CREATE_DEVICE ioctl to blkdev (see below).
# Down in the blktap driver, the above activity translates to:
blktap_control_ioctl:
  # BLKTAP2_IOCTL_ALLOC_TAP maps to BLKTAP_IOCTL_ALLOC_TAP
  # Call blktap_control_create_tap to create the tap ring and IO devices.
  
blktap_ring_ioctl:
  # BLKTAP2_IOCTL_CREATE_DEVICE maps to BLKTAP_IOCTL_CREATE_DEVICE_COMPAT. Calls:
  blktap_device_create:
    # Sets up the /dev/tdx node name (note little x corresponds to a, b, c...)
    # Creates and adds the actual block device with add_disk() (see include/linux/genhd.h for generic block disk devices).
    # The rest happens in the standard udev way.
  
 
NOTE: when destroying a tapdev with tap-ctl the process id is the tapdisk2 process that own the tap devs. The minor number is what is called X above.

  • No labels