linux-kernel - Re: [QUERY] lguest64

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] [thread-next>] [day] [month] [year] [list]

Date:	Fri, 2 Aug 2013 15:09:34 -0400
From:	Konrad Rzeszutek Wilk <konrad.wilk@...cle.com>
To:	"H. Peter Anvin" <hpa@...or.com>,
	Mukesh Rathor <mukesh.rathor@...cle.com>
Cc:	Mike Rapoport <mike.rapoport@...il.com>,
	Rusty Russell <rusty@...tcorp.com.au>,
	Ramkumar Ramachandra <artagnon@...il.com>,
	LKML <linux-kernel@...r.kernel.org>,
	xen-devel@...ts.xensource.com
Subject: Re: [QUERY] lguest64

On Wed, Jul 31, 2013 at 06:25:04AM -0700, H. Peter Anvin wrote:
> On 07/31/2013 06:17 AM, Konrad Rzeszutek Wilk wrote:
> >>
> >> The big problem with pvops is that they are a permanent tax on future
> >> development -- a classic case of "the hooks problem."  As such it is
> >> important that there be a real, significant, use case with enough users
> >> to make the pain worthwhile.  With Xen looking at sunsetting PV support
> >> with a long horizon, it might currently be possible to remove pvops some
> > 
> > PV MMU parts specifically.
> > 
> 
> Pretty much stuff that is driverized on plain hardware doesn't matter.
> What are you looking at with respect to the basic CPU control state?


CC-ing Mukesh here.

Let me iterate down what the experimental patch uses:

         struct pv_init_ops pv_init_ops;                                         
		[still use xen_patch, but I think that is not needed anymore]

         struct pv_time_ops pv_time_ops;                                         
		[we need that as we are using the PV clock source]

         struct pv_cpu_ops pv_cpu_ops;                                           
		[only end up using cpuid. This one is a tricky one. We could
		 arguable remove it but it does do some filtering - for example
	 	 THERM is turned off, or MWAIT if a certain hypercall tells us to
		 disable that. Since this is now a trapped operation this could be
		 handled in the hypervisor - but then it would be in charge of
		 filtering certain CPUID - and this is at bootup - so there is not
		 user interaction. This needs a bit more of thinking]

         struct pv_irq_ops pv_irq_ops;                                           
		[none so far, we use normal sti/cli

         struct pv_apic_ops pv_apic_ops;                                         
		[we over-write them without own event channel logic for IPI's, etc.
		Thought with virtualized APIC this could be done differently and
		some Intel engineers told me that they have it on their roadmap]
	
         struct pv_mmu_ops pv_mmu_ops;                                           
		[we use two:
		- .flush_tlb_others (xen_flush_tlb_others) - and I think we
		  actually remove that. Mukesh, do you recall why we need it?
		 - .pagetable_init - but that can be moved out as the
		only reason it does that is to use a new address (__va)
		on the shared page (it swaps out of using the __kva to
		using __va).]

         struct pv_lock_ops pv_lock_ops;   
		[still using that]


Please please take this with a grain of salt. The patches are still experimental
so we might be missing something and this is not set in stone.


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/