All of lore.kernel.org
 help / color / mirror / Atom feed
From: Boris Ostrovsky <bostrovsky@virtualiron.com>
To: Keir Fraser <Keir.Fraser@cl.cam.ac.uk>
Cc: xen-devel@lists.xensource.com
Subject: Re: [PATCH] add support for XCHG instruction accessing APIC
Date: Wed, 05 Apr 2006 10:01:24 -0400	[thread overview]
Message-ID: <4433CDB4.6080408@virtualiron.com> (raw)
In-Reply-To: <93eed1ff132a9eaf49f74dd3c8d57f5b@cl.cam.ac.uk>

Keir Fraser wrote:

>
> On 5 Apr 2006, at 10:50, Keir Fraser wrote:
>
>>> 32-bit SMP Linux uses xchg instruction to access APIC (see
>>> apic_write_atomic()). Attached is patch that adds support for
>>> this instruction.
>>>
>>> The patch also fixes missed dependencies (in xen/Rules.mk) on
>>> header files in include/asm-x86/hvm.
>>
>>
>> I wonder if it is worth adding the locking? xchg is only used to 
>> write to broken APICs -- the OS does not care about the returned 
>> value. The APIC is implemented entirely in Xen, so the lock isn't 
>> held across an ioreq round-trip to qemu-dm, right?
>

Yes, that's right --- we never leave Xen to handle APIC access.

> In fact I'm pretty sure the locking is not needed even if we did care 
> about atomicity. You're only protecting guest accesses from other 
> guest accesses, and each VCPU has its own local APIC model, so there 
> cannot be multiple simultaneous guest accesses to a single local APIC.


My only argument in favor of using the lock would be for completeness of 
the emulation. You are
absolutely right in that for Linux there seems to be no need to hold the 
lock. My concern is that
other OSs  may treat this differently. And if we don't have sources, it 
may be somewhat difficult
to  figure out that the atomicity (or lack of it) was the cause of a 
problem.

If, however, there is a strong feeling that we don't need the lock, I am 
happy to drop it.
I guess you are mostly unhappy about adding a new field to hvm_domain, 
not about performance
impact?

-boris

  reply	other threads:[~2006-04-05 14:01 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-04-04 21:24 [PATCH] add support for XCHG instruction accessing APIC Boris Ostrovsky
2006-04-05  9:50 ` Keir Fraser
2006-04-05 10:17   ` Keir Fraser
2006-04-05 14:01     ` Boris Ostrovsky [this message]
2006-04-05 14:05       ` Keir Fraser
2006-04-05 14:26         ` Boris Ostrovsky
2006-04-05 14:37           ` Keir Fraser

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=4433CDB4.6080408@virtualiron.com \
    --to=bostrovsky@virtualiron.com \
    --cc=Keir.Fraser@cl.cam.ac.uk \
    --cc=xen-devel@lists.xensource.com \
    /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.