Re: [RFC][PATCH v2 1/1] Add IOREQ_TYPE_VMWARE_PORT

[Don Slutz <dslutz@verizon.com>]

On 10/06/14 05:39, Jan Beulich wrote:
>>>> On 06.10.14 at 11:21, <stefano.stabellini@eu.citrix.com> wrote:
>> On Mon, 6 Oct 2014, Jan Beulich wrote:
>>>>>> On 03.10.14 at 21:27, <dslutz@verizon.com> wrote:
>>>> --- a/xen/include/public/hvm/ioreq.h
>>>> +++ b/xen/include/public/hvm/ioreq.h
>>>> @@ -85,11 +85,22 @@ struct vmware_ioreq {
>>>>    };
>>>>    typedef struct vmware_ioreq vmware_ioreq_t;
>>>>
>>>> +union union_ioreq {
>>>> +    ioreq_t oreq;
>>>> +    vmware_ioreq_t vreq;
>>>> +};
>>>> +typedef union union_ioreq union_ioreq_t;
>>>> +
>>>>    struct shared_iopage {
>>>>        struct ioreq vcpu_ioreq[1];
>>>>    };
>>>>    typedef struct shared_iopage shared_iopage_t;
>>>>
>>>> +struct union_shared_iopage {
>>>> +    union union_ioreq vcpu_ioreq[1];
>>>> +};
>>>> +typedef struct union_shared_iopage union_shared_iopage_t;
>>> I don't think either of these really need to be part of the public
>>> interface.
>> Do you prefer this union mechanism or the original code of this patch
>> 1412274977-6098-2-git-send-email-dslutz@verizon.com?
>>
>> I haven't see the QEMU code for the union approach, but both
>> alternatives would probably be fine from the QEMU POV.

Adding this union mechanism in QEMU would be making it part
of the public interface.  So I have not yet coded it up.

> I'm fine with the union approach (subject to convincing myself that
> all this effort and new code is really worth it in the first place, as
> said elsewhere before), just not as part of the public interface
> (unless there is a clear need for it to be there).

I am read this as yes, add the union_ioreq_t to Xen but not to QEMU.

I know of at least 1 custom kernel that requires the VMware "rpc" code.
So I think that vmware_port support is just like viridian support. It allows
more guests to be run under Xen.

With the statement "move VMware rpc to QEMU", this patch was needed.

Hope, this helps.

    -Don Slutz

> Jan
>