From mboxrd@z Thu Jan 1 00:00:00 1970 From: Tamas K Lengyel Subject: Re: [PATCH] vm_event: Implement ARM SMC events Date: Tue, 12 Apr 2016 09:08:40 -0600 Message-ID: References: <1460404042-31179-1-git-send-email-tamas@tklengyel.com> <570C881A02000078000E6497@prv-mh.provo.novell.com> <570C891E.5090904@bitdefender.com> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============0371535199426187187==" Return-path: Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xenproject.org with esmtp (Exim 4.84_2) (envelope-from ) id 1apzvq-0007fg-8A for xen-devel@lists.xenproject.org; Tue, 12 Apr 2016 15:08:46 +0000 Received: by mail-yw0-f178.google.com with SMTP id i84so27833211ywc.2 for ; Tue, 12 Apr 2016 08:08:42 -0700 (PDT) Received: from mail-yw0-f170.google.com (mail-yw0-f170.google.com. [209.85.161.170]) by smtp.gmail.com with ESMTPSA id 204sm17785551ywr.32.2016.04.12.08.08.40 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 12 Apr 2016 08:08:40 -0700 (PDT) Received: by mail-yw0-f170.google.com with SMTP id d68so27897137ywe.1 for ; Tue, 12 Apr 2016 08:08:40 -0700 (PDT) In-Reply-To: <570C891E.5090904@bitdefender.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xen.org Sender: "Xen-devel" To: Razvan Cojocaru Cc: wei.liu2@citrix.com, Keir Fraser , stefano.stabellini@eu.citrix.com, andrew.cooper3@citrix.com, Ian Jackson , julien.grall@arm.com, Jan Beulich , xen-devel@lists.xenproject.org List-Id: xen-devel@lists.xenproject.org --===============0371535199426187187== Content-Type: multipart/alternative; boundary=001a114e5b2e4cce3105304b09be --001a114e5b2e4cce3105304b09be Content-Type: text/plain; charset=UTF-8 > >> @@ -254,6 +279,7 @@ typedef struct vm_event_st { > > >union { > > >union { > > >struct vm_event_regs_x86 x86; > >> + struct vm_event_regs_arm arm; > > >} regs; > > > > Does this alter the x86 ABI? Perhaps the ARM structure is small enough for > > this to not happen now, but what's the general idea about not breaking other > > arch'es ABIs when adding support for a new arch here? > > I'd suggest modifying VM_EVENT_INTERFACE_VERSION whenever that becomes > the case. > Yeap, that's what I had in mind too, if we end up changing the layout or the size of the struct we will increment the version. Tamas --001a114e5b2e4cce3105304b09be Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


> >> @@ -254,6 +279,7 @@ typedef struct vm_event_st {
> >=C2=A0 =C2=A0 =C2=A0 >union {
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 >union {
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 >struct vm_eve= nt_regs_x86 x86;
> >> +=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 struct vm_event_re= gs_arm arm;
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 >} regs;
> >
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Does this alter the x86 ABI? Pe= rhaps the ARM structure is small enough for
> > this to not happen now, but what's the general idea about not= breaking other
> > arch'es ABIs when adding support for a new arch here?
>
> I'd suggest modifying VM_EVENT_INTERFACE_VERSION whenever that bec= omes
> the case.
>

Yeap, that's what I had in mind too, if we end up changi= ng the layout or the size of the struct we will increment the version.

Tamas

--001a114e5b2e4cce3105304b09be-- --===============0371535199426187187== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: base64 Content-Disposition: inline X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KWGVuLWRldmVs IG1haWxpbmcgbGlzdApYZW4tZGV2ZWxAbGlzdHMueGVuLm9yZwpodHRwOi8vbGlzdHMueGVuLm9y Zy94ZW4tZGV2ZWwK --===============0371535199426187187==--