Mailing List Archive

[PATCH 0/4] Add V4V to Xen v5
v5 changes:
- Fix prototypes in v4v.h for do_v4v_op
- Add padding to make sure all the structures
are 64 bits aligned
- Replace [0] with []

v4 changes:
- Stop using ssize_t, use long instead
- Return -MSGSIZE for message bigger than 2GB
- Fixup size handling
- Rename protocol with message_type to avoid the
confusion with the IP protocol flag
- Replaced V4V_DOMID_ANY value with DOMID_INVALID
- Replaced v4v_pfn_t with xen_pfn_t
- Add padding to struct v4v_info
- Fixup hypercall documentation
- Move V4V_ROUNDUP to v4v.c
- Remove v4v_utils.h (we could potentially add it later).

v3 changes:
- Switch to event channel
- Allocated a unbound event channel
per domain.
- Add a new v4v call to share the
event channel port.
- Public headers with actual type definition
- Align all the v4v type to 64 bits
- Modify v4v MAGIC numbers because we won't
but backward compatible anymore
- Merge insert and insertv
- Merge send and sendv
- Turn all the lock prerequisite from comment
to ASSERT()
- Make use or write_atomic instead of volatile pointers
- Merge v4v_memcpy_to_guest_ring and
v4v_memcpy_to_guest_ring_from_guest
- Introduce copy_from_guest_maybe that can take
a void * and a handle as src address.
- Replace 6 arguments hypercalls with 5 arguments hypercalls.

v2 changes:
- Cleanup plugin header
- Include basic access control
- Use guest_handle_for_field

Jan Beulich (1):
xen: Introduce guest_handle_for_field

Jean Guyader (3):
xen: virq, remove VIRQ_XC_RESERVED
xen: events, exposes evtchn_alloc_unbound_domain
xen: Add V4V implementation

xen/arch/x86/hvm/hvm.c | 6 +-
xen/arch/x86/x86_64/compat/entry.S | 2 +
xen/arch/x86/x86_64/entry.S | 2 +
xen/common/Makefile | 1 +
xen/common/domain.c | 13 +-
xen/common/event_channel.c | 39 +-
xen/common/v4v.c | 1905 ++++++++++++++++++++++++++++++++++++
xen/include/asm-x86/guest_access.h | 3 +
xen/include/public/v4v.h | 308 ++++++
xen/include/public/xen.h | 3 +-
xen/include/xen/event.h | 3 +
xen/include/xen/sched.h | 4 +
xen/include/xen/v4v.h | 133 +++
13 files changed, 2405 insertions(+), 17 deletions(-)
create mode 100644 xen/common/v4v.c
create mode 100644 xen/include/public/v4v.h
create mode 100644 xen/include/xen/v4v.h

--
1.7.9.5
Re: [PATCH 0/4] Add V4V to Xen v5 [ In reply to ]
>>> On 20.09.12 at 11:47, Jean Guyader <jean.guyader@citrix.com> wrote:
> v5 changes:
> - Fix prototypes in v4v.h for do_v4v_op
> - Add padding to make sure all the structures
> are 64 bits aligned
> - Replace [0] with []

But that isn't standard C either (before C99 at least).

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [PATCH 0/4] Add V4V to Xen v5 [ In reply to ]
On 20 September 2012 11:22, Jan Beulich <JBeulich@suse.com> wrote:
>>>> On 20.09.12 at 11:47, Jean Guyader <jean.guyader@citrix.com> wrote:
>> v5 changes:
>> - Fix prototypes in v4v.h for do_v4v_op
>> - Add padding to make sure all the structures
>> are 64 bits aligned
>> - Replace [0] with []
>
> But that isn't standard C either (before C99 at least).
>

I found that in xen/public/physdev.h

struct physdev_pci_device_add {
/* IN */
uint16_t seg;
uint8_t bus;
uint8_t devfn;
uint32_t flags;
struct {
uint8_t bus;
uint8_t devfn;
} physfn;
#if defined(__STDC_VERSION__) && __STDC_VERSION__ >= 199901L
uint32_t optarr[];
#elif defined(__GNUC__)
uint32_t optarr[0];
#endif
};

Would something similar be ok?

Thanks,
Jean

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [PATCH 0/4] Add V4V to Xen v5 [ In reply to ]
>>> On 20.09.12 at 12:27, Jean Guyader <jean.guyader@gmail.com> wrote:
> On 20 September 2012 11:22, Jan Beulich <JBeulich@suse.com> wrote:
>>>>> On 20.09.12 at 11:47, Jean Guyader <jean.guyader@citrix.com> wrote:
>>> v5 changes:
>>> - Fix prototypes in v4v.h for do_v4v_op
>>> - Add padding to make sure all the structures
>>> are 64 bits aligned
>>> - Replace [0] with []
>>
>> But that isn't standard C either (before C99 at least).
>>
>
> I found that in xen/public/physdev.h
>
> struct physdev_pci_device_add {
> /* IN */
> uint16_t seg;
> uint8_t bus;
> uint8_t devfn;
> uint32_t flags;
> struct {
> uint8_t bus;
> uint8_t devfn;
> } physfn;
> #if defined(__STDC_VERSION__) && __STDC_VERSION__ >= 199901L
> uint32_t optarr[];
> #elif defined(__GNUC__)
> uint32_t optarr[0];
> #endif
> };
>
> Would something similar be ok?

Yes, obviously.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel