All of lore.kernel.org
 help / color / mirror / Atom feed
From: Razvan Cojocaru <rcojocaru@bitdefender.com>
To: Tamas K Lengyel <tamas.lengyel@zentific.com>
Cc: Kevin Tian <kevin.tian@intel.com>,
	Stefano Stabellini <sstabellini@kernel.org>,
	Jan Beulich <jbeulich@suse.com>,
	George Dunlap <george.dunlap@eu.citrix.com>,
	Andrew Cooper <andrew.cooper3@citrix.com>,
	Julien Grall <julien.grall@arm.com>,
	Paul Durrant <paul.durrant@citrix.com>,
	Jun Nakajima <jun.nakajima@intel.com>,
	"xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>
Subject: Re: [PATCH 2/2] x86/vm_event: Allow returning i-cache for emulation
Date: Fri, 16 Sep 2016 19:09:55 +0300	[thread overview]
Message-ID: <8af58cfa-59e6-ade5-44ec-826894e35b8a@bitdefender.com> (raw)
In-Reply-To: <CAErYnshRAKuDAC8QGGcVdQ0JX7qauP=0O4VKCp-83P-M3ar1yQ@mail.gmail.com>

On 09/16/16 18:37, Tamas K Lengyel wrote:
>>>>> Since this breaks compilation of existing clients, I think we should
>>>>> >>>> increment some macro to alow for compile-time switching (maybe
>>>>> >>>> VM_EVENT_INTERFACE_VERSION?).
>>>> >>>
>>>> >>> I'm not sure I follow - this is a Xen internal-only enumeration. What
>>>> >>> kind-of clients are you referring to?
>>> >>
>>> >> Nevermind, I thought these changes propagate to the toolstack headers.
>>> >> Sorry for the confusion.
>> >
>> > On second thought (and a night's rest), the problem is real. I've made
>> > it a point to test the patches today before re-reviewing them, and this
>> > happened:
>> >
>> > bdvmixeneventmanager.cpp:359:46: error: ‘union vm_event_st::<anonymous>’
>> > has no member named ‘emul_read_data’
>> >       uint32_t rspDataSize = sizeof( rsp.data.emul_read_data.data );
>> >                                               ^
>> > bdvmixeneventmanager.cpp:386:44: error: ‘union vm_event_st::<anonymous>’
>> > has no member named ‘emul_read_data’
>> >                            action, rsp.data.emul_read_data.data,
>> > rspDataSize,
>> >                                             ^
>> > bdvmixeneventmanager.cpp:389:16: error: ‘union vm_event_st::<anonymous>’
>> > has no member named ‘emul_read_data’
>> >        rsp.data.emul_read_data.size = rspDataSize;
>> >                 ^
>> > make: *** [bdvmixeneventmanager.o] Error 1
>> >
>> > So, as you can see, existing clients really don't compile without
>> > modification.
>> >
> Hi Razvan,
> yes, for Xen 4.8 we already bumped the VM_EVENT_INTERFACE_VERSION, so
> any client building on it need to adapt accordingly.

Fair enough. That's all I was asking for / about: that we should make
sure that VM_EVENT_INTERFACE_VERSION reflects these changes. If it's
already been incremented for this pending release, that's perfect.


Thanks,
Razvan

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

  reply	other threads:[~2016-09-16 16:10 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-09-13 18:12 [PATCH 1/2] vm_event: Sanitize vm_event response handling Tamas K Lengyel
2016-09-13 18:12 ` [PATCH 2/2] x86/vm_event: Allow returning i-cache for emulation Tamas K Lengyel
2016-09-14  7:58   ` Razvan Cojocaru
2016-09-15 16:36     ` Tamas K Lengyel
2016-09-15 17:08       ` Razvan Cojocaru
2016-09-16  7:21         ` Razvan Cojocaru
2016-09-16 15:37           ` Tamas K Lengyel
2016-09-16 16:09             ` Razvan Cojocaru [this message]
2016-09-14 15:55   ` Jan Beulich
2016-09-14 16:20     ` Tamas K Lengyel
2016-09-15  5:58       ` Jan Beulich
2016-09-15 15:27         ` Tamas K Lengyel
2016-09-15 16:09           ` Jan Beulich
2016-09-14  7:49 ` [PATCH 1/2] vm_event: Sanitize vm_event response handling Razvan Cojocaru
2016-09-14  9:33 ` Julien Grall
2016-09-14 15:14   ` Tamas K Lengyel
2016-09-14 15:15     ` Julien Grall
2016-09-14 15:19       ` Tamas K Lengyel
2016-09-14 13:38 ` George Dunlap
2016-09-14 15:11   ` Tamas K Lengyel
2016-09-15 10:35     ` George Dunlap

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=8af58cfa-59e6-ade5-44ec-826894e35b8a@bitdefender.com \
    --to=rcojocaru@bitdefender.com \
    --cc=andrew.cooper3@citrix.com \
    --cc=george.dunlap@eu.citrix.com \
    --cc=jbeulich@suse.com \
    --cc=julien.grall@arm.com \
    --cc=jun.nakajima@intel.com \
    --cc=kevin.tian@intel.com \
    --cc=paul.durrant@citrix.com \
    --cc=sstabellini@kernel.org \
    --cc=tamas.lengyel@zentific.com \
    --cc=xen-devel@lists.xenproject.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.