Go to file
Junjie Mao 50e4bc1758 HV: io: refactoring vmexit handler on I/O instruction
This patch refactors how I/O instructions are emulated, in order for a unify the
I/O emulation path. The major control flow includes:

1. pio_instr_vmexit_handler (entry point for handling vmexit on I/O instruction):

    Extract port address, register size, direction and value (for write only),
    fill in an I/O request (of type io_request), invokes do_io to handle that
    and update the guest registers if the request has been successfully handled
    when do_io returns.

2. emulate_io:

    Handle the given I/O request. The request is handled or sent to VHM if it
    returns 0 (the actual status can be found in io_req->processed). On errors a
    negative error code is returned.

3. emulate_pio_by_handler:

    Look for the PIO handler for the given request and invoke that
    handler. Return 0 if a proper handler is found and invoked (the status of
    the emulation can be found in io_req->processed), -EIO when the request
    spans across devices, and -ENODEV when no handler is found.

4. emulate_pio_post:

    Update guest registers after the emulation is done. Currently this can
    happen either right after do_io() or after the vcpu is resumed. Status check
    on the I/O request and follow-up actions on failure will also go here.

Note:

Currently do_io can return 0 with io_req->processed being REQ_STATE_PENDING if
the request is sent to VHM for further processing. In this case the current vcpu
will be paused after handling this vm_exit, and dm_emulate_pio_post will be
invoked to do the rest after this vcpu is resumed. When vcpus are scheduled back
to exactly where they are scheduled out later, do_io should be responsible for
the post_work and the processing of do_io results shall be mostly the same.

v2 -> v3:

    * Rename: emulate_pio_by_handler -> hv_emulate_pio.
    * Properly mask the value passed to port I/O handler.

v1 -> v2:

    * Rename: do_io -> emulate_io.
    * Rename io_instr_vmexit_handler -> pio_instr_vmexit_handler to reflect the
      fact that it handles port I/O only.

Signed-off-by: Junjie Mao <junjie.mao@intel.com>
Acked-by: Eddie Dong <eddie.dong@intel.com>
2018-07-31 10:22:03 +08:00
.travis-dockerfiles Dockerfile: remove security by-pass in Clear Linux Dockerfile 2018-07-11 21:35:31 +08:00
devicemodel IOC mediator: fix IOC mediator blocks acrn-dm shutdown flow 2018-07-30 12:31:50 +08:00
doc doc: tweak formatting for :kbd: role 2018-07-30 16:13:03 -07:00
hypervisor HV: io: refactoring vmexit handler on I/O instruction 2018-07-31 10:22:03 +08:00
misc tools: replace payload[0] of struct mngr_msg with an union 2018-07-19 11:08:18 +08:00
scripts HV: make: rename minimalconfig to savedefconfig 2018-06-15 15:50:09 +08:00
tools Documentation: add needed library for acrnprobe 2018-07-27 16:38:21 +08:00
.gitignore doc: add hypervisor kconfig option reference 2018-06-15 15:20:43 -07:00
.travis.yml Update Travis CI files to account for new build dependencies 2018-06-01 13:16:06 +08:00
CODEOWNERS devops: update CODEOWNERS for tools/acrn-crashlog 2018-05-23 17:10:51 +08:00
LICENSE Create LICENSE (#168) 2018-05-15 18:03:33 +08:00
Makefile Build system: add target to build documentation 2018-06-15 13:32:08 +08:00
README.rst doc: update README technical community meeting 2018-05-30 12:01:57 -07:00
VERSION version: 0.2-unstable 2018-07-12 12:14:33 +00:00

README.rst

Project ACRN Embedded Hypervisor
################################


The open source project ACRN defines a device hypervisor reference stack
and an architecture for running multiple software subsystems, managed
securely, on a consolidated system by means of a virtual machine
manager. It also defines a reference framework implementation for
virtual device emulation, called the "ACRN Device Model".

The ACRN Hypervisor is a Type 1 reference hypervisor stack, running
directly on the bare-metal hardware, and is suitable for a variety of
IoT and embedded device solutions. The ACRN hypervisor addresses the
gap that currently exists between datacenter hypervisors, and hard
partitioning hypervisors. The ACRN hypervisor architecture partitions
the system into different functional domains, with carefully selected
guest OS sharing optimizations for IoT and embedded devices.

.. start_include_here

Community Support
*****************

The Project ACRN Developer Community includes developers from member
organizations and the general community all joining in the development of
software within the project. Members contribute and discuss ideas,
submit bugs and bug fixes. They also help those in need
through the community's forums such as mailing lists and IRC channels. Anyone
can join the developer community and the community is always willing to help
its members and the User Community to get the most out of Project ACRN.

Welcome to the project ARCN community!

We're now holding weekly Technical Community Meetings and encourage you
to call in and learn more about the project. Meeting information is on
the `TCM Meeting page`_ in our `ACRN wiki <https://wiki.projectacrn.org/>`_.

.. _TCM Meeting page:
   https://github.com/projectacrn/acrn-hypervisor/wiki/ACRN-Committee-and-Working-Group-Meetings#technical-community-meetings

Resources
*********

Here's a quick summary of resources to find your way around the Project
ACRN support systems:

* **Project ACRN Website**: The https://projectacrn.org website is the
  central source of information about the project. On this site, you'll
  find background and current information about the project as well as
  relevant links to project material.  For a quick start, refer to the
  `Introduction`_ and `Getting Started Guide`_.

* **Source Code in GitHub**: Project ACRN source code is maintained on a
  public GitHub repository at https://github.com/projectacrn/acrn-hypervisor.
  You'll find information about getting access to the repository and how to
  contribute to the project in this `Contribution Guide`_ document.

* **Documentation**: Project technical documentation is developed
  along with the project's code, and can be found at
  https://projectacrn.github.io.  Additional documentation is maintained in
  the `Project ACRN GitHub wiki`_.

* **Issue Reporting and Tracking**: Requirements and Issue tracking is done in
  the Github issues system: https://github.com/projectacrn/acrn-hypervisor/issues.
  You can browse through the reported issues and submit issues of your own.

* **Mailing List**: The `Project ACRN Development mailing list`_ is perhaps the most convenient
  way to track developer discussions and to ask your own support questions to
  the project ACRN community.  There are also specific `ACRN mailing list
  subgroups`_ for builds, users, and Technical
  Steering Committee notes, for example.
  You can read through the message archives to follow
  past posts and discussions, a good thing to do to discover more about the
  project.


.. _Introduction: https://projectacrn.github.io/latest/introduction/
.. _Getting Started Guide: https://projectacrn.github.io/latest/getting_started/
.. _Contribution Guide: https://projectacrn.github.io/latest/contribute.html
.. _Project ACRN GitHub wiki: https://github.com/projectacrn/acrn-hypervisor/wiki
.. _Project ACRN Development mailing list: https://lists.projectacrn.org/g/acrn-dev
.. _ACRN mailing list subgroups: https://lists.projectacrn.org/g/main/subgroups