netdev - RE: [RFC PATCH v9 6/8] psci: Add hvc call service for ptp

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <HE1PR0801MB1676C93AF0AA7980F4A79B3FF4340@HE1PR0801MB1676.eurprd08.prod.outlook.com>
Date:   Tue, 14 Jan 2020 10:34:51 +0000
From:   Jianyong Wu <Jianyong.Wu@....com>
To:     Marc Zyngier <maz@...nel.org>
CC:     "netdev@...r.kernel.org" <netdev@...r.kernel.org>,
        "yangbo.lu@....com" <yangbo.lu@....com>,
        "john.stultz@...aro.org" <john.stultz@...aro.org>,
        "tglx@...utronix.de" <tglx@...utronix.de>,
        "pbonzini@...hat.com" <pbonzini@...hat.com>,
        "sean.j.christopherson@...el.com" <sean.j.christopherson@...el.com>,
        "richardcochran@...il.com" <richardcochran@...il.com>,
        Mark Rutland <Mark.Rutland@....com>,
        "will@...nel.org" <will@...nel.org>,
        Suzuki Poulose <Suzuki.Poulose@....com>,
        Steven Price <Steven.Price@....com>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "linux-arm-kernel@...ts.infradead.org" 
        <linux-arm-kernel@...ts.infradead.org>,
        "kvmarm@...ts.cs.columbia.edu" <kvmarm@...ts.cs.columbia.edu>,
        "kvm@...r.kernel.org" <kvm@...r.kernel.org>,
        Steve Capper <Steve.Capper@....com>,
        Kaly Xin <Kaly.Xin@....com>, Justin He <Justin.He@....com>,
        nd <nd@....com>
Subject: RE: [RFC PATCH v9 6/8] psci: Add hvc call service for ptp_kvm.

Hi Marc,

> -----Original Message-----
> From: Marc Zyngier <maz@...nel.org>
> Sent: Monday, January 13, 2020 7:16 PM
> To: Jianyong Wu <Jianyong.Wu@....com>
> Cc: netdev@...r.kernel.org; yangbo.lu@....com; john.stultz@...aro.org;
> tglx@...utronix.de; pbonzini@...hat.com; sean.j.christopherson@...el.com;
> richardcochran@...il.com; Mark Rutland <Mark.Rutland@....com>;
> will@...nel.org; Suzuki Poulose <Suzuki.Poulose@....com>; Steven Price
> <Steven.Price@....com>; linux-kernel@...r.kernel.org; linux-arm-
> kernel@...ts.infradead.org; kvmarm@...ts.cs.columbia.edu;
> kvm@...r.kernel.org; Steve Capper <Steve.Capper@....com>; Kaly Xin
> <Kaly.Xin@....com>; Justin He <Justin.He@....com>; nd <nd@....com>
> Subject: Re: [RFC PATCH v9 6/8] psci: Add hvc call service for ptp_kvm.
> 
> Hi Jianyong,
> 
> On 2020-01-13 10:30, Jianyong Wu wrote:
> > Hi Marc,
> >
> >> -----Original Message-----
> >> From: Marc Zyngier <maz@...nel.org>
> >> Sent: Friday, January 10, 2020 6:56 PM NV breaks that assumtion,
> >> because the guest hypervisor is using the physical counter. Also,
> >> let's not forget that the hypercall isn't Linux specific.
> >> I can write my own non-Linux guest and still use this hypercall.
> >> Nothing in
> >> there says that I can't use the physical counter if I want to.
> >>
> >> So somehow, you need to convey the the hypervisor the notion of
> >> *which*
> >> counter the guest uses.
> >>
> >> Does it make sense? Or am I missing something?
> >>
> > I know what you say. Let me try to solve this problem.
> > 	Step 0, summary out all the conditions we should process, which will
> > sever as branch condition.(now only normal virt and nested virt, I
> > think)
> 
> No. You shouldn't think of the various use cases, but of which time
> references a guest can use. You don't need nested virt to use the physical
> counter, for example.
Ok,

> 
> > 	Step 1, figure out the set of reference counter value used by guest
> > in all condition.
> 
> That should be for the guest to tell you when it calls into the PV service.
> 
Yeah

> > 	Step 2, determine which reference counter value will be used by
> guest
> > in a certain condition in hypercall.
> > In step 1, can we give the set only 2 elements that one is physical
> > counter the other is virtual counter?
> 
> I don't think returning the two values is useful. Just return what the guest
> asks for.
> 
> > For step 2, I have no idea for that now. can you give me some hint
> > about it?
> 
> Just expand your SMC call to take a parameter indicating the reference
> counter, and return the sampled (or computed) value corresponding to that
> counter.
Get it, I'll try it.

Thanks
Jianyong 

> 
>          M.
> --
> Jazz is not dead. It just smells funny...