Re: [Qemu-devel] [Bug 696485] [NEW] BeOS5 personal edition only displays in Black and White
Le 2 janv. 2011 à 23:28, Andreas Färber a écrit : > Am 02.01.2011 um 19:27 schrieb François Revol: > >>> I can only get the display on BeOS/x86 Personal Edition 5 to be in black >>> and white. I've tried all the -vga options. >>> >>> wget http://www.bebits.com/bob/12373/BeOS4Linux.tar.gz >>> mkdir foo >>> cd foo >>> tar zxvf ../BeOS4Linux.tar.gz >>> qemu -cdrom image.be -fda floppy.img -boot a -vga std >> >> This is because it doesn't have any driver that supports the emulated >> hardware, so it just switches to 16 color VGA and draws from an 8bit >> framebuffer to the VGA bank with a grey palette. >> >> I thought the Cirrus card could be supported but it probably doesn't emulate >> a matching chip. >> >> It might be possible to try extra drivers from http://bebits.com/browse/23 >> though it'd be better to have a working setup from the official image. >> >> Later versions and Haiku use VESA though, so are unaffected and should work >> with -vga std. > > Hmm, I have BeOS 5 PE working with qemu -hda ... (i.e., default VGA options). > And I'm pretty sure I didn't install special drivers. > > /boot/home/config/settings/kernel/drivers/vesa has: > > mode 800 600 16 Oh, then you just have to force it. Indeed, the VESA driver is there, but you must force it by adding the config file. And it doesn't support mode changes. François.
[Qemu-devel] [Bug 696485] Re: BeOS5 personal edition only displays in Black and White
I went to Bebits.com and typed 'cirrus' into the search box, but it didn't match a driver. Please could you let me know where you found it? Thanks. -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/696485 Title: BeOS5 personal edition only displays in Black and White Status in QEMU: Invalid Bug description: I can only get the display on BeOS/x86 Personal Edition 5 to be in black and white. I've tried all the -vga options. wget http://www.bebits.com/bob/12373/BeOS4Linux.tar.gz mkdir foo cd foo tar zxvf ../BeOS4Linux.tar.gz qemu -cdrom image.be -fda floppy.img -boot a -vga std
Re: [Qemu-devel] [Bug 696485] [NEW] BeOS5 personal edition only displays in Black and White
Hi, El 02/01/2011, a las 22:28, Andreas Färber escribió: > Am 02.01.2011 um 19:27 schrieb François Revol: > >>> I can only get the display on BeOS/x86 Personal Edition 5 to be in >>> black >>> and white. I've tried all the -vga options. >>> >>> wget http://www.bebits.com/bob/12373/BeOS4Linux.tar.gz >>> mkdir foo >>> cd foo >>> tar zxvf ../BeOS4Linux.tar.gz >>> qemu -cdrom image.be -fda floppy.img -boot a -vga std >> >> This is because it doesn't have any driver that supports the >> emulated hardware, so it just switches to 16 color VGA and draws >> from an 8bit framebuffer to the VGA bank with a grey palette. >> >> I thought the Cirrus card could be supported but it probably doesn't >> emulate a matching chip. >> >> It might be possible to try extra drivers from http://bebits.com/browse/23 >> though it'd be better to have a working setup from the official image. >> >> Later versions and Haiku use VESA though, so are unaffected and >> should work with -vga std. > > Hmm, I have BeOS 5 PE working with qemu -hda ... (i.e., default VGA > options). > And I'm pretty sure I didn't install special drivers. > > /boot/home/config/settings/kernel/drivers/vesa has: > > mode 800 600 16 Are you sure it's PE and not Dano? > Andreas > > -- > You received this bug notification because you are a member of qemu- > devel-ml, which is subscribed to QEMU. > https://bugs.launchpad.net/bugs/696485 > > Title: > BeOS5 personal edition only displays in Black and White > > Status in QEMU: > Invalid > > Bug description: > I can only get the display on BeOS/x86 Personal Edition 5 to be in black and > white. I've tried all the -vga options. > > wget http://www.bebits.com/bob/12373/BeOS4Linux.tar.gz > mkdir foo > cd foo > tar zxvf ../BeOS4Linux.tar.gz > qemu -cdrom image.be -fda floppy.img -boot a -vga std > > >
Re: [Qemu-devel] [PATCH 1/2] softfloat: abstract out target-specific NaN propagation rules
On Sun, Jan 02, 2011 at 03:35:30PM +, Peter Maydell wrote: > On 2 January 2011 15:05, Aurelien Jarno wrote: > > On Sun, Jan 02, 2011 at 02:04:11PM +, Peter Maydell wrote: > >> Could we have a target-specific "silence this SNaN" function? > > > > You mean a target-specific version of floatXX_maybe_silence_nan()? > > Actually what I had in mind was a target-specific floatXX_silence_snan() > which would be called from the propagateFloatXX_NaN() > and floatXX_maybe_silence_nan() functions. But now you mention > it, just allowing the target to override floatXX_maybe_silence_nan() > (and calling it in propagateFloatXX_NaN()) looks like the better thing. > > > At least having a default version (for !SNAN_BIT_IS_ONE) and a version > > for MIPS, HPPA (which is btw not emulated), etc. > > Yes. (Incidentally, HPPA says the rule for "silence this NaN" is: > * set the first bit of the significand to 0 > * set the second bit of the significand to 1 (implementations can do > this (a) always or (b) only if all the other bits of the significand are 0) > Of course we don't need to actually implement this since > as you say we don't have an HPPA target, but it does suggest > that "silencing rules are target-specific" is the right approach.) > > >> Then the top level functions could use those rather than doing > >> their own bit-flipping, and I think that would do the right thing > >> for MIPS (you'd implement silence-NaN as "return the default > >> QNaN", and you implement pickNaN() to return the SNaN.) > > > > It seems, it would be the good way to do it. I am going to do a quick > > hack to see if this solution can work and if it is the case (it seems > > to be), apply your patch. > > Cool. > I confirm this solution works. I have applied your patches, I'll send a patch series to implement correct propagation on MIPS later this week. -- Aurelien Jarno GPG: 1024D/F1BCDB73 aurel...@aurel32.net http://www.aurel32.net
Re: [Qemu-devel] [Bug 696485] [NEW] BeOS5 personal edition only displays in Black and White
Am 02.01.2011 um 19:27 schrieb François Revol: I can only get the display on BeOS/x86 Personal Edition 5 to be in black and white. I've tried all the -vga options. wget http://www.bebits.com/bob/12373/BeOS4Linux.tar.gz mkdir foo cd foo tar zxvf ../BeOS4Linux.tar.gz qemu -cdrom image.be -fda floppy.img -boot a -vga std This is because it doesn't have any driver that supports the emulated hardware, so it just switches to 16 color VGA and draws from an 8bit framebuffer to the VGA bank with a grey palette. I thought the Cirrus card could be supported but it probably doesn't emulate a matching chip. It might be possible to try extra drivers from http://bebits.com/browse/23 though it'd be better to have a working setup from the official image. Later versions and Haiku use VESA though, so are unaffected and should work with -vga std. Hmm, I have BeOS 5 PE working with qemu -hda ... (i.e., default VGA options). And I'm pretty sure I didn't install special drivers. /boot/home/config/settings/kernel/drivers/vesa has: mode 800 600 16 Andreas
[Qemu-devel] [Bug 696485] Re: BeOS5 personal edition only displays in Black and White
This is not a QEMU bug. You need to get a correct driver for the emulated hardware. There is a Cirrus driver as well as a VESA driver in BeBits that will work with absolutely all emulated hardware. ** Changed in: qemu Status: New => Invalid -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/696485 Title: BeOS5 personal edition only displays in Black and White Status in QEMU: Invalid Bug description: I can only get the display on BeOS/x86 Personal Edition 5 to be in black and white. I've tried all the -vga options. wget http://www.bebits.com/bob/12373/BeOS4Linux.tar.gz mkdir foo cd foo tar zxvf ../BeOS4Linux.tar.gz qemu -cdrom image.be -fda floppy.img -boot a -vga std
[Qemu-devel] [PATCH] m48t59: Fix a wrong opaque passed to nvram read and write routines
This unregresses Sun4m and PPC prep/ref405ep machines
Signed-off-by: Hervé Poussineau
---
hw/m48t59.c | 11 ++-
1 files changed, 6 insertions(+), 5 deletions(-)
diff --git a/hw/m48t59.c b/hw/m48t59.c
index 6991e2e..2020487 100644
--- a/hw/m48t59.c
+++ b/hw/m48t59.c
@@ -642,6 +642,7 @@ M48t59State *m48t59_init(qemu_irq IRQ, target_phys_addr_t
mem_base,
DeviceState *dev;
SysBusDevice *s;
M48t59SysBusState *d;
+M48t59State *state;
dev = qdev_create(NULL, "m48t59");
qdev_prop_set_uint32(dev, "type", type);
@@ -649,18 +650,18 @@ M48t59State *m48t59_init(qemu_irq IRQ, target_phys_addr_t
mem_base,
qdev_prop_set_uint32(dev, "io_base", io_base);
qdev_init_nofail(dev);
s = sysbus_from_qdev(dev);
+d = FROM_SYSBUS(M48t59SysBusState, s);
+state = &d->state;
sysbus_connect_irq(s, 0, IRQ);
if (io_base != 0) {
-register_ioport_read(io_base, 0x04, 1, NVRAM_readb, s);
-register_ioport_write(io_base, 0x04, 1, NVRAM_writeb, s);
+register_ioport_read(io_base, 0x04, 1, NVRAM_readb, state);
+register_ioport_write(io_base, 0x04, 1, NVRAM_writeb, state);
}
if (mem_base != 0) {
sysbus_mmio_map(s, 0, mem_base);
}
-d = FROM_SYSBUS(M48t59SysBusState, s);
-
-return &d->state;
+return state;
}
M48t59State *m48t59_init_isa(uint32_t io_base, uint16_t size, int type)
--
1.7.2.3
Re: [Qemu-devel] [Bug 696485] [NEW] BeOS5 personal edition only displays in Black and White
> I can only get the display on BeOS/x86 Personal Edition 5 to be in black > and white. I've tried all the -vga options. > > wget http://www.bebits.com/bob/12373/BeOS4Linux.tar.gz > mkdir foo > cd foo > tar zxvf ../BeOS4Linux.tar.gz > qemu -cdrom image.be -fda floppy.img -boot a -vga std > > ** Affects: qemu > Importance: Undecided > Status: New > This is because it doesn't have any driver that supports the emulated hardware, so it just switches to 16 color VGA and draws from an 8bit framebuffer to the VGA bank with a grey palette. I thought the Cirrus card could be supported but it probably doesn't emulate a matching chip. It might be possible to try extra drivers from http://bebits.com/browse/23 though it'd be better to have a working setup from the official image. Later versions and Haiku use VESA though, so are unaffected and should work with -vga std. François.
[Qemu-devel] [Bug 696530] [NEW] qemu-0.13.0-r2 special keys different when using -alt-grab
Public bug reported: I use -alt-grab with qemu-0.13.0-r2 and special keys like Ctrl-Alt-f for full screen did not work for me with a windows guest. They work normally when omitting the -alt-grab startup parameter. After quite a long time, I found out that I have to add the shift key to the keys from the documentation when I use the -alt-grab option. Probably -ctrl-grab behaves similarly. It would be really nice to have this documented in the default documentation in the man page as has not been documented there yet. ** Affects: qemu Importance: Undecided Status: New -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/696530 Title: qemu-0.13.0-r2 special keys different when using -alt-grab Status in QEMU: New Bug description: I use -alt-grab with qemu-0.13.0-r2 and special keys like Ctrl-Alt-f for full screen did not work for me with a windows guest. They work normally when omitting the -alt-grab startup parameter. After quite a long time, I found out that I have to add the shift key to the keys from the documentation when I use the -alt-grab option. Probably -ctrl-grab behaves similarly. It would be really nice to have this documented in the default documentation in the man page as has not been documented there yet.
Re: [Qemu-devel] [PATCH 1/2] softfloat: abstract out target-specific NaN propagation rules
On 2 January 2011 15:05, Aurelien Jarno wrote: > On Sun, Jan 02, 2011 at 02:04:11PM +, Peter Maydell wrote: >> Could we have a target-specific "silence this SNaN" function? > > You mean a target-specific version of floatXX_maybe_silence_nan()? Actually what I had in mind was a target-specific floatXX_silence_snan() which would be called from the propagateFloatXX_NaN() and floatXX_maybe_silence_nan() functions. But now you mention it, just allowing the target to override floatXX_maybe_silence_nan() (and calling it in propagateFloatXX_NaN()) looks like the better thing. > At least having a default version (for !SNAN_BIT_IS_ONE) and a version > for MIPS, HPPA (which is btw not emulated), etc. Yes. (Incidentally, HPPA says the rule for "silence this NaN" is: * set the first bit of the significand to 0 * set the second bit of the significand to 1 (implementations can do this (a) always or (b) only if all the other bits of the significand are 0) Of course we don't need to actually implement this since as you say we don't have an HPPA target, but it does suggest that "silencing rules are target-specific" is the right approach.) >> Then the top level functions could use those rather than doing >> their own bit-flipping, and I think that would do the right thing >> for MIPS (you'd implement silence-NaN as "return the default >> QNaN", and you implement pickNaN() to return the SNaN.) > > It seems, it would be the good way to do it. I am going to do a quick > hack to see if this solution can work and if it is the case (it seems > to be), apply your patch. Cool. >> Isn't it clearing the FP exception flags for each instruction when >> they ought to be cumulative? > It only clears the softfloat ones, the real ones are kept in CPU > register fcr31, which is updated by update_fcr31(). This allows to > correctly emulate fcr31, as it contains a part that cumulates IEEE754 > flags and can be reset by software, and a part that cumulates exception > flags, which triggers exceptions if enabled, and which can be reset > independently. Ah yes, I hadn't spotted that we were calling UPDATE_FP_FLAGS rather than SET_FP_FLAGS in update_fcr31(). Sorry for the false alarm. -- PMM
[Qemu-devel] [PATCH 1/2] Add bootindex handling into usb storage device.
Signed-off-by: Gleb Natapov
---
hw/usb-msd.c |2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/hw/usb-msd.c b/hw/usb-msd.c
index 0a95d8d..46642a8 100644
--- a/hw/usb-msd.c
+++ b/hw/usb-msd.c
@@ -560,6 +560,7 @@ static int usb_msd_initfn(USBDevice *dev)
}
}
+add_boot_device_path(s->conf.bootindex, &dev->qdev, "/d...@0,0");
return 0;
}
@@ -624,6 +625,7 @@ static USBDevice *usb_msd_init(const char *filename)
static struct USBDeviceInfo msd_info = {
.product_desc = "QEMU USB MSD",
.qdev.name = "usb-storage",
+.qdev.fw_name = "storage",
.qdev.size = sizeof(MSDState),
.init = usb_msd_initfn,
.handle_packet = usb_generic_handle_packet,
--
1.7.2.3
[Qemu-devel] [PATCH 2/2] Add boot index documentation.
Signed-off-by: Gleb Natapov --- docs/bootindex.txt | 42 ++ 1 files changed, 42 insertions(+), 0 deletions(-) create mode 100644 docs/bootindex.txt diff --git a/docs/bootindex.txt b/docs/bootindex.txt new file mode 100644 index 000..9609c7f --- /dev/null +++ b/docs/bootindex.txt @@ -0,0 +1,42 @@ += Bootindex property = + +Block and net devices have bootindex property. This property is used to +determine the order in which firmware will consider devices for booting +guest OS. If bootindex property is not set for a device it gets lowest +boot priority. There is no particular order in which devices with unset +bootindex property will be considered for booting, but they will still be +bootable. + +== Example == + +Lets assume we have QEMU machine with two NICs (virtio, e1000) and two +disks (IDE, virtio): + +qemu -drive file=disk1.img,if=none,id=disk1 + -device ide-drive,drive=disk1,bootindex=4 + -drive file=disk2.img,if=none,id=disk2 + -device virtio-blk-pci,drive=disk2,bootindex=3 + -netdev type=user,id=net0 -device virtio-net-pci,netdev=net0,bootindex=2 + -netdev type=user,id=net1 -device e1000,netdev=net1,bootindex=1 + +Given command like above firmware should try to boot guest OS from e1000 +NIC if this fails it should try virtio NIC next, if this fails too it +should try virtio disk and then IDE disk. + +== Limitations == + +1. Some firmware has limitation on order in which devices can be +considered for booting. For instance PC bios boot specification allows +only one disk to be bootable. If boot from disk fails for some reason +bios cannot retry booting from other disk. It still can try to boot from +floppy or net though. + +2. Sometimes firmware cannot map device path QEMU wants firmware to boot +from to boot method. It doesn't happen for devices firmware can natively +boot from, but if firmware relies on option rom for booting, and same +option rom is used for booting from more then one device, firmware may +not be able to ask option rom to boot from particular device reliably. +For instance with PC bios if scsi HBA has three bootable devices target1, +target3, target5, connected to it option rom will create boot method for +each of them, but it is not possible to map boot method back to specific +target. This is a shortcoming of PC bios boot specification. -- 1.7.2.3
Re: [Qemu-devel] [PATCH 1/2] Add bootindex handling into usb storage device.
Please ignore. Will resend with Signed-off-by.
On Sun, Jan 02, 2011 at 05:04:31PM +0200, Gleb Natapov wrote:
> ---
> hw/usb-msd.c |2 ++
> 1 files changed, 2 insertions(+), 0 deletions(-)
>
> diff --git a/hw/usb-msd.c b/hw/usb-msd.c
> index 0a95d8d..46642a8 100644
> --- a/hw/usb-msd.c
> +++ b/hw/usb-msd.c
> @@ -560,6 +560,7 @@ static int usb_msd_initfn(USBDevice *dev)
> }
> }
>
> +add_boot_device_path(s->conf.bootindex, &dev->qdev, "/d...@0,0");
> return 0;
> }
>
> @@ -624,6 +625,7 @@ static USBDevice *usb_msd_init(const char *filename)
> static struct USBDeviceInfo msd_info = {
> .product_desc = "QEMU USB MSD",
> .qdev.name = "usb-storage",
> +.qdev.fw_name = "storage",
> .qdev.size = sizeof(MSDState),
> .init = usb_msd_initfn,
> .handle_packet = usb_generic_handle_packet,
> --
> 1.7.2.3
>
--
Gleb.
Re: [Qemu-devel] [PATCH 1/2] softfloat: abstract out target-specific NaN propagation rules
On Sun, Jan 02, 2011 at 02:04:11PM +, Peter Maydell wrote: > On 2 January 2011 13:23, Aurelien Jarno wrote: > > On Thu, Dec 16, 2010 at 11:51:17AM +, Peter Maydell wrote: > >> IEEE754 doesn't specify precisely what NaN should be returned as > >> the result of an operation on two input NaNs. This is therefore > >> target-specific. Abstract out the code in propagateFloat*NaN() > >> which was implementing the x87 propagation rules, so that it > >> can be easily replaced on a per-target basis. > > > I am basically find with the idea. I have tried to implement that for > > MIPS, but it seems your current implementation doesn't allow correct > > propagation for MIPS: if one of the two operand are a sNaN, the result > > should be a *default* qNaN. > > So if the input is a QNaN it's passed through but if it's an SNaN > you get the default QNaN? I guess it makes sense since MIPS Correct. > has SNAN_BIT_IS_ONE and you can't just silence a NaN by > flipping the bit (because you might end up with a non-NaN if > the final significand is all-zeroes). [...and the existing code that > tries to do that is therefore wrong, presumably for both MIPS > and HPPA.] This is also correct. We should probably change it to the default sNaN if the resulting significand is all-zeroes. > Could we have a target-specific "silence this SNaN" function? You mean a target-specific version of floatXX_maybe_silence_nan()? At least having a default version (for !SNAN_BIT_IS_ONE) and a version for MIPS, HPPA (which is btw not emulated), etc. > Then the top level functions could use those rather than doing > their own bit-flipping, and I think that would do the right thing > for MIPS (you'd implement silence-NaN as "return the default > QNaN", and you implement pickNaN() to return the SNaN.) It seems, it would be the good way to do it. I am going to do a quick hack to see if this solution can work and if it is the case (it seems to be), apply your patch. > > It seems that we should pass the operands to the pickNaN() function and > > return the result instead of a flag. That means having one pickNaN > > function per float type, but that can probably be handled by macros or > > by having a common function for targets on which its possible to do so. > > As you might have guessed I was definitely trying to avoid having > to actually pass the operands to pickNaN()... I agree with you that if it can be avoided, it's the best option. > > Note however that the current implementation provides the correct > > result, as the result is converted in op_helper.c: > > > > if (GET_FP_CAUSE(env->active_fpu.fcr31) & FP_INVALID) > > wt2 = FLOAT_QNAN32; > > ...incidentally, I don't know MIPS but this code looks a bit suspect to me: > set_float_exception_flags(0, &env->active_fpu.fp_status);\ > wt2 = float32_ ## name (fst0, fst1, &env->active_fpu.fp_status); \ > update_fcr31();\ > if (GET_FP_CAUSE(env->active_fpu.fcr31) & FP_INVALID)\ > wt2 = FLOAT_QNAN32;\ > > Isn't it clearing the FP exception flags for each instruction when > they ought to be cumulative? > It only clears the softfloat ones, the real ones are kept in CPU register fcr31, which is updated by update_fcr31(). This allows to correctly emulate fcr31, as it contains a part that cumulates IEEE754 flags and can be reset by software, and a part that cumulates exception flags, which triggers exceptions if enabled, and which can be reset independently. -- Aurelien Jarno GPG: 1024D/F1BCDB73 aurel...@aurel32.net http://www.aurel32.net
[Qemu-devel] [PATCH 2/2] Add boot index documentation.
--- docs/bootindex.txt | 42 ++ 1 files changed, 42 insertions(+), 0 deletions(-) create mode 100644 docs/bootindex.txt diff --git a/docs/bootindex.txt b/docs/bootindex.txt new file mode 100644 index 000..9609c7f --- /dev/null +++ b/docs/bootindex.txt @@ -0,0 +1,42 @@ += Bootindex property = + +Block and net devices have bootindex property. This property is used to +determine the order in which firmware will consider devices for booting +guest OS. If bootindex property is not set for a device it gets lowest +boot priority. There is no particular order in which devices with unset +bootindex property will be considered for booting, but they will still be +bootable. + +== Example == + +Lets assume we have QEMU machine with two NICs (virtio, e1000) and two +disks (IDE, virtio): + +qemu -drive file=disk1.img,if=none,id=disk1 + -device ide-drive,drive=disk1,bootindex=4 + -drive file=disk2.img,if=none,id=disk2 + -device virtio-blk-pci,drive=disk2,bootindex=3 + -netdev type=user,id=net0 -device virtio-net-pci,netdev=net0,bootindex=2 + -netdev type=user,id=net1 -device e1000,netdev=net1,bootindex=1 + +Given command like above firmware should try to boot guest OS from e1000 +NIC if this fails it should try virtio NIC next, if this fails too it +should try virtio disk and then IDE disk. + +== Limitations == + +1. Some firmware has limitation on order in which devices can be +considered for booting. For instance PC bios boot specification allows +only one disk to be bootable. If boot from disk fails for some reason +bios cannot retry booting from other disk. It still can try to boot from +floppy or net though. + +2. Sometimes firmware cannot map device path QEMU wants firmware to boot +from to boot method. It doesn't happen for devices firmware can natively +boot from, but if firmware relies on option rom for booting, and same +option rom is used for booting from more then one device, firmware may +not be able to ask option rom to boot from particular device reliably. +For instance with PC bios if scsi HBA has three bootable devices target1, +target3, target5, connected to it option rom will create boot method for +each of them, but it is not possible to map boot method back to specific +target. This is a shortcoming of PC bios boot specification. -- 1.7.2.3
[Qemu-devel] [PATCH 1/2] Add bootindex handling into usb storage device.
---
hw/usb-msd.c |2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/hw/usb-msd.c b/hw/usb-msd.c
index 0a95d8d..46642a8 100644
--- a/hw/usb-msd.c
+++ b/hw/usb-msd.c
@@ -560,6 +560,7 @@ static int usb_msd_initfn(USBDevice *dev)
}
}
+add_boot_device_path(s->conf.bootindex, &dev->qdev, "/d...@0,0");
return 0;
}
@@ -624,6 +625,7 @@ static USBDevice *usb_msd_init(const char *filename)
static struct USBDeviceInfo msd_info = {
.product_desc = "QEMU USB MSD",
.qdev.name = "usb-storage",
+.qdev.fw_name = "storage",
.qdev.size = sizeof(MSDState),
.init = usb_msd_initfn,
.handle_packet = usb_generic_handle_packet,
--
1.7.2.3
[Qemu-devel] [PATCH 1/3] target-ppc: remove PRECISE_EMULATION define
The PRECISE_EMULATION is "hardcoded" to one in target-ppc/exec.h and not
something easily tunable. Remove it and non-precise emulation code as
it doesn't make a noticeable difference in speed. People wanting speed
improvement should use softfloat-native instead.
Cc: Alexander Graf
Signed-off-by: Aurelien Jarno
---
target-ppc/exec.h |3 --
target-ppc/op_helper.c | 58 +--
2 files changed, 11 insertions(+), 50 deletions(-)
diff --git a/target-ppc/exec.h b/target-ppc/exec.h
index 44cc5e9..4688ef5 100644
--- a/target-ppc/exec.h
+++ b/target-ppc/exec.h
@@ -26,9 +26,6 @@
#include "cpu.h"
#include "exec-all.h"
-/* Precise emulation is needed to correctly emulate exception flags */
-#define USE_PRECISE_EMULATION 1
-
register struct CPUPPCState *env asm(AREG0);
#if !defined(CONFIG_USER_ONLY)
diff --git a/target-ppc/op_helper.c b/target-ppc/op_helper.c
index 89be0f4..858877e 100644
--- a/target-ppc/op_helper.c
+++ b/target-ppc/op_helper.c
@@ -974,7 +974,7 @@ uint64_t helper_fadd (uint64_t arg1, uint64_t arg2)
farg1.ll = arg1;
farg2.ll = arg2;
-#if USE_PRECISE_EMULATION
+
if (unlikely(float64_is_signaling_nan(farg1.d) ||
float64_is_signaling_nan(farg2.d))) {
/* sNaN addition */
@@ -986,9 +986,7 @@ uint64_t helper_fadd (uint64_t arg1, uint64_t arg2)
} else {
farg1.d = float64_add(farg1.d, farg2.d, &env->fp_status);
}
-#else
-farg1.d = float64_add(farg1.d, farg2.d, &env->fp_status);
-#endif
+
return farg1.ll;
}
@@ -999,8 +997,7 @@ uint64_t helper_fsub (uint64_t arg1, uint64_t arg2)
farg1.ll = arg1;
farg2.ll = arg2;
-#if USE_PRECISE_EMULATION
-{
+
if (unlikely(float64_is_signaling_nan(farg1.d) ||
float64_is_signaling_nan(farg2.d))) {
/* sNaN subtraction */
@@ -1012,10 +1009,7 @@ uint64_t helper_fsub (uint64_t arg1, uint64_t arg2)
} else {
farg1.d = float64_sub(farg1.d, farg2.d, &env->fp_status);
}
-}
-#else
-farg1.d = float64_sub(farg1.d, farg2.d, &env->fp_status);
-#endif
+
return farg1.ll;
}
@@ -1026,7 +1020,7 @@ uint64_t helper_fmul (uint64_t arg1, uint64_t arg2)
farg1.ll = arg1;
farg2.ll = arg2;
-#if USE_PRECISE_EMULATION
+
if (unlikely(float64_is_signaling_nan(farg1.d) ||
float64_is_signaling_nan(farg2.d))) {
/* sNaN multiplication */
@@ -1038,9 +1032,7 @@ uint64_t helper_fmul (uint64_t arg1, uint64_t arg2)
} else {
farg1.d = float64_mul(farg1.d, farg2.d, &env->fp_status);
}
-#else
-farg1.d = float64_mul(farg1.d, farg2.d, &env->fp_status);
-#endif
+
return farg1.ll;
}
@@ -1051,7 +1043,7 @@ uint64_t helper_fdiv (uint64_t arg1, uint64_t arg2)
farg1.ll = arg1;
farg2.ll = arg2;
-#if USE_PRECISE_EMULATION
+
if (unlikely(float64_is_signaling_nan(farg1.d) ||
float64_is_signaling_nan(farg2.d))) {
/* sNaN division */
@@ -1065,9 +1057,7 @@ uint64_t helper_fdiv (uint64_t arg1, uint64_t arg2)
} else {
farg1.d = float64_div(farg1.d, farg2.d, &env->fp_status);
}
-#else
-farg1.d = float64_div(farg1.d, farg2.d, &env->fp_status);
-#endif
+
return farg1.ll;
}
@@ -1116,12 +1106,10 @@ uint64_t helper_fctiw (uint64_t arg)
farg.ll = fload_invalid_op_excp(POWERPC_EXCP_FP_VXCVI);
} else {
farg.ll = float64_to_int32(farg.d, &env->fp_status);
-#if USE_PRECISE_EMULATION
/* XXX: higher bits are not supposed to be significant.
* to make tests easier, return the same as a real PowerPC 750
*/
farg.ll |= 0xFFF8ULL << 32;
-#endif
}
return farg.ll;
}
@@ -1140,12 +1128,10 @@ uint64_t helper_fctiwz (uint64_t arg)
farg.ll = fload_invalid_op_excp(POWERPC_EXCP_FP_VXCVI);
} else {
farg.ll = float64_to_int32_round_to_zero(farg.d, &env->fp_status);
-#if USE_PRECISE_EMULATION
/* XXX: higher bits are not supposed to be significant.
* to make tests easier, return the same as a real PowerPC 750
*/
farg.ll |= 0xFFF8ULL << 32;
-#endif
}
return farg.ll;
}
@@ -1245,7 +1231,7 @@ uint64_t helper_fmadd (uint64_t arg1, uint64_t arg2,
uint64_t arg3)
farg1.ll = arg1;
farg2.ll = arg2;
farg3.ll = arg3;
-#if USE_PRECISE_EMULATION
+
if (unlikely(float64_is_signaling_nan(farg1.d) ||
float64_is_signaling_nan(farg2.d) ||
float64_is_signaling_nan(farg3.d))) {
@@ -1277,10 +1263,7 @@ uint64_t helper_fmadd (uint64_t arg1, uint64_t arg2,
uint64_t arg3)
farg1.d = (farg1.d * farg2.d) + farg3.d;
#endif
}
-#else
-farg1.d = float64_mul(farg1.d, farg2.d, &env->fp_status);
-farg1.d = float64_add(farg1.d, farg3.d, &env->fp_status);
-#endif
+
return farg1.ll;
}
@@ -1292,7 +1275,7 @@ uint64_t helper_fmsub (uint64_t arg1, uint64_t arg2,
uint64_t arg3)
farg1.ll = arg1;
farg2.ll
[Qemu-devel] [PATCH 3/3] target-ppc: fix sNaN propagation
The current FPU code returns 0.0 if one of the operand is a
signaling NaN and the VXSNAN exception is disabled.
fload_invalid_op_excp() doesn't return a qNaN in case of a VXSNAN
exception as the operand should be propagated instead of a new
qNaN to be generated. Fix that by calling fload_invalid_op_excp()
only for the exception generation (if enabled), and use the softfloat
code to correctly compute the result.
Cc: Alexander Graf
Signed-off-by: Aurelien Jarno
---
target-ppc/op_helper.c | 145 +--
1 files changed, 77 insertions(+), 68 deletions(-)
diff --git a/target-ppc/op_helper.c b/target-ppc/op_helper.c
index 279f345..ea030d0 100644
--- a/target-ppc/op_helper.c
+++ b/target-ppc/op_helper.c
@@ -975,15 +975,16 @@ uint64_t helper_fadd (uint64_t arg1, uint64_t arg2)
farg1.ll = arg1;
farg2.ll = arg2;
-if (unlikely(float64_is_signaling_nan(farg1.d) ||
- float64_is_signaling_nan(farg2.d))) {
-/* sNaN addition */
-farg1.ll = fload_invalid_op_excp(POWERPC_EXCP_FP_VXSNAN);
-} else if (unlikely(float64_is_infinity(farg1.d) &&
float64_is_infinity(farg2.d) &&
- float64_is_neg(farg1.d) != float64_is_neg(farg2.d))) {
+if (unlikely(float64_is_infinity(farg1.d) && float64_is_infinity(farg2.d)
&&
+ float64_is_neg(farg1.d) != float64_is_neg(farg2.d))) {
/* Magnitude subtraction of infinities */
farg1.ll = fload_invalid_op_excp(POWERPC_EXCP_FP_VXISI);
} else {
+if (unlikely(float64_is_signaling_nan(farg1.d) ||
+ float64_is_signaling_nan(farg2.d))) {
+/* sNaN addition */
+fload_invalid_op_excp(POWERPC_EXCP_FP_VXSNAN);
+}
farg1.d = float64_add(farg1.d, farg2.d, &env->fp_status);
}
@@ -998,15 +999,16 @@ uint64_t helper_fsub (uint64_t arg1, uint64_t arg2)
farg1.ll = arg1;
farg2.ll = arg2;
-if (unlikely(float64_is_signaling_nan(farg1.d) ||
- float64_is_signaling_nan(farg2.d))) {
-/* sNaN subtraction */
-farg1.ll = fload_invalid_op_excp(POWERPC_EXCP_FP_VXSNAN);
-} else if (unlikely(float64_is_infinity(farg1.d) &&
float64_is_infinity(farg2.d) &&
- float64_is_neg(farg1.d) == float64_is_neg(farg2.d))) {
+if (unlikely(float64_is_infinity(farg1.d) && float64_is_infinity(farg2.d)
&&
+ float64_is_neg(farg1.d) == float64_is_neg(farg2.d))) {
/* Magnitude subtraction of infinities */
farg1.ll = fload_invalid_op_excp(POWERPC_EXCP_FP_VXISI);
} else {
+if (unlikely(float64_is_signaling_nan(farg1.d) ||
+ float64_is_signaling_nan(farg2.d))) {
+/* sNaN subtraction */
+fload_invalid_op_excp(POWERPC_EXCP_FP_VXSNAN);
+}
farg1.d = float64_sub(farg1.d, farg2.d, &env->fp_status);
}
@@ -1021,16 +1023,17 @@ uint64_t helper_fmul (uint64_t arg1, uint64_t arg2)
farg1.ll = arg1;
farg2.ll = arg2;
-if (unlikely(float64_is_signaling_nan(farg1.d) ||
- float64_is_signaling_nan(farg2.d))) {
-/* sNaN multiplication */
-farg1.ll = fload_invalid_op_excp(POWERPC_EXCP_FP_VXSNAN);
-} else if (unlikely((float64_is_infinity(farg1.d) &&
float64_is_zero(farg2.d)) ||
-(float64_is_zero(farg1.d) &&
float64_is_infinity(farg2.d {
+if (unlikely((float64_is_infinity(farg1.d) && float64_is_zero(farg2.d)) ||
+ (float64_is_zero(farg1.d) && float64_is_infinity(farg2.d {
/* Multiplication of zero by infinity */
farg1.ll = fload_invalid_op_excp(POWERPC_EXCP_FP_VXIMZ);
} else {
-farg1.d = float64_mul(farg1.d, farg2.d, &env->fp_status);
+if (unlikely(float64_is_signaling_nan(farg1.d) ||
+ float64_is_signaling_nan(farg2.d))) {
+/* sNaN multiplication */
+fload_invalid_op_excp(POWERPC_EXCP_FP_VXSNAN);
+}
+float64_mul(farg1.d, farg2.d, &env->fp_status);
}
return farg1.ll;
@@ -1044,17 +1047,18 @@ uint64_t helper_fdiv (uint64_t arg1, uint64_t arg2)
farg1.ll = arg1;
farg2.ll = arg2;
-if (unlikely(float64_is_signaling_nan(farg1.d) ||
- float64_is_signaling_nan(farg2.d))) {
-/* sNaN division */
-farg1.ll = fload_invalid_op_excp(POWERPC_EXCP_FP_VXSNAN);
-} else if (unlikely(float64_is_infinity(farg1.d) &&
float64_is_infinity(farg2.d))) {
+if (unlikely(float64_is_infinity(farg1.d) &&
float64_is_infinity(farg2.d))) {
/* Division of infinity by infinity */
farg1.ll = fload_invalid_op_excp(POWERPC_EXCP_FP_VXIDI);
} else if (unlikely(float64_is_zero(farg1.d) && float64_is_zero(farg2.d)))
{
/* Division of zero by zero */
farg1.ll = fload_invalid_op_excp(POWERPC_EXCP_FP_VXZDZ);
} else {
+if (unlikely(float64_is_signaling_nan(farg1.d) ||
+
[Qemu-devel] [PATCH 2/3] target-ppc: fix default qNaN
On PPC the default qNaN doesn't have the sign bit set.
Cc: Alexander Graf
Signed-off-by: Aurelien Jarno
---
target-ppc/op_helper.c |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/target-ppc/op_helper.c b/target-ppc/op_helper.c
index 858877e..279f345 100644
--- a/target-ppc/op_helper.c
+++ b/target-ppc/op_helper.c
@@ -643,7 +643,7 @@ static inline uint64_t fload_invalid_op_excp(int op)
env->fpscr &= ~((1 << FPSCR_FR) | (1 << FPSCR_FI));
if (ve == 0) {
/* Set the result to quiet NaN */
-ret = 0xFFF8ULL;
+ret = 0x7FF8ULL;
env->fpscr &= ~(0xF << FPSCR_FPCC);
env->fpscr |= 0x11 << FPSCR_FPCC;
}
@@ -654,7 +654,7 @@ static inline uint64_t fload_invalid_op_excp(int op)
env->fpscr &= ~((1 << FPSCR_FR) | (1 << FPSCR_FI));
if (ve == 0) {
/* Set the result to quiet NaN */
-ret = 0xFFF8ULL;
+ret = 0x7FF8ULL;
env->fpscr &= ~(0xF << FPSCR_FPCC);
env->fpscr |= 0x11 << FPSCR_FPCC;
}
--
1.7.2.3
[Qemu-devel] [PATCH 0/3] target-ppc: improve FPU emulation
The PowerPC CPU has a lot more precise FPU exception than the IEEE754 specifications. 7 independant exceptions corresponding to the invalid exception IEEE754. They are currently not implemented in softfloat code, though they are detected to compute the result, that's why the target-ppc code checks for the operands before calling the softfloat code. This patch series fixes some issues with the FPU emulation, though the long term solution is to implement the various flags in the softfloat code, and rely to compute the result. Aurelien Jarno (3): target-ppc: remove PRECISE_EMULATION define target-ppc: fix default qNaN target-ppc: fix sNaN propagation target-ppc/exec.h |3 - target-ppc/op_helper.c | 203 +--- 2 files changed, 88 insertions(+), 118 deletions(-) -- 1.7.2.3
Re: [Qemu-devel] [PATCH 1/2] softfloat: abstract out target-specific NaN propagation rules
On 2 January 2011 13:23, Aurelien Jarno wrote: > On Thu, Dec 16, 2010 at 11:51:17AM +, Peter Maydell wrote: >> IEEE754 doesn't specify precisely what NaN should be returned as >> the result of an operation on two input NaNs. This is therefore >> target-specific. Abstract out the code in propagateFloat*NaN() >> which was implementing the x87 propagation rules, so that it >> can be easily replaced on a per-target basis. > I am basically find with the idea. I have tried to implement that for > MIPS, but it seems your current implementation doesn't allow correct > propagation for MIPS: if one of the two operand are a sNaN, the result > should be a *default* qNaN. So if the input is a QNaN it's passed through but if it's an SNaN you get the default QNaN? I guess it makes sense since MIPS has SNAN_BIT_IS_ONE and you can't just silence a NaN by flipping the bit (because you might end up with a non-NaN if the final significand is all-zeroes). [...and the existing code that tries to do that is therefore wrong, presumably for both MIPS and HPPA.] Could we have a target-specific "silence this SNaN" function? Then the top level functions could use those rather than doing their own bit-flipping, and I think that would do the right thing for MIPS (you'd implement silence-NaN as "return the default QNaN", and you implement pickNaN() to return the SNaN.) > It seems that we should pass the operands to the pickNaN() function and > return the result instead of a flag. That means having one pickNaN > function per float type, but that can probably be handled by macros or > by having a common function for targets on which its possible to do so. As you might have guessed I was definitely trying to avoid having to actually pass the operands to pickNaN()... > Note however that the current implementation provides the correct > result, as the result is converted in op_helper.c: > > if (GET_FP_CAUSE(env->active_fpu.fcr31) & FP_INVALID) > wt2 = FLOAT_QNAN32; ...incidentally, I don't know MIPS but this code looks a bit suspect to me: set_float_exception_flags(0, &env->active_fpu.fp_status);\ wt2 = float32_ ## name (fst0, fst1, &env->active_fpu.fp_status); \ update_fcr31();\ if (GET_FP_CAUSE(env->active_fpu.fcr31) & FP_INVALID)\ wt2 = FLOAT_QNAN32;\ Isn't it clearing the FP exception flags for each instruction when they ought to be cumulative? -- PMM
[Qemu-devel] Re: [GIT PULL] kvm upstream updates
Am 31.12.2010 14:14, Jan Kiszka wrote: > Am 29.12.2010 16:42, Avi Kivity wrote: >> On 12/29/2010 05:05 PM, Jan Kiszka wrote: >>> Am 28.12.2010 11:36, Avi Kivity wrote: Marcelo Tosatti (1): Expose thread_id in info cpus >>> >>> As I'm currently unable to find this particular version of the last >>> patch in the archive: >>> >>>LINK i386-linux-user/qemu-i386 >>> exec.o: In function `cpu_exec_init': >>> /data/qemu-kvm/exec.c:634: undefined reference to `get_thread_id' >>> >> >> I'll take a look. > > OK. And please rebase over current qemu master. I tried to pull in the > series to prepare qemu-kvm for the back merge, but it generated to much > conflicts, pointing out that uq/master is outdated. That was false alarm. Current uq/master actually nicely applies on qemu/master. My problems turned out to be related to subtle differences in the qemu-kvm tree. Jan signature.asc Description: OpenPGP digital signature
[Qemu-devel] [Bug 696485] [NEW] BeOS5 personal edition only displays in Black and White
Public bug reported: I can only get the display on BeOS/x86 Personal Edition 5 to be in black and white. I've tried all the -vga options. wget http://www.bebits.com/bob/12373/BeOS4Linux.tar.gz mkdir foo cd foo tar zxvf ../BeOS4Linux.tar.gz qemu -cdrom image.be -fda floppy.img -boot a -vga std ** Affects: qemu Importance: Undecided Status: New -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/696485 Title: BeOS5 personal edition only displays in Black and White Status in QEMU: New Bug description: I can only get the display on BeOS/x86 Personal Edition 5 to be in black and white. I've tried all the -vga options. wget http://www.bebits.com/bob/12373/BeOS4Linux.tar.gz mkdir foo cd foo tar zxvf ../BeOS4Linux.tar.gz qemu -cdrom image.be -fda floppy.img -boot a -vga std
Re: [Qemu-devel] [PATCH 1/2] softfloat: abstract out target-specific NaN propagation rules
On Thu, Dec 16, 2010 at 11:51:17AM +, Peter Maydell wrote:
> IEEE754 doesn't specify precisely what NaN should be returned as
> the result of an operation on two input NaNs. This is therefore
> target-specific. Abstract out the code in propagateFloat*NaN()
> which was implementing the x87 propagation rules, so that it
> can be easily replaced on a per-target basis.
>
> Signed-off-by: Peter Maydell
> ---
> fpu/softfloat-specialize.h | 160 +++
> 1 files changed, 100 insertions(+), 60 deletions(-)
>
> diff --git a/fpu/softfloat-specialize.h b/fpu/softfloat-specialize.h
> index 8e6aceb..3015480 100644
> --- a/fpu/softfloat-specialize.h
> +++ b/fpu/softfloat-specialize.h
> @@ -134,6 +134,52 @@ static float32 commonNaNToFloat32( commonNaNT a )
> }
>
>
> /*
> +| Select which NaN to propagate for a two-input operation.
> +| IEEE754 doesn't specify all the details of this, so the
> +| algorithm is target-specific.
> +| The routine is passed various bits of information about the
> +| two NaNs and should return 0 to select NaN a and 1 for NaN b.
> +| Note that signalling NaNs are always squashed to quiet NaNs
> +| by the caller, by flipping the SNaN bit before returning them.
> +|
> +| aIsLargerSignificand is only valid if both a and b are NaNs
> +| of some kind, and is true if a has the larger significand,
> +| or if both a and b have the same significand but a is
> +| positive but b is negative. It is only needed for the x87
> +| tie-break rule.
> +**/
> +
> +static int pickNaN(flag aIsQNaN, flag aIsSNaN, flag bIsQNaN, flag bIsSNaN,
> +flag aIsLargerSignificand)
> +{
> +/* This implements x87 NaN propagation rules:
> + * SNaN + QNaN => return the QNaN
> + * two SNaNs => return the one with the larger significand, silenced
> + * two QNaNs => return the one with the larger significand
> + * SNaN and a non-NaN => return the SNaN, silenced
> + * QNaN and a non-NaN => return the QNaN
> + *
> + * If we get down to comparing significands and they are the same,
> + * return the NaN with the positive sign bit (if any).
> + */
> +if (aIsSNaN) {
> +if (bIsSNaN) {
> +return aIsLargerSignificand ? 0 : 1;
> +}
> +return bIsQNaN ? 1 : 0;
> +}
> +else if (aIsQNaN) {
> +if (bIsSNaN || !bIsQNaN)
> +return 0;
> +else {
> +return aIsLargerSignificand ? 0 : 1;
> +}
> +} else {
> +return 1;
> +}
> +}
I am basically find with the idea. I have tried to implement that for
MIPS, but it seems your current implementation doesn't allow correct
propagation for MIPS: if one of the two operand are a sNaN, the result
should be a *default* qNaN.
It seems that we should pass the operands to the pickNaN() function and
return the result instead of a flag. That means having one pickNaN
function per float type, but that can probably be handled by macros or
by having a common function for targets on which its possible to do so.
Note however that the current implementation provides the correct
result, as the result is converted in op_helper.c:
if (GET_FP_CAUSE(env->active_fpu.fcr31) & FP_INVALID)
wt2 = FLOAT_QNAN32;
However if we finally implement correct NaN propagation in the
softfloat routines, it's better to have everything implemented there.
--
Aurelien Jarno GPG: 1024D/F1BCDB73
aurel...@aurel32.net http://www.aurel32.net
[Qemu-devel] [PATCH] target-ppc: use float32_is_any_nan()
Use the new function float32_is_any_nan() instead of
float32_is_quiet_nan() || float32_is_signaling_nan().
Cc: Alexander Graf
Signed-off-by: Aurelien Jarno
---
target-ppc/op_helper.c |5 ++---
1 files changed, 2 insertions(+), 3 deletions(-)
diff --git a/target-ppc/op_helper.c b/target-ppc/op_helper.c
index 5ded1c1..89be0f4 100644
--- a/target-ppc/op_helper.c
+++ b/target-ppc/op_helper.c
@@ -1938,7 +1938,7 @@ target_ulong helper_dlmzb (target_ulong high,
target_ulong low, uint32_t update_
/* If X is a NaN, store the corresponding QNaN into RESULT. Otherwise,
* execute the following block. */
#define DO_HANDLE_NAN(result, x)\
-if (float32_is_quiet_nan(x) || float32_is_signaling_nan(x)) { \
+if (float32_is_any_nan(x)) {\
CPU_FloatU __f; \
__f.f = x; \
__f.l = __f.l | (1 << 22); /* Set QNaN bit. */ \
@@ -2283,8 +2283,7 @@ void helper_vcmpbfp_dot (ppc_avr_t *r, ppc_avr_t *a,
ppc_avr_t *b)
float_status s = env->vec_status; \
set_float_rounding_mode(float_round_to_zero, &s); \
for (i = 0; i < ARRAY_SIZE(r->f); i++) {\
-if (float32_is_quiet_nan(b->f[i]) || \
-float32_is_signaling_nan(b->f[i])) {\
+if (float32_is_any_nan(b->f[i])) { \
r->element[i] = 0; \
} else {\
float64 t = float32_to_float64(b->f[i], &s);\
--
1.7.2.3
Re: [Qemu-devel] [PATCH V2] softfloat: Rename float*_is_nan() functions to float*_is_quiet_nan()
On Sun, Jan 02, 2011 at 11:12:32AM +, Peter Maydell wrote: > On 2 January 2011 10:31, Aurelien Jarno wrote: > > On Sat, Jan 01, 2011 at 11:46:16PM +, Peter Maydell wrote: > >> Can it be applied please? (cc'd Aurelien since you seem to be > >> committing various missed patches at the moment :-)) > > > > Sorry, I understood there was a conflict with another patch series, and > > it was better to wait. Committed now. > > Thanks. > > > As a side note, there are now a few places where the following code is > > present: > > > > float32_is_quiet_nan(x) || float32_is_signaling_nan(x) > > > > It might be a good idea to add back a function float32_is_nan() that > > this time checks for both quiet and signaling NaN. > > This is already present as float32_is_any_nan() (I added it as > part of one of the earlier ARM patchsets). > Ok, then I am going to produce a cleanup patch to use it. -- Aurelien Jarno GPG: 1024D/F1BCDB73 aurel...@aurel32.net http://www.aurel32.net
Re: [Qemu-devel] [PATCH V2] softfloat: Rename float*_is_nan() functions to float*_is_quiet_nan()
On 2 January 2011 10:31, Aurelien Jarno wrote: > On Sat, Jan 01, 2011 at 11:46:16PM +, Peter Maydell wrote: >> Can it be applied please? (cc'd Aurelien since you seem to be >> committing various missed patches at the moment :-)) > > Sorry, I understood there was a conflict with another patch series, and > it was better to wait. Committed now. Thanks. > As a side note, there are now a few places where the following code is > present: > > float32_is_quiet_nan(x) || float32_is_signaling_nan(x) > > It might be a good idea to add back a function float32_is_nan() that > this time checks for both quiet and signaling NaN. This is already present as float32_is_any_nan() (I added it as part of one of the earlier ARM patchsets). -- PMM
Re: [Qemu-devel] [PATCH V2] softfloat: Rename float*_is_nan() functions to float*_is_quiet_nan()
On Sat, Jan 01, 2011 at 11:46:16PM +, Peter Maydell wrote: > On 17 December 2010 15:56, Peter Maydell wrote: > > The softfloat functions float*_is_nan() were badly misnamed, > > because they return true only for quiet NaNs, not for all NaNs. > > Rename them to float*_is_quiet_nan() to more accurately reflect > > what they do. > > > > This change was produced by: > > perl -p -i -e 's/_is_nan/_is_quiet_nan/g' $(git grep -l is_nan) > > (with the results manually checked.) > > > > Signed-off-by: Peter Maydell > > Reviewed-by: Nathan Froyd > > Acked-by: Edgar E. Iglesias > > Ping? This patch got no further comments (although it provoked > a long thread on a completely unrelated topic), it's been > reviewed and it still applies to master currently. I think it's > an uncontroversially good idea (~80% of current uses of the > functions are actually buggy because the people who wrote > them were misled by the function name!). > > Can it be applied please? (cc'd Aurelien since you seem to be > committing various missed patches at the moment :-)) > Sorry, I understood there was a conflict with another patch series, and it was better to wait. Committed now. As a side note, there are now a few places where the following code is present: float32_is_quiet_nan(x) || float32_is_signaling_nan(x) It might be a good idea to add back a function float32_is_nan() that this time checks for both quiet and signaling NaN. -- Aurelien Jarno GPG: 1024D/F1BCDB73 aurel...@aurel32.net http://www.aurel32.net
