Re: [PATCH for-4.5 v8 4/7] xen: Add vmware_port support

[Don Slutz <dslutz@verizon.com>]

On 01/28/15 03:19, Jan Beulich wrote:
>>>> On 27.01.15 at 08:58, <JBeulich@suse.com> wrote:
>>>>> On 26.01.15 at 21:19, <dslutz@verizon.com> wrote:
>>> On 01/26/15 11:46, Jan Beulich wrote:
>>>> As stated before - if feasible, 8 would seem the best option. The
>>>> second best one would be to support all four I/O insns (assuming
>>>> VMware supports all of them too) with any legal (even if pointless
>>>> or redundant) prefix combination, and with the prefixes actually
>>>> doing something correctly emulated.
>>>
>>> Ok, I will focus on hvm_emulate_one.
>>
>> Just to avoid any misunderstanding - it's another clone of it that
>> you'll want to create, with presumably only .insn_fetch, .read_io, and
>> .write_io implemented (and maybe a few others stubbed out, where
>> the core emulator assumes they're non-NULL).
> 
> And I just recalled that I think in mem-event context it was already
> suggested to perhaps separate instruction decoding from emulation,
> which might be a mode also suitable for your needs. Maybe get in
> touch with Razvan or Tamas or whoever it was, who might already
> be working on that.
>

You mean like hvm_emulate_one_no_write() (which is already
there)?

It looks to me to be a starting place of how to do this.
So I currently do not plan on seeking help here.


The delay is not in coding up this, but is that QEMU master (and now
xenbits's qemu staging) do not work with my changes and so far I am
unable to link why this is the case.  I am adding a new hvm param
as part of getting vmport requests to QEMU (HVM_PARAM_VMPORT_REGS_PFN)
which changes QEMU to call xc_map_foreign_range() 1 more time.  However
what is failing is hvmloader's pci setup and scan (~70 ioreqs work and
the next one hangs because it is sent to the default QEMU which does not
"exist" because of the patch in QEMU:


commit 7665d6ba98e20fb05c420de947c1750fd47e5c07
Author: Paul Durrant <paul.durrant@citrix.com>
Date:   Tue Jan 20 11:06:19 2015 +0000

    Xen: Use the ioreq-server API when available

    The ioreq-server API added to Xen 4.5 offers better security than
    the existing Xen/QEMU interface because the shared pages that are
    used to pass emulation request/results back and forth are removed
    from the guest's memory space before any requests are serviced.
    This prevents the guest from mapping these pages (they are in a
    well known location) and attempting to attack QEMU by synthesizing
    its own request structures. Hence, this patch modifies configure
    to detect whether the API is available, and adds the necessary
    code to use the API if it is.

    upstream-commit-id: 3996e85c1822e05c50250f8d2d1e57b6bea1229d

    Signed-off-by: Paul Durrant <paul.durrant@citrix.com>
    Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
    Acked-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>



Since I had the code for handing off vmport requests to QEMU I was
planning on adding those patches to this patch set.  Now that I have hit
a road block, the best I can do is put out a next RFC version of
these patches with the issue listed.

So I will switch to spending most of my time on reworking (like a new
hvm_emulate_one_vmport() (or hvm_emulate_one_gp()).


   -Don Slutz

> Jan
>