[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] [PATCH v2 01/10] vm_event: Define VM_EVENT type


  • To: Tamas K Lengyel <tamas@xxxxxxxxxxxxx>
  • From: Petre Ovidiu PIRCALABU <ppircalabu@xxxxxxxxxxxxxxx>
  • Date: Wed, 17 Jul 2019 07:59:11 +0000
  • Accept-language: ro-RO, en-US
  • Arc-authentication-results: i=1; mx.microsoft.com 1;spf=pass smtp.mailfrom=bitdefender.com;dmarc=pass action=none header.from=bitdefender.com;dkim=pass header.d=bitdefender.com;arc=none
  • Arc-message-signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=2k4cVyBM0GqcHa3Ro1CwdNAZVq++vr/KDohX7Kd0BUw=; b=Q+dZBdK/hyyzpxl9HHUYIhO9WLBqx37oVzMTStXFbWALnyUL4S0GyhrOvwzzDEi1DgNAoqXmvuI3UKzwvjJ1PEYWBiC/gS3YF2VvzdXBRbLB0SVVLNfGys6+s2KAlqiCy0SrZU6L2KDYBqGPDqu0OAS94z8UNTeAdTscuTbKmac1yyHf1g/x/opyXxlLyrB7Dy2Di5R6q8SzQGg0xnwy28OftTAvwTG5xIiQ58od1KhU70lOyzMin6xW9hsgpDWtn+epjFGNcDUjwEyL7w5wqQ6QsRSc6snT1S9DrTQSYoaz5q5dSaLD4OPTTF9ZIBDHBDli40TmWMoDAs/X0dwU4w==
  • Arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=ce4M16m40U1BANPxcQDY1tGHWH3jVI1dBstKaoMznv/qaMN4HRgJlmb9AZ8+Yj2eLILIfDScUpwXnITxx9zHYNeQk3wlN4SLEarreJOp+jD+hntsLTGa0ZJtLxsSq0nkJCWjtqmcqntNg5EE9PHyIvcboH3Qjfo+iMjrRmPiGo/FJgkPnYvkuYpGv5KYL48fgWMl5ZlrQn1xZRRnLTzkCUpF5AFUrQVyyKxxfrLwGYcpNG5uZwb8ZWS7PAcaF2R6XyQE3DKkdSd1e9NbScLU6H9rwAKBix1AfbwsuUW8H4LYWeHEdDMDQ8kltA8g3zwgnY/Whf4HNW42oZCVac49Bg==
  • Authentication-results: spf=none (sender IP is ) smtp.mailfrom=ppircalabu@xxxxxxxxxxxxxxx;
  • Cc: Stefano Stabellini <sstabellini@xxxxxxxxxx>, Razvan Cojocaru <rcojocaru@xxxxxxxxxxxxxxx>, Wei Liu <wl@xxxxxxx>, Konrad Rzeszutek Wilk <konrad.wilk@xxxxxxxxxx>, George Dunlap <George.Dunlap@xxxxxxxxxxxxx>, Andrew Cooper <andrew.cooper3@xxxxxxxxxx>, Ian Jackson <ian.jackson@xxxxxxxxxxxxx>, Tim Deegan <tim@xxxxxxx>, Julien Grall <julien.grall@xxxxxxx>, Jan Beulich <jbeulich@xxxxxxxx>, Alexandru Stefan ISAILA <aisaila@xxxxxxxxxxxxxxx>, Xen-devel <xen-devel@xxxxxxxxxxxxxxxxxxxx>
  • Delivery-date: Wed, 17 Jul 2019 07:59:35 +0000
  • List-id: Xen developer discussion <xen-devel.lists.xenproject.org>
  • Thread-index: AQHVO/jiC7r7Phv/mUucGqu2PM/TjKbNurYAgAC4XoA=
  • Thread-topic: [PATCH v2 01/10] vm_event: Define VM_EVENT type

On Tue, 2019-07-16 at 14:59 -0600, Tamas K Lengyel wrote:
> > diff --git a/xen/include/public/vm_event.h
> > b/xen/include/public/vm_event.h
> > index 959083d..c48bc21 100644
> > --- a/xen/include/public/vm_event.h
> > +++ b/xen/include/public/vm_event.h
> > @@ -36,6 +36,37 @@
> >  #include "io/ring.h"
> > 
> >  /*
> > + * There are currently three types of VM events.
> > + */
> 
> This is a bit misleading and confusing if someone just looks at the
> header. Right now we actually have 14 different VM_EVENT_REASONs
> defined. What we have 3 of are the different rings where these events
> would be delivered, with paging and sharing having their own ring
> separate from the events under the "monitor" label.
> 
The reason I replaced "ring" with "type" is because the next patches
introduce a new mechanism for handling requests/responses without using
a ring.

I assumed the following naming convention:

Type - the "subsystem" which generates the vm_event request: monitor,
paging or sharing.
Reason - The reason why the vm_event request was sent (e.g.
VM_EVENT_REASON_MEM_ACCESS)

However, I do understand that it can be misleading without a proper
description so I will update the description.

Many thanks,
Petre


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/mailman/listinfo/xen-devel

 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.