Versions Compared

Old Version 5

changes.mady.by.user Ross Philipson

Saved on

compared with

New Version Current

changes.mady.by.user Ross Philipson

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.
Info
iconNone

Image Added

Copyright 2015 by Assured Information Security, Inc. Created by Martin Osterloh <osterlohm@ainfosec.com>. This work is licensed under the Creative Commons Attribution 4.0 International License. To view a copy of this license, visit http://creativecommons.org/licenses/by/4.0/.

Contributions by: Ross Philipson <philipsonr@ainfosec.com>

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:

...

Code Block
languagetext
        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
 
Looks like this under /local/domain/<n>
 
hvmloader = ""
 bios = "seabios"
 seabios-legacy-load-roms = "1"

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:

Code Block
languagetext
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 */
};

Arguments to QEMU

We did something non standard when invoking QEMU. We slapped the domid as arg 1. Just noting it here in case we run into trouble.

Code Block
Nonstandard args:
Mar 17 19:11:34.942096 dm-agent-0: Info:spawn.c:spawn_dump_cmdline:352: Domain 3: Devmodel 0: cmdline: /usr/sbin/svirt-interpose 3 -xen-domid 3 -nodefaults -name qemu-3.0 -machine xenfv,max-ram-below-4g=0xf0000000 -m 1024 -smp 2 -boot cd -device xenmou -xen-acpi-pm -vga std -display surfman -serial pty -drive file=/storage/isos/null.iso,if=ide,index=2,media=cdrom,format=file,readonly=on -drive file=/dev/xen/blktap-2/tapdev5,if=ide,index=0,media=disk,format=raw,readonly=off -drive file=atapi-pt-local:/dev/bsg/2:0:0:0,media=cdrom,if=atapi-pt,format=raw,readonly=off -soundhw ac97
 
Nonstandard hackery in the wrapper:
DOMID=$1
shift 1

 

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:

...

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.