linux-kernel - Re: hardwired VMI crap

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]

Message-ID: <45F08B71.50606@vmware.com>
Date:	Thu, 08 Mar 2007 14:17:21 -0800
From:	Zachary Amsden <zach@...are.com>
To:	Ingo Molnar <mingo@...e.hu>
CC:	tglx@...utronix.de, Jeremy Fitzhardinge <jeremy@...p.org>,
	john stultz <johnstul@...ibm.com>, akpm@...ux-foundation.org,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	LKML <linux-kernel@...r.kernel.org>,
	Pratap Subrahmanyam <pratap@...are.com>,
	Rusty Russell <rusty@...tcorp.com.au>, Andi Kleen <ak@...e.de>,
	Daniel Hecht <dhecht@...are.com>,
	Daniel Arai <arai@...are.com>,
	Chris Wright <chrisw@...s-sol.org>
Subject: Re: hardwired VMI crap

Ingo Molnar wrote:
> * Zachary Amsden <zach@...are.com> wrote:
>
>   
>> When we're about two weeks away from a product release and you are 
>> threatening to unmerge or block our code because we didn't create an 
>> abstract interrupt controller, we re-used the APIC and IO-APIC, this 
>> is uber rocket science. [...]
>>     
>
> see my mail to you below: you've been told about the clockevents problem 
> months ago, that you shouldnt hardwire PIT details and that you should 
> be registering a clockevents device. You cannot credibly claim that you 
> didnt know about this.
>   

I am claiming no such thing.  My claim is that nobody ever said, well 
unless you you clockevents, we're going to break your code, then nack 
any possible way to fix it, and now for spite, since you are in the 
kernel tree, we're going to nack any attempt to use clockevents.

It was our plan to convert to using clockevents all along.  It was never 
said that this was such a huge, showstopping issue, and so we didn't see 
any reason to change the timer code any further for 2.6.21, specifically 
because the integration with hrtimers caused so much pain and debugging 
for us.  Our code was working fine, then clocksources came along, and we 
had to change.  Then clockevents came along, had bugs of its own to work 
out, and caused a huge amount of grief and debugging for us.  So when we 
had something working, we drew the line and figured we could make the 
leap to CE in the next kernel.

>> We've been doing things this way, with public patches for over a year, 
>> and you've even been CC'd on some of the discussions. [...]
>>     
>
> i've specifically objected, numerous times - the result of which was 
> that when you submitted it to lkml you didnt Cc: me ;) The VMI crap went 
> in 'under the radar' via the x86_64 tree.
>
>   
>> [...]  So it is a little late to tell us - "redesign your hypervisor, 
>> or else.."
>>     
>
> Also, it was /you/ who claimed that paravirt_ops can take care of 
> whatever design change on the Linux side - that claim is apparently 
> history now and you are now claiming "there's a product on the road, we 
> cannot change the hypervisor ABI"? Should i cite that email of yours 
> too?
>   

Ingo, either you or Thomas have vetoed every attempt we have made to 
make our code operate with clockevents.  There are serious platform 
issues here that make this difficult, no matter how many nice, well 
designed, abstract, higher-level kernel interfaces we have to work with, 
we have to work around platform code which makes the wrong assumptions.

Citing already established facts doesn't do anything productive.  Can I 
please get some feedback on the design choices I have proposed for how 
to integrate VMI timer?

Thanks,

Zach
-
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/