qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Jan Kiszka <jan.kiszka@web.de>
To: "Andreas Färber" <afaerber@suse.de>
Cc: Anthony Liguori <aliguori@us.ibm.com>,
	kvm@vger.kernel.org, Gleb Natapov <gleb@redhat.com>,
	Marcelo Tosatti <mtosatti@redhat.com>,
	qemu-devel <qemu-devel@nongnu.org>,
	Blue Swirl <blauwirbel@gmail.com>, Avi Kivity <avi@redhat.com>,
	Paolo Bonzini <pbonzini@redhat.com>
Subject: Re: [Qemu-devel] [PATCH v2 1/8] kvm: Set cpu_single_env only once
Date: Sat, 11 Feb 2012 15:02:50 +0100	[thread overview]
Message-ID: <4F36750A.5060304@web.de> (raw)
In-Reply-To: <4F36742F.2050600@suse.de>

[-- Attachment #1: Type: text/plain, Size: 1615 bytes --]

On 2012-02-11 14:59, Andreas Färber wrote:
> Am 11.02.2012 14:35, schrieb Jan Kiszka:
>> On 2012-02-11 14:21, Andreas Färber wrote:
>>> CPU base class v3: http://patchwork.ozlabs.org/patch/139284/ (v4
>>> coming up)
>>>
>>> That doesn't prevent target-specific devices. Although Paolo does
>>> want that to change wrt properties.
> 
>> This patch doesn't explain yet what shall happen to cpu_single_env
>> and CPUState accesses from target-specific devices.
> 
> True. We can't change them before all targets are converted. So far I
> have 3/14 and still some review comments to work in.
> 
> Another patch in that series uses a macro
> s/ENV_GET_OBJECT/ENV_GET_CPU/ to go from CPUState -> CPU while we
> convert targets.
> 
> Depending on our taste, cpu_single_env might become cpu_single_cpu,
> single_cpu or cpu_single.
> 
>> Do you plan accessors for registers?
> 
> No, registers are in target-specific ARMCPU, S390CPU, MIPSCPU, etc.
> and their CPU*State. It would be possible to have static inline
> accessors but so far I've seen no need.

Then the devices need to have access to a CPUState pointer, just as so far.

> 
>> And a service to return the CPU object associated with the
>> execution context?
> 
> What do you mean by execution context? TLS? The modelling of the state
> is pretty orthogonal to how/where we store it.

I mean "Where come this I/O access from?" and "am I running over some
VCPU thread?". This questions need to be answered in target-specific
device models and some parts of cpus.c (the latter is one motivation for
this patch).

Jan


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 262 bytes --]

  reply	other threads:[~2012-02-11 14:03 UTC|newest]

Thread overview: 45+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-02-10 18:31 [Qemu-devel] [PATCH v2 0/8] uq/master: TPR access optimization for Windows guests Jan Kiszka
2012-02-10 18:31 ` [Qemu-devel] [PATCH v2 1/8] kvm: Set cpu_single_env only once Jan Kiszka
2012-02-11 10:02   ` Blue Swirl
2012-02-11 10:06     ` Jan Kiszka
2012-02-11 11:25       ` Blue Swirl
2012-02-11 11:49         ` Andreas Färber
2012-02-11 12:43           ` Jan Kiszka
2012-02-11 13:06             ` Andreas Färber
2012-02-11 13:07               ` Jan Kiszka
2012-02-11 13:21                 ` Andreas Färber
2012-02-11 13:35                   ` Jan Kiszka
2012-02-11 13:59                     ` Andreas Färber
2012-02-11 14:02                       ` Jan Kiszka [this message]
2012-02-11 14:12                         ` Andreas Färber
2012-02-11 14:24                           ` Jan Kiszka
2012-02-11 14:49                             ` Andreas Färber
2012-02-13  8:17                           ` Paolo Bonzini
2012-02-11 13:54             ` Blue Swirl
2012-02-11 14:00               ` Jan Kiszka
2012-02-11 14:11                 ` Blue Swirl
2012-02-11 14:18                   ` Jan Kiszka
2012-02-11 14:23                     ` Blue Swirl
2012-02-11 12:41         ` Jan Kiszka
2012-02-10 18:31 ` [Qemu-devel] [PATCH v2 2/8] Allow to use pause_all_vcpus from VCPU context Jan Kiszka
2012-02-11 14:16   ` Blue Swirl
2012-02-11 14:31     ` Jan Kiszka
2012-02-10 18:31 ` [Qemu-devel] [PATCH v2 3/8] target-i386: Add infrastructure for reporting TPR MMIO accesses Jan Kiszka
2012-02-11 14:32   ` Blue Swirl
2012-02-10 18:31 ` [Qemu-devel] [PATCH v2 4/8] kvmvapic: Add option ROM Jan Kiszka
2012-02-10 18:31 ` [Qemu-devel] [PATCH v2 5/8] kvmvapic: Introduce TPR access optimization for Windows guests Jan Kiszka
2012-02-11 15:25   ` Blue Swirl
2012-02-13 10:16     ` Jan Kiszka
2012-02-13 18:50       ` Blue Swirl
2012-02-13 19:11         ` Gleb Natapov
2012-02-13 19:22         ` Jan Kiszka
2012-02-14  7:54           ` Gleb Natapov
2012-02-14  8:55             ` Jan Kiszka
2012-02-14  8:59               ` Gleb Natapov
2012-02-10 18:31 ` [Qemu-devel] [PATCH v2 6/8] kvmvapic: Simplify mp/up_set_tpr Jan Kiszka
2012-02-10 18:31 ` [Qemu-devel] [PATCH v2 7/8] optionsrom: Reserve space for checksum Jan Kiszka
2012-02-11 11:46   ` Andreas Färber
2012-02-11 12:45     ` Jan Kiszka
2012-02-11 12:51       ` Andreas Färber
2012-02-11 12:57         ` Jan Kiszka
2012-02-10 18:31 ` [Qemu-devel] [PATCH v2 8/8] kvmvapic: Use optionrom helpers Jan Kiszka

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=4F36750A.5060304@web.de \
    --to=jan.kiszka@web.de \
    --cc=afaerber@suse.de \
    --cc=aliguori@us.ibm.com \
    --cc=avi@redhat.com \
    --cc=blauwirbel@gmail.com \
    --cc=gleb@redhat.com \
    --cc=kvm@vger.kernel.org \
    --cc=mtosatti@redhat.com \
    --cc=pbonzini@redhat.com \
    --cc=qemu-devel@nongnu.org \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).