All of lore.kernel.org
 help / color / mirror / Atom feed
From: Zachary Amsden <zach@vmware.com>
To: Alan Cox <alan@lxorguk.ukuu.org.uk>
Cc: Pavel Machek <pavel@ucw.cz>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: Re: VMI Interface Proposal Documentation for I386, Part 4
Date: Thu, 16 Mar 2006 07:29:34 -0800	[thread overview]
Message-ID: <4419845E.8060904@vmware.com> (raw)
In-Reply-To: <1142522308.13318.29.camel@localhost.localdomain>

Alan Cox wrote:
> On Iau, 2006-03-16 at 00:37 +0100, Pavel Machek wrote:
>   
>> This code used to work when ran as root:
>>     
>
> Unless it page faulted, or was on SMP, or ....
>   

Actually, quite interestingly, I believe you can take page faults in 
this scenario - you might end up getting rescheduled and lose the effect 
disabling interrupts, but I think the kernel lives on just fine - as 
long as it doesn't BUG_ON about this.  On SMP, clearly you can't 
disabled IRQs on all processors with it.  But I really think the point 
is to try to eliminate IRQs on a single processor during some critical 
timing sensitive region.  One thing you definitely can't do safely is 
make sysenter based syscalls off the vsyscall page - you will notice 
that you always come back with interrupts enabled.

I just really don't think that is a good idea to do in userspace, when 
writing a kernel module to accomplish this safely is actually really 
quite easy.  I would argue that the various CMOS timer update utilities 
in userspace that do this same thing, really should be moved into the 
kernel as fast as possible - they could race against other CPUs in 
kernel mode that are doing the same thing, and there is no locking 
discipline here whatsoever.

>   
>> I'm not sure how will X like this.
>>     
>
> X has not used this ability for many years.
>   

Good to know.  I thought some piece of xinit still used it to do 
dot-clock probing - but I could be wrong.  We really don't care about 
getting accurate information here, since the dot-clocks don't actually 
exist in a VM.  We simulate virtual SVGA hardware instead of passing 
through any installed card.

Zach

  reply	other threads:[~2006-03-16 15:31 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-03-13 19:55 VMI Interface Proposal Documentation for I386, Part 4 Zachary Amsden
2006-03-15 23:37 ` Pavel Machek
2006-03-16  7:00   ` Zachary Amsden
2006-03-16  7:00     ` Zachary Amsden
2006-03-16 15:18   ` Alan Cox
2006-03-16 15:29     ` Zachary Amsden [this message]
2006-03-16 18:40       ` Alan Cox

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4419845E.8060904@vmware.com \
    --to=zach@vmware.com \
    --cc=alan@lxorguk.ukuu.org.uk \
    --cc=linux-kernel@vger.kernel.org \
    --cc=pavel@ucw.cz \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.