1. 27 1月, 2016 7 次提交
    • I
      xen: domainbuild: reopen libxenctrl interface after forking for domain watcher. · 228df5c9
      Ian Campbell 提交于
      Using an existing libxenctrl handle after a fork was never
      particularly safe (especially if foreign mappings existed at the time
      of the fork) and the xc fd has been unavailable for many releases.
      
      Reopen the handle after fork and therefore do away with xc_fd().
      Signed-off-by: NIan Campbell <ian.campbell@citrix.com>
      Acked-by: NStefano Stabellini <stefano.stabellini@eu.citrix.com>
      Signed-off-by: NStefano Stabellini <stefano.stabellini@eu.citrix.com>
      228df5c9
    • I
      xen: Use stable library interfaces when they are available. · 5eeb39c2
      Ian Campbell 提交于
      In Xen 4.7 we are refactoring parts libxenctrl into a number of
      separate libraries which will provide backward and forward API and ABI
      compatiblity.
      
      Specifically libxenevtchn, libxengnttab and libxenforeignmemory.
      
      Previous patches have already laid the groundwork for using these by
      switching the existing compatibility shims to reflect the intefaces to
      these libraries.
      
      So all which remains is to update configure to detect the libraries
      and enable their use. Although they are notionally independent we take
      an all or nothing approach to the three libraries since they were
      added at the same time.
      
      The only non-obvious bit is that we now open a proper xenforeignmemory
      handle for xen_fmem instead of reusing the xen_xc handle.
      
      Build tested with 4.0 .. 4.6 (inclusive) and the patches targetting
      4.7 which adds these libraries.
      
      This uses CONFIG_XEN_CTRL_INTERFACE_VERSION == 471 to cover the
      introduction of these new interfaces.
      Signed-off-by: NIan Campbell <ian.campbell@citrix.com>
      Reviewed-by: NStefano Stabellini <stefano.stabellini@eu.citrix.com>
      Signed-off-by: NStefano Stabellini <stefano.stabellini@eu.citrix.com>
      5eeb39c2
    • I
      xen: Switch uses of xc_map_foreign_{pages,bulk} to use libxenforeignmemory API. · e0cb42ae
      Ian Campbell 提交于
      In Xen 4.7 we are refactoring parts libxenctrl into a number of
      separate libraries which will provide backward and forward API and ABI
      compatiblity.
      
      One such library will be libxenforeignmemory which provides access to
      privileged foreign mappings and which will provide an interface
      equivalent to xc_map_foreign_{pages,bulk}.
      
      The new xenforeignmemory_map() function behaves like
      xc_map_foreign_pages() when the err argument is NULL and like
      xc_map_foreign_bulk() when err is non-NULL, which maps into the shim
      here onto checking err == NULL and calling the appropriate old
      function.
      
      Note that xenforeignmemory_map() takes the number of pages before the
      arrays themselves, in order to support potentially future use of
      variable-length-arrays in the prototype (in the future, when Xen's
      baseline toolchain requirements are new enough to ensure VLAs are
      supported).
      
      In preparation for adding support for libxenforeignmemory add support
      to the <=4.0 and <=4.6 compat code in xen_common.h to allow us to
      switch to using the new API. These shims will disappear for versions
      of Xen which include libxenforeignmemory.
      
      Since libxenforeignmemory will have its own handle type but for <= 4.6
      the functionality is provided by using a libxenctrl handle we
      introduce a new global xen_fmem alongside the existing xen_xc. In fact
      we make xen_fmem a pointer to the existing xen_xc, which then works
      correctly with both <=4.0 (xc handle is an int) and <=4.6 (xc handle
      is a pointer). In the latter case xen_fmem is actually a double
      indirect pointer, but it all falls out in the wash.
      
      Unlike libxenctrl libxenforeignmemory has an explicit unmap function,
      rather than just specifying that munmap should be used, so the unmap
      paths are updated to use xenforeignmemory_unmap, which is a shim for
      munmap on these versions of xen. The mappings in xen-hvm.c do not
      appear to be unmapped (which makes sense for a qemu-dm process)
      
      In fb_disconnect this results in a change from simply mmap over the
      existing mapping (with an implicit munmap) to expliclty unmapping with
      xenforeignmemory_unmap and then mapping the required anonymous memory
      in the same hole. I don't think this is a problem since any other
      thread which was racily touching this region would already be running
      the risk of hitting the mapping halfway through the call. If this is
      thought to be a problem then we could consider adding an extra API to
      the libxenforeignmemory interface to replace a foreign mapping with
      anonymous shared memory, but I'd prefer not to.
      Signed-off-by: NIan Campbell <ian.campbell@citrix.com>
      Reviewed-by: NStefano Stabellini <stefano.stabellini@eu.citrix.com>
      Signed-off-by: NStefano Stabellini <stefano.stabellini@eu.citrix.com>
      e0cb42ae
    • I
      xen: Switch uses of xc_map_foreign_range into xc_map_foreign_pages · 9ed257d1
      Ian Campbell 提交于
      In Xen 4.7 we are refactoring parts libxenctrl into a number of
      separate libraries which will provide backward and forward API and ABI
      compatiblity.
      
      One such library will be libxenforeignmemory which provides access to
      privileged foreign mappings and which will provide an interface
      equivalent to xc_map_foreign_{pages,bulk}.
      
      In preparation for this switch all uses of xc_map_foreign_range to
      xc_map_foreign_pages. This is trivial because size was always
      XC_PAGE_SIZE so the necessary adjustments are trivial:
      
        * Pass &mfn (an array of length 1) instead of mfn. The function
          takes a pointer to const, so there is no possibily of mfn changing
          due to this change.
        * Pass nr_pages=1 instead of size=XC_PAGE_SIZE
      
      There is one wrinkle in xen_console.c:con_initialise() where
      con->ring_ref is an int but can in some code paths (when !xendev->dev)
      be treated as an mfn. I think this is an existing latent truncation
      hazard on platforms where xen_pfn_t is 64-bit and int is 32-bit (e.g.
      amd64, both arm* variants). I'm unsure under what circumstances
      xendev->dev can be NULL or if anything elsewhere ensures the value
      fits into an int. For now I just use a temporary xen_pfn_t to in
      effect upcast the pointer from int* to xen_pfn_t*.
      
      In xenfb.c:common_bind we now explicitly launder the mfn into a
      xen_pfn_t, so it has the correct type to be passed to
      xc_map_foreign_pages and doesn't provoke warnings on 32-bit x86.
      Signed-off-by: NIan Campbell <ian.campbell@citrix.com>
      Reviewed-by: NStefano Stabellini <stefano.stabellini@eu.citrix.com>
      Signed-off-by: NStefano Stabellini <stefano.stabellini@eu.citrix.com>
      9ed257d1
    • I
      xen: Switch to libxengnttab interface for compat shims. · c1345a88
      Ian Campbell 提交于
      In Xen 4.7 we are refactoring parts libxenctrl into a number of
      separate libraries which will provide backward and forward API and ABI
      compatiblity.
      
      One such library will be libxengnttab which provides access to grant
      tables.
      
      In preparation for this switch the compatibility layer in xen_common.h
      (which support building with older versions of Xen) to use what will
      be the new library API. This means that the gnttab shim will disappear
      for versions of Xen which include libxengnttab.
      
      To simplify things for the <= 4.0.0 support we wrap the int fd in a
      malloc(sizeof int) such that the handle is always a pointer. This
      leads to less typedef headaches and the need for
      XC_HANDLER_INITIAL_VALUE etc for these interfaces.
      
      Note that this patch does not add any support for actually using
      libxengnttab, it just adjusts the existing shims.
      Signed-off-by: NIan Campbell <ian.campbell@citrix.com>
      Reviewed-by: NStefano Stabellini <stefano.stabellini@eu.citrix.com>
      Signed-off-by: NStefano Stabellini <stefano.stabellini@eu.citrix.com>
      c1345a88
    • I
      xen: Switch to libxenevtchn interface for compat shims. · a2db2a1e
      Ian Campbell 提交于
      In Xen 4.7 we are refactoring parts libxenctrl into a number of
      separate libraries which will provide backward and forward API and ABI
      compatiblity.
      
      One such library will be libxenevtchn which provides access to event
      channels.
      
      In preparation for this switch the compatibility layer in xen_common.h
      (which support building with older versions of Xen) to use what will
      be the new library API. This means that the evtchn shim will disappear
      for versions of Xen which include libxenevtchn.
      
      To simplify things for the <= 4.0.0 support we wrap the int fd in a
      malloc(sizeof int) such that the handle is always a pointer. This
      leads to less typedef headaches and the need for
      XC_HANDLER_INITIAL_VALUE etc for these interfaces.
      
      Note that this patch does not add any support for actually using
      libxenevtchn, it just adjusts the existing shims.
      
      Note that xc_evtchn_alloc_unbound functionality remains in libxenctrl,
      since that functionality is not exposed by /dev/xen/evtchn.
      Signed-off-by: NIan Campbell <ian.campbell@citrix.com>
      Reviewed-by: NStefano Stabellini <stefano.stabellini@eu.citrix.com>
      Signed-off-by: NStefano Stabellini <stefano.stabellini@eu.citrix.com>
      a2db2a1e
    • I
      xen_console: correctly cleanup primary console on teardown. · 549e9bca
      Ian Campbell 提交于
      All of the work in con_disconnect applies to the primary console case
      (when xendev->dev is NULL). Therefore remove the early check and bail
      and allow it to fall through. All of the existing code is correctly
      conditional already.
      
      The ->dev and ->gnttabdev handles are either both set or neither. For
      consistency with con_initialise() with to the former here too.
      
      With this con_initialise and con_disconnect now mirror each other.
      
      Fix up a hard tab in the function while editing.
      Signed-off-by: NIan Campbell <ian.campbell@citrix.com>
      Reviewed-by: NStefano Stabellini <stefano.stabellini@eu.citrix.com>
      Signed-off-by: NStefano Stabellini <stefano.stabellini@eu.citrix.com>
      549e9bca
  2. 26 1月, 2016 14 次提交
    • P
      Merge remote-tracking branch 'remotes/jnsnow/tags/ide-pull-request' into staging · 1535a6d6
      Peter Maydell 提交于
      # gpg: Signature made Mon 25 Jan 2016 19:39:58 GMT using RSA key ID AAFC390E
      # gpg: Good signature from "John Snow (John Huston) <jsnow@redhat.com>"
      
      * remotes/jnsnow/tags/ide-pull-request:
        fdc: change auto fallback drive for ISA FDC to 288
        qtest/fdc: Support for 2.88MB drives
        fdc: rework pick_geometry
        fdc: add physical disk sizes
        fdc: add drive type option
        fdc: Add fallback option
        fdc: add pick_drive
        fdc: Throw an assertion on misconfigured fd_formats table
        fdc: add disk field
        fdc: add drive type qapi enum
        fdc: reduce number of pick_geometry arguments
        fdc: move pick_geometry
        ide: Correct the CHS 'cyls_max' limit to be 65535
      Signed-off-by: NPeter Maydell <peter.maydell@linaro.org>
      1535a6d6
    • J
      fdc: change auto fallback drive for ISA FDC to 288 · 4812fa27
      John Snow 提交于
      The 2.88 drive is more suitable as a default because
      it can still read 1.44 images correctly, but the reverse
      is not true.
      
      Since there exist virtio-win drivers that are shipped on
      2.88 floppy images, this patch will allow VMs booted without
      a floppy disk inserted to later insert a 2.88MB floppy and
      have that work.
      
      This patch has been tested with msdos, freedos, fedora,
      windows 8 and windows 10 without issue: if problems do
      arise for certain guests being unable to cope with 2.88MB
      drives as the default, they are in the minority and can use
      type=144 as needed (or insert a proper boot medium and omit
      type=144/288 or use type=auto) to obtain different drive types.
      
      As icing, the default will remain auto/144 for any pre-2.6
      machine types, hopefully minimizing the impact of this change
      in legacy hw to basically zero.
      Reviewed-by: NEric Blake <eblake@redhat.com>
      Signed-off-by: NJohn Snow <jsnow@redhat.com>
      Message-id: 1453495865-9649-13-git-send-email-jsnow@redhat.com
      4812fa27
    • J
      qtest/fdc: Support for 2.88MB drives · 62c76250
      John Snow 提交于
      The old test assumes a 1.44MB drive.
      Assert that the QEMU default drive is now either 1.44 or 2.88.
      Reviewed-by: NEric Blake <eblake@redhat.com>
      Signed-off-by: NJohn Snow <jsnow@redhat.com>
      Message-id: 1453495865-9649-12-git-send-email-jsnow@redhat.com
      62c76250
    • J
      fdc: rework pick_geometry · f31937aa
      John Snow 提交于
      This one is the crazy one.
      
      fd_revalidate currently uses pick_geometry to tell if the diskette
      geometry has changed upon an eject/insert event, but it won't allow us
      to insert a 1.44MB diskette into a 2.88MB drive. This is inflexible.
      
      The new algorithm applies a new heuristic to guessing disk geometries
      that allows us to switch diskette types as long as the physical size
      matches before falling back to the old heuristic.
      
      The old one is roughly:
       - If the size (sectors) and type matches, choose it.
       - Fall back to the first geometry that matched our type.
      
      The new one is:
       - If the size (sectors) and type matches, choose it.
       - If the size (sectors) and physical size match, choose it.
       - Fall back to the first geometry that matched our type.
      Signed-off-by: NJohn Snow <jsnow@redhat.com>
      Reviewed-by: NEric Blake <eblake@redhat.com>
      Message-id: 1453495865-9649-11-git-send-email-jsnow@redhat.com
      f31937aa
    • J
      fdc: add physical disk sizes · 109c17bc
      John Snow 提交于
      2.88MB capable drives can accept 1.44MB floppies,
      for instance. To rework the pick_geometry function,
      we need to know if our current drive can even accept
      the type of disks we're considering.
      
      NB: This allows us to distinguish between all of the
      "total sectors" collisions between 1.20MB and 1.44MB
      diskette types, by using the physical drive size as a
      differentiator.
      Reviewed-by: NEric Blake <eblake@redhat.com>
      Signed-off-by: NJohn Snow <jsnow@redhat.com>
      Message-id: 1453495865-9649-10-git-send-email-jsnow@redhat.com
      109c17bc
    • J
      fdc: add drive type option · fff4687b
      John Snow 提交于
      This patch adds a new explicit Floppy Drive Type option. The existing
      behavior in QEMU is to automatically guess a drive type based on the
      media inserted, or if a diskette is not present, arbitrarily assign one.
      
      This behavior can be described as "auto." This patch adds the option
      to pick an explicit behavior: 120, 144, 288 or none. The new "auto"
      option is intended to mimic current behavior, while the other types
      pick one explicitly.
      
      Set the type given by the CLI during fd_init. If the type remains the
      default (auto), we'll attempt to scan an inserted diskette if present
      to determine a type. If auto is selected but no diskette is present,
      we fall back to a predetermined default (currently 1.44MB to match
      legacy QEMU behavior.)
      Reviewed-by: NEric Blake <eblake@redhat.com>
      Signed-off-by: NJohn Snow <jsnow@redhat.com>
      Message-id: 1453495865-9649-9-git-send-email-jsnow@redhat.com
      fff4687b
    • J
      fdc: Add fallback option · a73275dd
      John Snow 提交于
      Currently, QEMU chooses a drive type automatically based on the inserted
      media. If there is no disk inserted, it chooses a 1.44MB drive type.
      
      Change this behavior to be configurable, but leave it defaulted to 1.44.
      
      This is not earnestly intended to be used by a user or a management
      library, but rather exists so that pre-2.6 board types can configure it
      to be a legacy value.
      Reviewed-by: NEric Blake <eblake@redhat.com>
      Signed-off-by: NJohn Snow <jsnow@redhat.com>
      Message-id: 1453495865-9649-8-git-send-email-jsnow@redhat.com
      a73275dd
    • J
      fdc: add pick_drive · d5d47efc
      John Snow 提交于
      Split apart pick_geometry by creating a pick_drive routine that will only
      ever called during device bring-up instead of relying on pick_geometry to
      be used in both cases.
      
      With this change, the drive field is changed to be 'write once'. It is
      not altered after the initialization routines exit.
      
      media_validated does not need to be migrated. The target VM
      will just revalidate the media on post_load anyway.
      Reviewed-by: NEric Blake <eblake@redhat.com>
      Signed-off-by: NJohn Snow <jsnow@redhat.com>
      Message-id: 1453495865-9649-7-git-send-email-jsnow@redhat.com
      d5d47efc
    • J
      fdc: Throw an assertion on misconfigured fd_formats table · 69ce1ac2
      John Snow 提交于
      pick_geometry is a convoluted function that makes it difficult to tell
      at a glance what QEMU's current behavior for choosing a floppy drive
      type is when it can't quite identify the diskette.
      
      The code iterates over all entries in the candidate geometry table
      ("fd_formats") and if our specific drive type matches a row in the table,
      then either "match" is set to that entry (an exact match) and the loop
      exits, or "first_match" will be non-negative (the first such entry that
      shares the same drive type), and the loop continues. If our specific
      drive type is NONE, then all drive types in the candidate geometry table
      are considered. After iteration, if "match" was not set, we fall back to
      "first match".
      
      This means that either "match" was set, or we exited the loop without an
      exact match, in which case:
      
      - If drive type is NONE, the default is truly fd_formats[0], a 1.44MB
        type, because "first_match" will always get set to the first item.
      
      - If drive type is not NONE, pick_geometry's iteration was fussier and
        only looked at rows that matched our drive type. However, since all
        possible drive types are represented in the table, we still know that
        "first match" was set.
      
      - If drive type is not NONE and the fd_formats table lists no options for
        our drive type, we choose fd_formats[1], an incomprehensibly bizarre
        choice that can never happen anyway.
      
      Correct this: If first_match is -1, it can ONLY mean we didn't edit our
      fd_formats table correctly. Throw an assertion instead.
      Reviewed-by: NEric Blake <eblake@redhat.com>
      Signed-off-by: NJohn Snow <jsnow@redhat.com>
      Message-id: 1453495865-9649-6-git-send-email-jsnow@redhat.com
      69ce1ac2
    • J
      fdc: add disk field · 16c1e3ec
      John Snow 提交于
      Currently, 'drive' is used both to represent the current diskette
      type as well as the current drive type.
      
      This patch adds a 'disk' field that is updated explicitly to match
      the type of the disk.
      
      As of this patch, disk and drive are always the same, but forthcoming
      patches to change the behavior of pick_geometry will invalidate this
      assumption.
      
      disk does not need to be migrated because it is not user-visible state
      nor is it currently used for any calculations. It is purely informative,
      and will be rebuilt automatically via fd_revalidate on the new host.
      Reviewed-by: NEric Blake <eblake@redhat.com>
      Signed-off-by: NJohn Snow <jsnow@redhat.com>
      Message-id: 1453495865-9649-5-git-send-email-jsnow@redhat.com
      16c1e3ec
    • J
      fdc: add drive type qapi enum · 2da44dd0
      John Snow 提交于
      Change the floppy drive type to a QAPI enum type, to allow us to
      specify the floppy drive type from the CLI in a forthcoming patch.
      Reviewed-by: NEric Blake <eblake@redhat.com>
      Signed-off-by: NJohn Snow <jsnow@redhat.com>
      Message-id: 1453495865-9649-4-git-send-email-jsnow@redhat.com
      2da44dd0
    • J
      fdc: reduce number of pick_geometry arguments · 21862658
      John Snow 提交于
      Modify this function to operate directly on FDrive objects instead of
      unpacking and passing all of those parameters manually. Reduces the
      complexity in the caller and reduces the number of args to just one.
      Reviewed-by: NEric Blake <eblake@redhat.com>
      Signed-off-by: NJohn Snow <jsnow@redhat.com>
      Message-id: 1453495865-9649-3-git-send-email-jsnow@redhat.com
      21862658
    • J
      fdc: move pick_geometry · 9a972233
      John Snow 提交于
      Code motion: I want to refactor this function to work with FDrive
      directly, so shuffle it below that definition.
      Reviewed-by: NEric Blake <eblake@redhat.com>
      Signed-off-by: NJohn Snow <jsnow@redhat.com>
      Message-id: 1453495865-9649-2-git-send-email-jsnow@redhat.com
      9a972233
    • S
      ide: Correct the CHS 'cyls_max' limit to be 65535 · 4f086994
      Shmulik Ladkani 提交于
      In b7eb0c9f:
        hw/block-common: Factor out fall back to legacy -drive cyls=...
      'blkconf_geometry()' was introduced, factoring out CHS limit validation
      code that was repeated in ide, scsi, virtio-blk.
      
      The original IDE CHS limit prior b7eb0c9f was 65535,16,255 (as per ATA
      CHS addressing).
      However the 'cyls_max' argument passed to 'blkconf_geometry' in the
      ide_dev_initfn case was accidentally set to 65536 instead of 65535.
      
      Fix, providing the correct 'cyls_max'.
      Signed-off-by: NShmulik Ladkani <shmulik.ladkani@ravellosystems.com>
      Reviewed-by: NJohn Snow <jsnow@redhat.com>
      Message-id: 1453112371-29760-1-git-send-email-shmulik.ladkani@ravellosystems.com
      Signed-off-by: NJohn Snow <jsnow@redhat.com>
      4f086994
  3. 25 1月, 2016 1 次提交
  4. 23 1月, 2016 4 次提交
  5. 22 1月, 2016 14 次提交