From: Paolo Bonzini <pbonzini@redhat.com>
To: nicolas.ochem@free.fr
Cc: kvm@vger.kernel.org
Subject: Re: UIP flag not cleared
Date: Tue, 03 Jul 2012 15:28:08 +0200 [thread overview]
Message-ID: <4FF2F368.2050101@redhat.com> (raw)
In-Reply-To: <1795528294.249975120.1339774728128.JavaMail.root@spooler3-g27.priv.proxad.net>
Il 15/06/2012 17:38, nicolas.ochem@free.fr ha scritto:
> Hi list,
>
>
> I am having troubles porting my os to qemu/kvm environment. It's
> about the RTC (real-time clock)
>
> There is a flag (UIP flag) which is supposed to show when RTC can be
> read or not.
>
> We wait 10ms for that flag to be cleared, but sometimes it's not
> enough with qemu/kvm.
You need to wait more than 10ms then. :( This will be fixed in QEMU
1.2, but you cannot rule out delays due to bad scheduling of the virtual
machine monitor (aka QEMU itself).
> Is it necessary to check this flag at all ? or can I always read the
> RTC regardless of the status of the flag ? If the latter is true, why
> then is this flag not always clear ?
Unlike real hardware, QEMU updates the time atomically; there are no
"invalid states" during the update of the RTC. However, _reads_ of the
RTC are not atomic so you do need UIP. UIP triggers 220 us *before* the
invalid state, so that if UIP=0 you have 220 us to read the RTC. If
your reads take less than 220 us, they are guaranteed to be atomic.
If you need a workaround you can do the following (but it will break on
bare metal):
old_UIP = UIP
read RTC
if old_UIP = 1 and UIP = 0
read RTC again
i.e. accept the old read if both old_UIP and UIP are 1 (and of course if
old_UIP was 0).
Paolo
prev parent reply other threads:[~2012-07-03 13:28 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <2097433711.249908057.1339773258139.JavaMail.root@spooler3-g27.priv.proxad.net>
2012-06-15 15:38 ` UIP flag not cleared nicolas.ochem
2012-07-03 13:28 ` Paolo Bonzini [this message]
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=4FF2F368.2050101@redhat.com \
--to=pbonzini@redhat.com \
--cc=kvm@vger.kernel.org \
--cc=nicolas.ochem@free.fr \
/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.