All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Michael S. Tsirkin" <mst@redhat.com>
To: Peter Crosthwaite <peter.crosthwaite@xilinx.com>
Cc: qemu-trivial@nongnu.org, qemu-devel@nongnu.org,
	"Hervé Poussineau" <hpoussin@reactos.org>,
	"Gerd Hoffmann" <kraxel@redhat.com>,
	"Edgar E. Iglesias" <edgar.iglesias@gmail.com>,
	"Paolo Bonzini" <pbonzini@redhat.com>
Subject: Re: [Qemu-trivial] [PATCH] ioport/memory: check that both .read and .write callbacks are defined
Date: Mon, 10 Jun 2013 20:06:49 +0300	[thread overview]
Message-ID: <20130610170649.GA31588@redhat.com> (raw)
In-Reply-To: <CAEgOgz6PmZ+gvhH9vVFiVqMvNXOBDn3Y+ny=tW+QHEu-eZ-LcQ@mail.gmail.com>

On Mon, Jun 10, 2013 at 07:14:45PM +1000, Peter Crosthwaite wrote:
> Hi,
> 
> On Mon, Jun 10, 2013 at 3:27 PM, Gerd Hoffmann <kraxel@redhat.com> wrote:
> >   Hi,
> >
> >> Maybe instead (or in addition to), we should provide a dummy
> >> read or write functions -- instead of fixing each such occurence
> >> to use its own dummy function
> >
> > Makes sense, especially for write where we can just ignore what the
> > guest attempts to write.  Not sure we can have a generic handler for
> > reads.  Maybe two, one which returns 0xff and one which returns 0x00.
> >
> 
> FWIW, I have one in my tree that qemu_log(LOG_GUEST_ERROR's such
> accesses that I use for unimplemented devices. It's worthwhile to trap
> such accesses and speaking for the Xilinx LQSPI case, my preference is
> for some form of failure rather than silent write-ignore. And can we
> have an option where a invalid writes have consistent behavior with
> unassigned accesses?
> 
> Regards,
> Peter

Probably not a good idea. Ignoring unassigned addresses
is very handy for compatibility: we can run new guests
on old qemu and They don't crash or log errors.

> > cheers,
> >   Gerd
> >
> >


WARNING: multiple messages have this Message-ID (diff)
From: "Michael S. Tsirkin" <mst@redhat.com>
To: Peter Crosthwaite <peter.crosthwaite@xilinx.com>
Cc: qemu-trivial@nongnu.org, "Michael Tokarev" <mjt@tls.msk.ru>,
	qemu-devel@nongnu.org, "Hervé Poussineau" <hpoussin@reactos.org>,
	"Gerd Hoffmann" <kraxel@redhat.com>,
	"Edgar E. Iglesias" <edgar.iglesias@gmail.com>,
	"Paolo Bonzini" <pbonzini@redhat.com>
Subject: Re: [Qemu-devel] [Qemu-trivial] [PATCH] ioport/memory: check that both .read and .write callbacks are defined
Date: Mon, 10 Jun 2013 20:06:49 +0300	[thread overview]
Message-ID: <20130610170649.GA31588@redhat.com> (raw)
In-Reply-To: <CAEgOgz6PmZ+gvhH9vVFiVqMvNXOBDn3Y+ny=tW+QHEu-eZ-LcQ@mail.gmail.com>

On Mon, Jun 10, 2013 at 07:14:45PM +1000, Peter Crosthwaite wrote:
> Hi,
> 
> On Mon, Jun 10, 2013 at 3:27 PM, Gerd Hoffmann <kraxel@redhat.com> wrote:
> >   Hi,
> >
> >> Maybe instead (or in addition to), we should provide a dummy
> >> read or write functions -- instead of fixing each such occurence
> >> to use its own dummy function
> >
> > Makes sense, especially for write where we can just ignore what the
> > guest attempts to write.  Not sure we can have a generic handler for
> > reads.  Maybe two, one which returns 0xff and one which returns 0x00.
> >
> 
> FWIW, I have one in my tree that qemu_log(LOG_GUEST_ERROR's such
> accesses that I use for unimplemented devices. It's worthwhile to trap
> such accesses and speaking for the Xilinx LQSPI case, my preference is
> for some form of failure rather than silent write-ignore. And can we
> have an option where a invalid writes have consistent behavior with
> unassigned accesses?
> 
> Regards,
> Peter

Probably not a good idea. Ignoring unassigned addresses
is very handy for compatibility: we can run new guests
on old qemu and They don't crash or log errors.

> > cheers,
> >   Gerd
> >
> >

  reply	other threads:[~2013-06-10 17:06 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-06-05 13:42 [Qemu-trivial] [PATCH] ioport/memory: check that both .read and .write callbacks are defined Hervé Poussineau
2013-06-05 13:42 ` [Qemu-devel] " Hervé Poussineau
2013-06-08  7:51 ` [Qemu-trivial] " Michael Tokarev
2013-06-08  7:51   ` [Qemu-devel] " Michael Tokarev
2013-06-10  5:27   ` Gerd Hoffmann
2013-06-10  5:27     ` [Qemu-devel] " Gerd Hoffmann
2013-06-10  9:14     ` Peter Crosthwaite
2013-06-10  9:14       ` [Qemu-devel] " Peter Crosthwaite
2013-06-10 17:06       ` Michael S. Tsirkin [this message]
2013-06-10 17:06         ` Michael S. Tsirkin
2013-06-10 22:30         ` [Qemu-trivial] [Qemu-devel] " Peter Crosthwaite
2013-06-10 22:30           ` [Qemu-devel] [Qemu-trivial] " Peter Crosthwaite
2013-06-10 22:53           ` [Qemu-trivial] [Qemu-devel] " Edgar E. Iglesias
2013-06-10 22:53             ` [Qemu-devel] [Qemu-trivial] " Edgar E. Iglesias

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=20130610170649.GA31588@redhat.com \
    --to=mst@redhat.com \
    --cc=edgar.iglesias@gmail.com \
    --cc=hpoussin@reactos.org \
    --cc=kraxel@redhat.com \
    --cc=pbonzini@redhat.com \
    --cc=peter.crosthwaite@xilinx.com \
    --cc=qemu-devel@nongnu.org \
    --cc=qemu-trivial@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 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.