qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Mike Qiu <qiudayu@linux.vnet.ibm.com>
To: Peter Maydell <peter.maydell@linaro.org>
Cc: agraf@suse.de, aik@ozlabs.ru, qemu-devel@nongnu.org,
	xiaoguangrong@linux.vnet.ibm.com, qemu-ppc@nongnu.org,
	"Gerd Hoffmann" <kraxel@redhat.com>,
	"Paolo Bonzini" <pbonzini@redhat.com>,
	"Andreas Färber" <afaerber@suse.de>
Subject: Re: [Qemu-devel] [PATCH] Bug Fix:Segmentation fault when use usb-ehci device
Date: Mon, 22 Jul 2013 10:17:18 +0800	[thread overview]
Message-ID: <51EC962E.5000108@linux.vnet.ibm.com> (raw)
In-Reply-To: <CAFEAcA_z7WdHOSSt=TLUY5Q5ov8GzR2AQhp7Mm5Bu_m9E6L1pw@mail.gmail.com>

于 2013/7/19 22:32, Peter Maydell 写道:
> On 19 July 2013 15:12, Andreas Färber <afaerber@suse.de> wrote:
>> No, I don't. There were other segfault avoidance patches like yours over
>> the past months - they're all fixing individual segfault symptoms.
>> Question for Paolo is whether we want to continue to discover them one
>> by one or whether to implement a fallback inside memory code if .read or
>> .write is NULL.
> I think that the correct behaviour is "if neither
> .read nor .oldmmio.read[x] are set then behave as if
> .valid.accepts returned false" (ie "device has not responded
> to the read access, bus error").
>
> That said, if we want to add do-nothing functions instead,
> then (a) having memory.c provide a single set of nop functions
> that devices can use would be nicer than lots of individual
> nop functions and (b) a list to start with:
Yes, can we add one step in
memory_region_oldmmio_read_accessor() and
memory_region_oldmmio_write_accessor()
to check if the oldmmio read and write has been implement,
if no, for .write function, we just drop and do nothing,
for .read function, we drop read and return the value param
with 0xFF or other to show read fault.

Thus, we do not need to fix the segment fault in special field.

Thanks
Mike
>
> $ for f in $(find . -name '*.c'); do perl -e '$s = 0; while (<>) { if
> (/MemoryRegionOps (.*) =/) { $n = $1; $s = 1; next; } next if $s == 0;
> if (/\.read = /) { $s |= 2; } if (/\.write = /) { $s |= 4; } if (/;/)
> { print "$ARGV: $n: missing read\n" unless $s & 2; print "$ARGV: $n:
> missing write\n" unless $s & 4; $s = 0; }}' $f; done
> ./memory.c: unassigned_mem_ops: missing read
> ./memory.c: unassigned_mem_ops: missing write
> ./exec.c: notdirty_mem_ops: missing read
> ./hw/pci-host/prep.c: PPC_intack_ops: missing write
> ./hw/ssi/xilinx_spips.c: lqspi_ops: missing write
> ./hw/arm/omap1.c: omap_pwt_ops: missing read
> ./hw/arm/musicpal.c: mv88w8618_wlan_ops: missing write
> ./hw/scsi/megasas.c: megasas_queue_ops: missing write
> ./hw/usb/hcd-ehci.c: ehci_mmio_caps_ops: missing write
> ./hw/usb/hcd-uhci.c: uhci_ioport_ops: missing read
> ./hw/intc/openpic_kvm.c: kvm_openpic_mem_ops: missing read
> ./hw/intc/openpic.c: openpic_glb_ops_le: missing read
> ./hw/intc/openpic.c: openpic_glb_ops_be: missing read
> ./hw/intc/openpic.c: openpic_tmr_ops_le: missing read
> ./hw/intc/openpic.c: openpic_tmr_ops_be: missing read
> ./hw/intc/openpic.c: openpic_cpu_ops_le: missing read
> ./hw/intc/openpic.c: openpic_cpu_ops_be: missing read
> ./hw/intc/openpic.c: openpic_src_ops_le: missing read
> ./hw/intc/openpic.c: openpic_src_ops_be: missing read
> ./hw/pci/msix.c: msix_pba_mmio_ops: missing write
> ./hw/xen/xen_platform.c: xen_pci_io_ops: missing read
> ./hw/misc/lm32_sys.c: sys_ops: missing read
> ./hw/misc/pc-testdev.c: test_irq_ops: missing read
> ./hw/misc/pc-testdev.c: test_flush_ops: missing read
> ./hw/misc/vfio.c: vfio_ati_3c3_quirk: missing write
> ./hw/misc/debugexit.c: debug_exit_ops: missing read
> ./hw/net/lan9118.c: *mem_ops: missing read
> ./hw/net/lan9118.c: *mem_ops: missing write
> ./hw/char/grlib_apbuart.c: grlib_apbuart_ops: missing read
> ./hw/char/grlib_apbuart.c: grlib_apbuart_ops: missing write
> ./hw/isa/pc87312.c: pc87312_io_ops: missing read
> ./hw/nvram/fw_cfg.c: fw_cfg_ctl_mem_ops: missing read
>
> No doubt there are some false positives in there (eg fw_cfg.c
> provides a valid function so we'll never try to do reads)
> and it may miss some.
>
> -- PMM
>
>

      reply	other threads:[~2013-07-22  2:18 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-07-16  3:50 [Qemu-devel] [PATCH] Bug Fix:Segmentation fault when use usb-ehci device Mike Qiu
2013-07-18 15:27 ` Mike Qiu
2013-07-18 17:14   ` Andreas Färber
2013-07-19  2:26     ` Mike Qiu
2013-07-19 14:12       ` Andreas Färber
2013-07-19 14:32         ` Peter Maydell
2013-07-22  2:17           ` Mike Qiu [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=51EC962E.5000108@linux.vnet.ibm.com \
    --to=qiudayu@linux.vnet.ibm.com \
    --cc=afaerber@suse.de \
    --cc=agraf@suse.de \
    --cc=aik@ozlabs.ru \
    --cc=kraxel@redhat.com \
    --cc=pbonzini@redhat.com \
    --cc=peter.maydell@linaro.org \
    --cc=qemu-devel@nongnu.org \
    --cc=qemu-ppc@nongnu.org \
    --cc=xiaoguangrong@linux.vnet.ibm.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;
as well as URLs for NNTP newsgroup(s).