qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: "Glauber Costa" <glommer@gmail.com>
To: qemu-devel@nongnu.org, paul@codesourcery.com
Subject: Re: [Qemu-devel] [4261] Errors while registering ioports are not fatal (Glauber Costa).
Date: Sat, 26 Apr 2008 17:45:05 -0300	[thread overview]
Message-ID: <5d6222a80804261345x3a976797oc3bf6d090dcdff32@mail.gmail.com> (raw)
In-Reply-To: <200804262057.51230.paul@codesourcery.com>

On Sat, Apr 26, 2008 at 4:57 PM, Paul Brook <paul@codesourcery.com> wrote:
> On Saturday 26 April 2008, Anthony Liguori wrote:
>  > Paul Brook wrote:
>  > > On Saturday 26 April 2008, Andrzej Zaborowski wrote:
>  > >> Revision: 4261
>  > >>           http://svn.sv.gnu.org/viewvc/?view=rev&root=qemu&revision=4261
>  > >> Author:   balrog
>  > >> Date:     2008-04-26 16:04:29 +0000 (Sat, 26 Apr 2008)
>  > >>
>  > >> Log Message:
>  > >> -----------
>  > >> Errors while registering ioports are not fatal (Glauber Costa).
>  > >
>  > > Why shouldn't they be fatal? How can this be anything other than a
>  > > serious bug in the device emulation?
>  >
>  > I think the idea is that the device should fail to initialize rather the
>  > VM being destroyed.  Consider the case of PCI hotplug.  It's a
>  > recoverable error if register ioport fails during hot add.
>
>  The errors that get suppressed aren't the sort of thing that should ever
>  happen. How exactly do you end up with an IO port that is not 1, 2 or 4 bytes
>  in size? If this ever happens I want qemu do die right there and then. This
>  isn't just a failure, it is an indication that something is broken beyond
>  hope.
>
>  Paul

Errors in size are not the thing we´re trying to catch here. If
preferred, they can still be fatal, which makes some sense.
Problem is that some devices might use an ioport that is already
registered. In the specific problem I had:

* qemu statically register an ide controller, (can´t recall specific
port numbers now)
* kvm wants to passthrough a device, choosen by the user. It might be
the case that this device is an IDE controller, which will use the
same ports.

Would it be better to test it, and not even register the device in the
first place. Sure. I agree 120 % with this. But how?

You won´t have the conflicting ioport registered until it is too late
in the process, because all ports only get registered in
update_mappings(). But now that I got your attention, if there is a
better proposed solution for this case, I'll be happy to hear and
implement it.

>
>



-- 
Glauber Costa.
"Free as in Freedom"
http://glommer.net

"The less confident you are, the more serious you have to act."

  parent reply	other threads:[~2008-04-26 20:45 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-04-26 16:04 [Qemu-devel] [4261] Errors while registering ioports are not fatal (Glauber Costa) Andrzej Zaborowski
2008-04-26 19:26 ` Paul Brook
2008-04-26 19:36   ` Anthony Liguori
2008-04-26 19:57     ` Paul Brook
2008-04-26 20:33       ` Anthony Liguori
2008-04-26 20:45       ` Glauber Costa [this message]
2008-04-26 19:57   ` andrzej zaborowski
2008-04-26 20:08     ` Paul Brook
2008-04-26 20:38       ` Anthony Liguori
2008-04-26 20:54         ` Paul Brook
2008-04-26 21:09           ` Anthony Liguori
2008-04-26 21:29             ` Paul Brook
2008-04-26 20:39     ` Glauber Costa
2008-04-26 20:43     ` Anthony Liguori
2008-04-26 21:18       ` andrzej zaborowski

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=5d6222a80804261345x3a976797oc3bf6d090dcdff32@mail.gmail.com \
    --to=glommer@gmail.com \
    --cc=paul@codesourcery.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).