From: Gleb Natapov <gleb@redhat.com>
To: Marcelo Tosatti <mtosatti@redhat.com>
Cc: Jan Kiszka <jan.kiszka@siemens.com>, Avi Kivity <avi@redhat.com>,
"kvm@vger.kernel.org" <kvm@vger.kernel.org>
Subject: Re: [PATCH 04/19] qemu-kvm: x86: Drop MSR reset
Date: Thu, 5 May 2011 21:08:05 +0300 [thread overview]
Message-ID: <20110505180805.GB29181@redhat.com> (raw)
In-Reply-To: <20110505133301.GA20018@amt.cnet>
On Thu, May 05, 2011 at 10:33:01AM -0300, Marcelo Tosatti wrote:
> On Thu, May 05, 2011 at 02:22:57PM +0300, Gleb Natapov wrote:
> > On Thu, May 05, 2011 at 11:32:26AM +0200, Jan Kiszka wrote:
> > > >> >
> > > >> > Of course, if we get a patch soon no one will ever see the
> > > >> regression so
> > > >> > we can apply the series.
> > > >>
> > > >> I will still require the usual testing and merging round via upstream
> > > >> and back. Not sure when I'll be able to work on it, probably not the
> > > >> next days.
> > > >
> > > > If you can do it within a couple of weeks or so that should be fine.
> > > >
> > >
> > > We'll see, but I still do not share your concern regarding future
> > > regressions when removing the fragile reset code.
> > >
> > Why do we rely on userspace to properly reset kernel component anyway?
>
> In general its required that userspace properly sets (some of) the
> parameters of emulated hardware, including on reset.
That's just how things work now. It doesn't have to be this way.
>
> > We should introduce cpu/lapic/ioapic/pit/pic resets ASAP.
>
> Thats done through userspace via ioctls, don't get your point?
Why userspace shouldn't know such low level details about in kernel
device? We had same devices emulated in qemu so it was easy to reuse
that for reset, but think about writing device model from the start.
With current interfaces you either need to have very low level knowledge
about in kernel device in userspace just to reset it properly, or you
need to save device state just after creation and reload the saved state
on reset (kind of what Avi proposed for MSR). Both solutions are not
optional IMO.
--
Gleb.
next prev parent reply other threads:[~2011-05-05 18:08 UTC|newest]
Thread overview: 40+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-05-04 19:43 [PATCH 00/19] qemu-kvm: Cleanup and switch to upstream - Part I Jan Kiszka
2011-05-04 19:43 ` [PATCH 01/19] qemu-kvm: Switch to upstream mp_state functions Jan Kiszka
2011-05-04 19:43 ` [PATCH 02/19] qemu-kvm: x86: Use upstream kvmclock device Jan Kiszka
2011-05-04 19:43 ` [PATCH 03/19] Revert "introduce VMSTATE_U64" Jan Kiszka
2011-05-04 19:43 ` [PATCH 04/19] qemu-kvm: x86: Drop MSR reset Jan Kiszka
2011-05-05 8:08 ` Avi Kivity
2011-05-05 8:11 ` Jan Kiszka
2011-05-05 8:16 ` Avi Kivity
2011-05-05 8:27 ` Jan Kiszka
2011-05-05 8:33 ` Avi Kivity
2011-05-05 8:44 ` Jan Kiszka
2011-05-05 8:53 ` Avi Kivity
2011-05-05 9:32 ` Jan Kiszka
2011-05-05 10:22 ` Avi Kivity
2011-05-05 10:36 ` Jan Kiszka
2011-05-05 11:57 ` Avi Kivity
2011-05-05 11:22 ` Gleb Natapov
2011-05-05 11:58 ` Avi Kivity
2011-05-05 12:23 ` Gleb Natapov
2011-05-05 12:42 ` Jan Kiszka
2011-05-05 13:33 ` Marcelo Tosatti
2011-05-05 18:08 ` Gleb Natapov [this message]
2011-05-04 19:43 ` [PATCH 05/19] qemu-kvm: Use upstream VCPU reset services Jan Kiszka
2011-05-04 19:43 ` [PATCH 06/19] qemu-kvm: Use upstream vcpu initialization Jan Kiszka
2011-05-04 19:43 ` [PATCH 07/19] qemu-kvm: Start using qemu-thread services Jan Kiszka
2011-05-04 19:43 ` [PATCH 08/19] qemu-kvm: Use upstream kvm_arch_get/put_registers Jan Kiszka
2011-05-04 19:43 ` [PATCH 09/19] qemu-kvm: Use upstream state synchronization services Jan Kiszka
2011-05-04 19:43 ` [PATCH 10/19] qemu-kvm: Drop remaining libkvm fragments Jan Kiszka
2011-05-04 19:43 ` [PATCH 11/19] qemu-kvm: Drop some more unused code Jan Kiszka
2011-05-04 19:43 ` [PATCH 12/19] qemu-kvm: Drop some obsolete/unused fields from kvm_context Jan Kiszka
2011-05-04 19:43 ` [PATCH 13/19] qemu-kvm: Refactor in-kernel irqchip and pit control Jan Kiszka
2011-05-04 19:43 ` [PATCH 14/19] qemu-kvm: Fold kvm_create into kvm_create_context Jan Kiszka
2011-05-04 19:43 ` [PATCH 15/19] qemu-kvm: Fold kvm_arch_qemu_create_context into kvm_arch_create Jan Kiszka
2011-05-04 19:43 ` [PATCH 16/19] qemu-kvm: Push PIT reinjection control into x86 code Jan Kiszka
2011-05-04 19:43 ` [PATCH 17/19] qemu-kvm: Replace kvm_show_regs/code with cpu_dump_state Jan Kiszka
2011-05-04 19:43 ` [PATCH 18/19] qemu-kvm: Fold kvm_init_coalesced_mmio into kvm_create_context Jan Kiszka
2011-05-04 19:43 ` [PATCH 19/19] qemu-kvm: x86: Use kvm_arch_init Jan Kiszka
2011-05-05 8:22 ` [PATCH 00/19] qemu-kvm: Cleanup and switch to upstream - Part I Avi Kivity
2011-05-05 8:29 ` Jan Kiszka
2011-05-06 13:51 ` Marcelo Tosatti
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=20110505180805.GB29181@redhat.com \
--to=gleb@redhat.com \
--cc=avi@redhat.com \
--cc=jan.kiszka@siemens.com \
--cc=kvm@vger.kernel.org \
--cc=mtosatti@redhat.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox