* [PATCH 0/1] gst-plugins-good: add libsoup as a dependency
From: Saul Wold @ 2011-04-10 20:55 UTC (permalink / raw)
To: openembedded-core
From: Saul Wold <sgw@linux.intel.com>
When souphttpsrc was added to gst-meta-base, the dependency was
not set up correctly in gst-plugins-good. This patch fixes that
problem.
Sau!
Pull URL: git://git.pokylinux.org/poky-contrib.git
Branch: distro/oe-core
Browse: http://git.pokylinux.org/cgit.cgi/poky-contrib/log/?h=distro/oe-core
Thanks,
Saul Wold <sgw@linux.intel.com>
---
Saul Wold (1):
gst-plugins-good: add dependency on libsoup-2.4
.../gstreamer/gst-plugins-good_0.10.26.bb | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
^ permalink raw reply
* [PATCH 2/2] savagefb: Enable LCD detection on mobile Twister
From: Tormod Volden @ 2011-04-10 20:57 UTC (permalink / raw)
To: linux-fbdev
From: Tormod Volden <debian.tormod@gmail.com>
Copy and paste from the Xorg DDX. Tested on TwisterK (Compaq Presario 700).
Signed-off-by: Tormod Volden <debian.tormod@gmail.com>
---
drivers/video/savage/savagefb_driver.c | 3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/drivers/video/savage/savagefb_driver.c b/drivers/video/savage/savagefb_driver.c
index 0be3f31..0c64d2e 100644
--- a/drivers/video/savage/savagefb_driver.c
+++ b/drivers/video/savage/savagefb_driver.c
@@ -1967,7 +1967,8 @@ static int savage_init_hw(struct savagefb_par *par)
}
}
- if (S3_SAVAGE_MOBILE_SERIES(par->chip) && !par->crtonly)
+ if ((S3_SAVAGE_MOBILE_SERIES(par->chip) ||
+ S3_MOBILE_TWISTER_SERIES(par->chip)) && !par->crtonly)
par->display_type = DISP_LCD;
else if (dvi || (par->chip = S3_SAVAGE4 && par->dvi))
par->display_type = DISP_DFP;
--
1.7.0.4
^ permalink raw reply related
* [PATCH 1/2] savagefb: New S3_TWISTER and S3_PROSAVAGEDDR chip families
From: Tormod Volden @ 2011-04-10 20:57 UTC (permalink / raw)
To: linux-fbdev
From: Tormod Volden <debian.tormod@gmail.com>
Realign the chip families with the Xorg DDX
Signed-off-by: Tormod Volden <debian.tormod@gmail.com>
---
This commit should functionally be a NOP, only prepares for the next patch.
Regards,
Tormod
drivers/video/savage/savagefb-i2c.c | 2 ++
drivers/video/savage/savagefb.h | 8 +++++---
drivers/video/savage/savagefb_driver.c | 12 ++++++++----
3 files changed, 15 insertions(+), 7 deletions(-)
diff --git a/drivers/video/savage/savagefb-i2c.c b/drivers/video/savage/savagefb-i2c.c
index bb71fea..80fa87e 100644
--- a/drivers/video/savage/savagefb-i2c.c
+++ b/drivers/video/savage/savagefb-i2c.c
@@ -171,6 +171,8 @@ void savagefb_create_i2c_busses(struct fb_info *info)
switch (par->chip) {
case S3_PROSAVAGE:
+ case S3_PROSAVAGEDDR:
+ case S3_TWISTER:
par->chan.reg = CR_SERIAL2;
par->chan.ioaddr = par->mmio.vbase;
par->chan.algo.setsda = prosavage_gpio_setsda;
diff --git a/drivers/video/savage/savagefb.h b/drivers/video/savage/savagefb.h
index e4c3f21..6f20ae4 100644
--- a/drivers/video/savage/savagefb.h
+++ b/drivers/video/savage/savagefb.h
@@ -36,7 +36,6 @@
#define PCI_CHIP_SAVAGE_IX 0x8c13
#define PCI_CHIP_PROSAVAGE_PM 0x8a25
#define PCI_CHIP_PROSAVAGE_KM 0x8a26
- /* Twister is a code name; hope I get the real name soon. */
#define PCI_CHIP_S3TWISTER_P 0x8d01
#define PCI_CHIP_S3TWISTER_K 0x8d02
#define PCI_CHIP_PROSAVAGE_DDR 0x8d03
@@ -52,14 +51,15 @@
#define PCI_CHIP_SUPSAV_IXCDDR 0x8c2f
+#define S3_SAVAGE_SERIES(chip) ((chip>=S3_SAVAGE3D) && (chip<=S3_SAVAGE2000))
#define S3_SAVAGE3D_SERIES(chip) ((chip>=S3_SAVAGE3D) && (chip<=S3_SAVAGE_MX))
-#define S3_SAVAGE4_SERIES(chip) ((chip=S3_SAVAGE4) || (chip=S3_PROSAVAGE))
+#define S3_SAVAGE4_SERIES(chip) ((chip>=S3_SAVAGE4) || (chip<=S3_PROSAVAGEDDR))
#define S3_SAVAGE_MOBILE_SERIES(chip) ((chip=S3_SAVAGE_MX) || (chip=S3_SUPERSAVAGE))
-#define S3_SAVAGE_SERIES(chip) ((chip>=S3_SAVAGE3D) && (chip<=S3_SAVAGE2000))
+#define S3_MOBILE_TWISTER_SERIES(chip) ((chip=S3_TWISTER) || (chip=S3_PROSAVAGEDDR))
/* Chip tags. These are used to group the adapters into
* related families.
@@ -71,6 +71,8 @@ typedef enum {
S3_SAVAGE_MX,
S3_SAVAGE4,
S3_PROSAVAGE,
+ S3_TWISTER,
+ S3_PROSAVAGEDDR,
S3_SUPERSAVAGE,
S3_SAVAGE2000,
S3_LAST
diff --git a/drivers/video/savage/savagefb_driver.c b/drivers/video/savage/savagefb_driver.c
index 487911e..0be3f31 100644
--- a/drivers/video/savage/savagefb_driver.c
+++ b/drivers/video/savage/savagefb_driver.c
@@ -328,7 +328,9 @@ SavageSetup2DEngine(struct savagefb_par *par)
savage_out32(0x48C18, savage_in32(0x48C18, par) | 0x0C, par);
break;
case S3_SAVAGE4:
+ case S3_TWISTER:
case S3_PROSAVAGE:
+ case S3_PROSAVAGEDDR:
case S3_SUPERSAVAGE:
/* Disable BCI */
savage_out32(0x48C18, savage_in32(0x48C18, par) & 0x3FF0, par);
@@ -1886,6 +1888,8 @@ static int savage_init_hw(struct savagefb_par *par)
break;
case S3_PROSAVAGE:
+ case S3_PROSAVAGEDDR:
+ case S3_TWISTER:
videoRam = RamSavageNB[(config1 & 0xE0) >> 5] * 1024;
break;
@@ -2111,19 +2115,19 @@ static int __devinit savage_init_fb_info(struct fb_info *info,
snprintf(info->fix.id, 16, "ProSavageKM");
break;
case FB_ACCEL_S3TWISTER_P:
- par->chip = S3_PROSAVAGE;
+ par->chip = S3_TWISTER;
snprintf(info->fix.id, 16, "TwisterP");
break;
case FB_ACCEL_S3TWISTER_K:
- par->chip = S3_PROSAVAGE;
+ par->chip = S3_TWISTER;
snprintf(info->fix.id, 16, "TwisterK");
break;
case FB_ACCEL_PROSAVAGE_DDR:
- par->chip = S3_PROSAVAGE;
+ par->chip = S3_PROSAVAGEDDR;
snprintf(info->fix.id, 16, "ProSavageDDR");
break;
case FB_ACCEL_PROSAVAGE_DDRK:
- par->chip = S3_PROSAVAGE;
+ par->chip = S3_PROSAVAGEDDR;
snprintf(info->fix.id, 16, "ProSavage8");
break;
}
--
1.7.0.4
^ permalink raw reply related
* Re: [PATCH v2 1/2] strbuf: make sure buffer is zero-terminated
From: Jeff King @ 2011-04-10 20:57 UTC (permalink / raw)
To: Erik Faye-Lund; +Cc: git, jwa, drew.northup
In-Reply-To: <1302468858-7376-1-git-send-email-kusmabite@gmail.com>
On Sun, Apr 10, 2011 at 10:54:17PM +0200, Erik Faye-Lund wrote:
> strbuf_init does not zero-terminate the initial buffer when hint is
> non-zero. Fix this so strbuf_attach does not return garbage.
s/attach/detach/ I think. It is more than just detach, though; the
NUL-termination is supposed to be an invariant of strbuf, so any code
just looking at "sb.buf" would be broken. So your code looks fine, but
you may want to mention that in the commit message.
-Peff
^ permalink raw reply
* [PATCH v2 2/2] config: support values longer than 1023 bytes
From: Erik Faye-Lund @ 2011-04-10 20:54 UTC (permalink / raw)
To: git; +Cc: jwa, drew.northup, peff
In-Reply-To: <1302468858-7376-1-git-send-email-kusmabite@gmail.com>
parse_value in config.c has a static buffer of 1024 bytes that it
parse the value into. This can sometimes be a problem when a
config file contains very long values.
It's particularly amusing that git-config already is able to write
such files, so it should probably be able to read them as well.
Fix this by using a strbuf instead of a fixed-size buffer.
Signed-off-by: Erik Faye-Lund <kusmabite@gmail.com>
---
Updated as suggested by Peff.
config.c | 18 ++++++++----------
t/t1303-wacky-config.sh | 2 +-
2 files changed, 9 insertions(+), 11 deletions(-)
diff --git a/config.c b/config.c
index 0abcada..b7fc2c5 100644
--- a/config.c
+++ b/config.c
@@ -133,23 +133,21 @@ static int get_next_char(void)
static char *parse_value(void)
{
- static char value[1024];
- int quote = 0, comment = 0, len = 0, space = 0;
+ static struct strbuf value = STRBUF_INIT;
+ int quote = 0, comment = 0, space = 0;
+ strbuf_reset(&value);
for (;;) {
int c = get_next_char();
- if (len >= sizeof(value) - 1)
- return NULL;
if (c == '\n') {
if (quote)
return NULL;
- value[len] = 0;
- return value;
+ return value.buf;
}
if (comment)
continue;
if (isspace(c) && !quote) {
- if (len)
+ if (value.len)
space++;
continue;
}
@@ -160,7 +158,7 @@ static char *parse_value(void)
}
}
for (; space; space--)
- value[len++] = ' ';
+ strbuf_addch(&value, ' ');
if (c == '\\') {
c = get_next_char();
switch (c) {
@@ -182,14 +180,14 @@ static char *parse_value(void)
default:
return NULL;
}
- value[len++] = c;
+ strbuf_addch(&value, c);
continue;
}
if (c == '"') {
quote = 1-quote;
continue;
}
- value[len++] = c;
+ strbuf_addch(&value, c);
}
}
diff --git a/t/t1303-wacky-config.sh b/t/t1303-wacky-config.sh
index 080117c..46103a1 100755
--- a/t/t1303-wacky-config.sh
+++ b/t/t1303-wacky-config.sh
@@ -44,7 +44,7 @@ LONG_VALUE=$(printf "x%01021dx a" 7)
test_expect_success 'do not crash on special long config line' '
setup &&
git config section.key "$LONG_VALUE" &&
- check section.key "fatal: bad config file line 2 in .git/config"
+ check section.key "$LONG_VALUE"
'
test_done
--
1.7.4.msysgit.0.916.ga2194
^ permalink raw reply related
* [PATCH v2 1/2] strbuf: make sure buffer is zero-terminated
From: Erik Faye-Lund @ 2011-04-10 20:54 UTC (permalink / raw)
To: git; +Cc: jwa, drew.northup, peff
strbuf_init does not zero-terminate the initial buffer when hint is
non-zero. Fix this so strbuf_attach does not return garbage.
Signed-off-by: Erik Faye-Lund <kusmabite@gmail.com>
---
strbuf.c | 4 +++-
1 files changed, 3 insertions(+), 1 deletions(-)
diff --git a/strbuf.c b/strbuf.c
index 77444a9..09c43ae 100644
--- a/strbuf.c
+++ b/strbuf.c
@@ -30,8 +30,10 @@ void strbuf_init(struct strbuf *sb, size_t hint)
{
sb->alloc = sb->len = 0;
sb->buf = strbuf_slopbuf;
- if (hint)
+ if (hint) {
strbuf_grow(sb, hint);
+ sb->buf[0] = '\0';
+ }
}
void strbuf_release(struct strbuf *sb)
--
1.7.4.msysgit.0.916.ga2194
^ permalink raw reply related
* Re: [PATCH] net: sky2: convert to hw_features
From: Stephen Hemminger @ 2011-04-10 20:50 UTC (permalink / raw)
To: Michał Mirosław; +Cc: netdev
In-Reply-To: <20110410131321.8CD9713A64@rere.qmqm.pl>
On Sun, 10 Apr 2011 15:13:21 +0200 (CEST)
Michał Mirosław <mirq-linux@rere.qmqm.pl> wrote:
> @@ -4620,18 +4574,21 @@ static __devinit struct net_device *sky2_init_netdev(struct sky2_hw *hw,
>
> sky2->port = port;
>
> - dev->features |= NETIF_F_IP_CSUM | NETIF_F_SG
> - | NETIF_F_TSO | NETIF_F_GRO;
> + dev->hw_features |= NETIF_F_IP_CSUM | NETIF_F_SG | NETIF_F_TSO;
>
You lost GRO flag in the conversion. Since code calls gro_receive,
this is necessary.
--
^ permalink raw reply
* Required Kernel version to compile git btrfs with DKMS? Problems with Ubuntu 10.10
From: Christian Aßfalg @ 2011-04-10 20:50 UTC (permalink / raw)
To: linux-btrfs
[-- Attachment #1: Type: text/plain, Size: 1820 bytes --]
Hi all,
I'd like to look into btrfs code and try some things, so I followed the
instructions on the wiki (link below) to setup git and get a dkms build
against my kernel. I'm using Ubuntu 10.10 with a 2.6.35 Kernel, which I
assume is too old. What version do I need?
https://btrfs.wiki.kernel.org/index.php/Btrfs_source_repositories
I've followed the guide (skipped initrd) until the dkms build command,
which fails with the following error:
dkms build -m btrfs -v git
root@chris-desktop:/home/chris/workspace/btrfs/git-repo/btrfs-unstable#
cat /var/lib/dkms/btrfs/git/build/make.log
DKMS make.log for btrfs-git for kernel 2.6.35-28-generic (i686)
So 10. Apr 22:05:11 CEST 2011
make: Gehe in Verzeichnis '/usr/src/linux-headers-2.6.35-28-generic'
LD /var/lib/dkms/btrfs/git/build/built-in.o
CC [M] /var/lib/dkms/btrfs/git/build/super.o
In file included from /var/lib/dkms/btrfs/git/build/super.c:43:
/var/lib/dkms/btrfs/git/build/ctree.h:31: fatal error:
trace/events/btrfs.h: Datei oder Verzeichnis nicht gefunden
compilation terminated.
make[1]: *** [/var/lib/dkms/btrfs/git/build/super.o] Fehler 1
make: *** [_module_/var/lib/dkms/btrfs/git/build] Fehler 2
make: Verlasse Verzeichnis '/usr/src/linux-headers-2.6.35-28-generic'
This seems to be fairly new (related to initial tracepoint support),
from the two Mailing list threads "[PATCH] Btrfs: add initial tracepoint
support for btrfs" and "[GIT PULL] Btrfs updates for 2.6.39". The
attached make.log is when I simply copy the missing file over from the
btrfs git tree (fails with among others
"/var/lib/dkms/btrfs/git/build/super.c:578: error: ‘struct super_block’
has no member named ‘s_d_op’"). So I am guessing that my Ubuntu 10.10
2.6.35 Kernel is too old? Will the 2.6.38 from the next Ubuntu release
work?
Regards,
Christian Aßfalg
[-- Attachment #2: make.log --]
[-- Type: text/x-log, Size: 7050 bytes --]
DKMS make.log for btrfs-git for kernel 2.6.35-28-generic (i686)
So 10. Apr 22:15:02 CEST 2011
make: Gehe in Verzeichnis '/usr/src/linux-headers-2.6.35-28-generic'
LD /var/lib/dkms/btrfs/git/build/built-in.o
CC [M] /var/lib/dkms/btrfs/git/build/super.o
In file included from /var/lib/dkms/btrfs/git/build/super.c:43:
/var/lib/dkms/btrfs/git/build/ctree.h:2237: warning: ‘struct fstrim_range’ declared inside parameter list
/var/lib/dkms/btrfs/git/build/ctree.h:2237: warning: its scope is only this definition or declaration, which is probably not what you want
In file included from include/trace/ftrace.h:285,
from include/trace/define_trace.h:73,
from include/trace/events/btrfs.h:667,
from /var/lib/dkms/btrfs/git/build/super.c:56:
include/trace/events/btrfs.h: In function ‘ftrace_raw_output_btrfs_transaction_commit’:
include/trace/events/btrfs.h:47: warning: large integer implicitly truncated to unsigned type
include/trace/events/btrfs.h:47: warning: large integer implicitly truncated to unsigned type
include/trace/events/btrfs.h:47: warning: large integer implicitly truncated to unsigned type
include/trace/events/btrfs.h: In function ‘ftrace_raw_output_btrfs__inode’:
include/trace/events/btrfs.h:68: warning: large integer implicitly truncated to unsigned type
include/trace/events/btrfs.h:68: warning: large integer implicitly truncated to unsigned type
include/trace/events/btrfs.h:68: warning: large integer implicitly truncated to unsigned type
include/trace/events/btrfs.h: In function ‘ftrace_raw_output_btrfs_get_extent’:
include/trace/events/btrfs.h:144: warning: large integer implicitly truncated to unsigned type
include/trace/events/btrfs.h:144: warning: large integer implicitly truncated to unsigned type
include/trace/events/btrfs.h:144: warning: large integer implicitly truncated to unsigned type
include/trace/events/btrfs.h:144: warning: large integer implicitly truncated to unsigned type
include/trace/events/btrfs.h:144: warning: large integer implicitly truncated to unsigned type
include/trace/events/btrfs.h:144: warning: large integer implicitly truncated to unsigned type
include/trace/events/btrfs.h:144: warning: large integer implicitly truncated to unsigned type
include/trace/events/btrfs.h: In function ‘ftrace_raw_output_btrfs__ordered_extent’:
include/trace/events/btrfs.h:197: warning: large integer implicitly truncated to unsigned type
include/trace/events/btrfs.h:197: warning: large integer implicitly truncated to unsigned type
include/trace/events/btrfs.h:197: warning: large integer implicitly truncated to unsigned type
include/trace/events/btrfs.h: In function ‘ftrace_raw_output_btrfs__writepage’:
include/trace/events/btrfs.h:273: warning: large integer implicitly truncated to unsigned type
include/trace/events/btrfs.h:273: warning: large integer implicitly truncated to unsigned type
include/trace/events/btrfs.h:273: warning: large integer implicitly truncated to unsigned type
include/trace/events/btrfs.h: In function ‘ftrace_raw_output_btrfs_writepage_end_io_hook’:
include/trace/events/btrfs.h:332: warning: large integer implicitly truncated to unsigned type
include/trace/events/btrfs.h:332: warning: large integer implicitly truncated to unsigned type
include/trace/events/btrfs.h:332: warning: large integer implicitly truncated to unsigned type
include/trace/events/btrfs.h: In function ‘ftrace_raw_output_btrfs_sync_file’:
include/trace/events/btrfs.h:365: warning: large integer implicitly truncated to unsigned type
include/trace/events/btrfs.h:365: warning: large integer implicitly truncated to unsigned type
include/trace/events/btrfs.h:365: warning: large integer implicitly truncated to unsigned type
include/trace/events/btrfs.h: In function ‘ftrace_raw_output_btrfs_delayed_tree_ref’:
include/trace/events/btrfs.h:420: warning: large integer implicitly truncated to unsigned type
include/trace/events/btrfs.h:420: warning: large integer implicitly truncated to unsigned type
include/trace/events/btrfs.h:420: warning: large integer implicitly truncated to unsigned type
include/trace/events/btrfs.h:420: warning: large integer implicitly truncated to unsigned type
include/trace/events/btrfs.h:420: warning: large integer implicitly truncated to unsigned type
include/trace/events/btrfs.h:420: warning: large integer implicitly truncated to unsigned type
include/trace/events/btrfs.h: In function ‘ftrace_raw_output_btrfs_delayed_data_ref’:
include/trace/events/btrfs.h:459: warning: large integer implicitly truncated to unsigned type
include/trace/events/btrfs.h:459: warning: large integer implicitly truncated to unsigned type
include/trace/events/btrfs.h:459: warning: large integer implicitly truncated to unsigned type
include/trace/events/btrfs.h:459: warning: large integer implicitly truncated to unsigned type
include/trace/events/btrfs.h:459: warning: large integer implicitly truncated to unsigned type
include/trace/events/btrfs.h:459: warning: large integer implicitly truncated to unsigned type
include/trace/events/btrfs.h: In function ‘ftrace_raw_output_btrfs__chunk’:
include/trace/events/btrfs.h:541: warning: large integer implicitly truncated to unsigned type
include/trace/events/btrfs.h:541: warning: large integer implicitly truncated to unsigned type
include/trace/events/btrfs.h:541: warning: large integer implicitly truncated to unsigned type
include/trace/events/btrfs.h: In function ‘ftrace_raw_output_btrfs_cow_block’:
include/trace/events/btrfs.h:591: warning: large integer implicitly truncated to unsigned type
include/trace/events/btrfs.h:591: warning: large integer implicitly truncated to unsigned type
include/trace/events/btrfs.h:591: warning: large integer implicitly truncated to unsigned type
include/trace/events/btrfs.h: In function ‘ftrace_raw_output_btrfs__reserved_extent’:
include/trace/events/btrfs.h:626: warning: large integer implicitly truncated to unsigned type
include/trace/events/btrfs.h:626: warning: large integer implicitly truncated to unsigned type
include/trace/events/btrfs.h:626: warning: large integer implicitly truncated to unsigned type
/var/lib/dkms/btrfs/git/build/super.c: In function ‘btrfs_fill_super’:
/var/lib/dkms/btrfs/git/build/super.c:578: error: ‘struct super_block’ has no member named ‘s_d_op’
/var/lib/dkms/btrfs/git/build/super.c: At top level:
/var/lib/dkms/btrfs/git/build/super.c:1069: error: unknown field ‘mount’ specified in initializer
/var/lib/dkms/btrfs/git/build/super.c:1069: warning: initialization makes integer from pointer without a cast
/var/lib/dkms/btrfs/git/build/super.c:1119: warning: initialization from incompatible pointer type
/var/lib/dkms/btrfs/git/build/super.c:1120: error: unknown field ‘evict_inode’ specified in initializer
make[1]: *** [/var/lib/dkms/btrfs/git/build/super.o] Fehler 1
make: *** [_module_/var/lib/dkms/btrfs/git/build] Fehler 2
make: Verlasse Verzeichnis '/usr/src/linux-headers-2.6.35-28-generic'
^ permalink raw reply
* Re: [PATCH 0/1] meta-fishriver: new BSP
From: Elizabeth Flanagan @ 2011-04-10 20:48 UTC (permalink / raw)
To: poky
In-Reply-To: <4D99FCE4.6000209@intel.com>
I'll get this into the autobuilder config this week.
-b
On 04/04/2011 10:16 AM, Saul Wold wrote:
> On 03/30/2011 05:41 PM, Tom Zanussi wrote:
>> From: Tom Zanussi<tom.zanussi@intel.com>
>>
>> This patchset implements a new BSP for Fish River Island (Z530/EG20T).
>>
>> The basic platorm support works e.g. network, sato desktop,
>> USB keyboard/mouse, but it currently only supports vesa.
>>
>> Better graphics support and support for more of the Fish River Island
>> devices will be added later.
>>
>> Please pull into meta-intel/master.
>>
>> Pull URL: git://git.pokylinux.org/meta-intel.git
>> Branch: tzanussi/meta-fishriver-initial-BSP
>> Browse: http://git.pokylinux.org/cgit/cgit.cgi/meta-intel/log/?h=tzanussi/meta-fishriver-initial-BSP
>>
>> Tom Zanussi (1):
>> meta-fishriver: new layer for Fish River Island (Z530/EG20T) systems
>>
>> meta-fishriver/COPYING.MIT | 17 ++++
>> meta-fishriver/README | 94 ++++++++++++++++++++
>> meta-fishriver/conf/layer.conf | 10 ++
>> meta-fishriver/conf/machine/fishriver.conf | 46 ++++++++++
>> .../formfactor/formfactor/fishriver/machconfig | 3 +
>> .../recipes-bsp/formfactor/formfactor_0.0.bbappend | 3 +
>> .../xserver-xf86-config/fishriver/xorg.conf | 26 ++++++
>> .../xorg-xserver/xserver-xf86-config_0.1.bbappend | 3 +
>> .../recipes-kernel/linux/linux-yocto_git.bbappend | 4 +
>> 9 files changed, 206 insertions(+), 0 deletions(-)
>> create mode 100644 meta-fishriver/COPYING.MIT
>> create mode 100644 meta-fishriver/README
>> create mode 100644 meta-fishriver/binary/.gitignore
>> create mode 100644 meta-fishriver/conf/layer.conf
>> create mode 100644 meta-fishriver/conf/machine/fishriver.conf
>> create mode 100644 meta-fishriver/recipes-bsp/formfactor/formfactor/fishriver/machconfig
>> create mode 100644 meta-fishriver/recipes-bsp/formfactor/formfactor_0.0.bbappend
>> create mode 100644 meta-fishriver/recipes-graphics/xorg-xserver/xserver-xf86-config/fishriver/xorg.conf
>> create mode 100644 meta-fishriver/recipes-graphics/xorg-xserver/xserver-xf86-config_0.1.bbappend
>> create mode 100644 meta-fishriver/recipes-kernel/linux/linux-yocto_git.bbappend
>>
>> _______________________________________________
>> poky mailing list
>> poky@yoctoproject.org
>> https://lists.yoctoproject.org/listinfo/poky
>>
> Pushed into meta-intel master
>
> Thanks
> Sau!
>
> _______________________________________________
> poky mailing list
> poky@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/poky
--
------------------
Elizabeth Flanagan
Yocto Project
Release Engineer
^ permalink raw reply
* [PATCH] KVM test: iofuzz: Fix exception formatting bug
From: Lucas Meneghel Rodrigues @ 2011-04-10 20:44 UTC (permalink / raw)
To: autotest; +Cc: kvm, Lucas Meneghel Rodrigues
Show both operation and operand when VM quits abnormally.
Signed-off-by: Lucas Meneghel Rodrigues <lmr@redhat.com>
---
client/tests/kvm/tests/iofuzz.py | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/client/tests/kvm/tests/iofuzz.py b/client/tests/kvm/tests/iofuzz.py
index 7189f91..ea25ba2 100644
--- a/client/tests/kvm/tests/iofuzz.py
+++ b/client/tests/kvm/tests/iofuzz.py
@@ -84,8 +84,8 @@ def run_iofuzz(test, params, env):
logging.debug("Could not re-login, reboot the guest")
session = vm.reboot(method="system_reset")
else:
- raise error.TestFail("VM has quit abnormally during %s",
- (op, operand))
+ raise error.TestFail("VM has quit abnormally during "
+ "%s: %s" % (op, operand))
login_timeout = float(params.get("login_timeout", 240))
--
1.7.4.2
^ permalink raw reply related
* Re: [Qemu-devel] [PATCH 08/15] s390x: virtio machine storage keys
From: Aurelien Jarno @ 2011-04-10 20:41 UTC (permalink / raw)
To: Alexander Graf; +Cc: peter.maydell, QEMU-devel Developers, Richard Henderson
In-Reply-To: <1301927544-32767-9-git-send-email-agraf@suse.de>
On Mon, Apr 04, 2011 at 04:32:17PM +0200, Alexander Graf wrote:
> For emulation (and migration) we need to know about the guest's storage keys.
> These are separate from actual RAM contents, so we need to allocate them in
> parallel to RAM.
>
> While touching the file, this patch also adjusts the hypercall function
> to a new syntax that aligns better with tcg emulated code.
>
> Signed-off-by: Alexander Graf <agraf@suse.de>
> ---
> hw/s390-virtio.c | 21 +++++++++------------
> 1 files changed, 9 insertions(+), 12 deletions(-)
>
> diff --git a/hw/s390-virtio.c b/hw/s390-virtio.c
> index 850422f..be2c80c 100644
> --- a/hw/s390-virtio.c
> +++ b/hw/s390-virtio.c
> @@ -82,13 +82,12 @@ CPUState *s390_cpu_addr2state(uint16_t cpu_addr)
> return ipi_states[cpu_addr];
> }
>
> -int s390_virtio_hypercall(CPUState *env)
> +int s390_virtio_hypercall(CPUState *env, uint64_t mem, uint64_t hypercall)
> {
> int r = 0, i;
> - target_ulong mem = env->regs[2];
>
> - dprintf("KVM hypercall: %ld\n", env->regs[1]);
> - switch (env->regs[1]) {
> + dprintf("KVM hypercall: %ld\n", hypercall);
> + switch (hypercall) {
> case KVM_S390_VIRTIO_NOTIFY:
> if (mem > ram_size) {
> VirtIOS390Device *dev = s390_virtio_bus_find_vring(s390_bus,
> @@ -128,8 +127,7 @@ int s390_virtio_hypercall(CPUState *env)
> break;
> }
>
> - env->regs[2] = r;
> - return 0;
> + return r;
> }
>
> /* PC hardware initialisation */
> @@ -145,14 +143,9 @@ static void s390_init(ram_addr_t ram_size,
> ram_addr_t kernel_size = 0;
> ram_addr_t initrd_offset;
> ram_addr_t initrd_size = 0;
> + uint8_t *storage_keys;
> int i;
>
> - /* XXX we only work on KVM for now */
> -
> - if (!kvm_enabled()) {
> - fprintf(stderr, "The S390 target only works with KVM enabled\n");
> - exit(1);
> - }
>
> /* get a BUS */
> s390_bus = s390_virtio_bus_init(&ram_size);
> @@ -161,6 +154,9 @@ static void s390_init(ram_addr_t ram_size,
> ram_addr = qemu_ram_alloc(NULL, "s390.ram", ram_size);
> cpu_register_physical_memory(0, ram_size, ram_addr);
>
> + /* allocate storage keys */
> + storage_keys = qemu_mallocz(ram_size / TARGET_PAGE_SIZE);
> +
> /* init CPUs */
> if (cpu_model == NULL) {
> cpu_model = "host";
> @@ -178,6 +174,7 @@ static void s390_init(ram_addr_t ram_size,
> ipi_states[i] = tmp_env;
> tmp_env->halted = 1;
> tmp_env->exception_index = EXCP_HLT;
> + tmp_env->storage_keys = storage_keys;
> }
>
> env->halted = 0;
Reviewed-by: Aurelien Jarno <aurelien@aurel32.net>
--
Aurelien Jarno GPG: 1024D/F1BCDB73
aurelien@aurel32.net http://www.aurel32.net
^ permalink raw reply
* Re: [Qemu-devel] [PATCH 07/15] s390x: Adjust GDB stub
From: Aurelien Jarno @ 2011-04-10 20:39 UTC (permalink / raw)
To: Alexander Graf; +Cc: peter.maydell, QEMU-devel Developers, Richard Henderson
In-Reply-To: <1301927544-32767-8-git-send-email-agraf@suse.de>
On Mon, Apr 04, 2011 at 04:32:16PM +0200, Alexander Graf wrote:
> We have successfully lazilized cc computation, so we need to manually
> trigger its calculation when gdb wants to fetch it. We also changed the
> variable name, so writing it writes into a different field now.
>
> Signed-off-by: Alexander Graf <agraf@suse.de>
> ---
> gdbstub.c | 8 ++++++--
> 1 files changed, 6 insertions(+), 2 deletions(-)
>
> diff --git a/gdbstub.c b/gdbstub.c
> index 0838948..ae856f9 100644
> --- a/gdbstub.c
> +++ b/gdbstub.c
> @@ -1436,7 +1436,11 @@ static int cpu_gdb_read_register(CPUState *env, uint8_t *mem_buf, int n)
> /* XXX */
> break;
> case S390_PC_REGNUM: GET_REGL(env->psw.addr); break;
> - case S390_CC_REGNUM: GET_REG32(env->cc); break;
> + case S390_CC_REGNUM:
> + env->cc_op = calc_cc(env, env->cc_op, env->cc_src, env->cc_dst,
> + env->cc_vr);
> + GET_REG32(env->cc_op);
> + break;
> }
>
> return 0;
> @@ -1462,7 +1466,7 @@ static int cpu_gdb_write_register(CPUState *env, uint8_t *mem_buf, int n)
> /* XXX */
> break;
> case S390_PC_REGNUM: env->psw.addr = tmpl; break;
> - case S390_CC_REGNUM: env->cc = tmp32; r=4; break;
> + case S390_CC_REGNUM: env->cc_op = tmp32; r=4; break;
> }
>
> return r;
The patch looks fine, but it should appear later in the patch series.
--
Aurelien Jarno GPG: 1024D/F1BCDB73
aurelien@aurel32.net http://www.aurel32.net
^ permalink raw reply
* Re: [Qemu-devel] [PATCH 06/15] s390x: Dispatch interrupts to KVM or the real CPU
From: Aurelien Jarno @ 2011-04-10 20:37 UTC (permalink / raw)
To: Alexander Graf; +Cc: peter.maydell, QEMU-devel Developers, Richard Henderson
In-Reply-To: <1301927544-32767-7-git-send-email-agraf@suse.de>
On Mon, Apr 04, 2011 at 04:32:15PM +0200, Alexander Graf wrote:
> The KVM interrupt injection path is non-generic for now. So we need to push
> knowledge of how to inject a device interrupt using KVM into the actual device
> code.
>
> Signed-off-by: Alexander Graf <agraf@suse.de>
> ---
> hw/s390-virtio-bus.c | 10 ++++++++--
> 1 files changed, 8 insertions(+), 2 deletions(-)
>
> diff --git a/hw/s390-virtio-bus.c b/hw/s390-virtio-bus.c
> index 60e0135..35acf53 100644
> --- a/hw/s390-virtio-bus.c
> +++ b/hw/s390-virtio-bus.c
> @@ -43,6 +43,8 @@
> do { } while (0)
> #endif
>
> +#define VIRTIO_EXT_CODE 0x2603
> +
> struct BusInfo s390_virtio_bus_info = {
> .name = "s390-virtio",
> .size = sizeof(VirtIOS390Bus),
> @@ -304,9 +306,13 @@ static void virtio_s390_notify(void *opaque, uint16_t vector)
> {
> VirtIOS390Device *dev = (VirtIOS390Device*)opaque;
> uint64_t token = s390_virtio_device_vq_token(dev, vector);
> + CPUState *env = s390_cpu_addr2state(0);
>
> - /* XXX kvm dependency! */
> - kvm_s390_virtio_irq(s390_cpu_addr2state(0), 0, token);
> + if (kvm_enabled()) {
> + kvm_s390_virtio_irq(env, 0, token);
> + } else {
> + cpu_inject_ext(env, VIRTIO_EXT_CODE, 0, token);
cpu_inject_ext() is defined in a later patch so the patch series should
probably be reordered to not break bisecting (for the KVM version only
in that case).
> + }
> }
>
> static unsigned virtio_s390_get_features(void *opaque)
> --
> 1.6.0.2
>
>
>
--
Aurelien Jarno GPG: 1024D/F1BCDB73
aurelien@aurel32.net http://www.aurel32.net
^ permalink raw reply
* Re: [Qemu-devel] [PATCH 05/15] s390x: Enable s390x-softmmu target
From: Aurelien Jarno @ 2011-04-10 20:34 UTC (permalink / raw)
To: Alexander Graf; +Cc: peter.maydell, QEMU-devel Developers, Richard Henderson
In-Reply-To: <1301927544-32767-6-git-send-email-agraf@suse.de>
On Mon, Apr 04, 2011 at 04:32:14PM +0200, Alexander Graf wrote:
> This patch adds some code paths for running s390x guest OSs without the
> need for KVM.
>
> Signed-off-by: Alexander Graf <agraf@suse.de>
> ---
> cpu-exec.c | 8 ++++++++
> target-s390x/exec.h | 20 ++++++++++++++++++++
> 2 files changed, 28 insertions(+), 0 deletions(-)
>
> diff --git a/cpu-exec.c b/cpu-exec.c
> index 5cc9379..ebc8cba 100644
> --- a/cpu-exec.c
> +++ b/cpu-exec.c
> @@ -343,6 +343,8 @@ int cpu_exec(CPUState *env1)
> do_interrupt(env);
> #elif defined(TARGET_M68K)
> do_interrupt(0);
> +#elif defined(TARGET_S390X)
> + do_interrupt(env);
> #endif
> env->exception_index = -1;
> #endif
> @@ -551,6 +553,12 @@ int cpu_exec(CPUState *env1)
> do_interrupt(1);
> next_tb = 0;
> }
> +#elif defined(TARGET_S390X) && !defined(CONFIG_USER_ONLY)
> + if ((interrupt_request & CPU_INTERRUPT_HARD) &&
> + (env->psw.mask & PSW_MASK_EXT)) {
> + do_interrupt(env);
> + next_tb = 0;
> + }
> #endif
This should be somehow consistent with cpu_has_work() (from exec.h)
which currently has "// guess". The current versions of cpu_has_work()
ignore env->psw.mask so wake-up the CPU even if the external interrupt
are masked. Does it matches the real hardware?
> /* Don't use the cached interupt_request value,
> do_interrupt may have updated the EXITTB flag. */
> diff --git a/target-s390x/exec.h b/target-s390x/exec.h
> index f7893f3..6fe64a6 100644
> --- a/target-s390x/exec.h
> +++ b/target-s390x/exec.h
> @@ -34,6 +34,26 @@ static inline int cpu_has_work(CPUState *env)
> return env->interrupt_request & CPU_INTERRUPT_HARD; // guess
> }
>
> +static inline void regs_to_env(void)
> +{
> +}
> +
> +static inline void env_to_regs(void)
> +{
> +}
> +
> +static inline int cpu_halted(CPUState *env)
> +{
> + if (!env->halted) {
> + return 0;
> + }
> + if (cpu_has_work(env)) {
> + env->halted = 0;
> + return 0;
> + }
> + return EXCP_HALTED;
> +}
> +
This has been removed in eda48c344f35e5bd511dea3e8be56fb08c19b399 .
There is no need to reintroduce it.
> static inline void cpu_pc_from_tb(CPUState *env, TranslationBlock* tb)
> {
> env->psw.addr = tb->pc;
> --
> 1.6.0.2
>
>
>
--
Aurelien Jarno GPG: 1024D/F1BCDB73
aurelien@aurel32.net http://www.aurel32.net
^ permalink raw reply
* Re: [PATCH] Remove non-MAINTAINERS email address references for Lennert Buytenhek.
From: David Miller @ 2011-04-10 20:28 UTC (permalink / raw)
To: buytenh; +Cc: akpm, linux-kernel
In-Reply-To: <20110410202716.GK22881@wantstofly.org>
From: Lennert Buytenhek <buytenh@wantstofly.org>
Date: Sun, 10 Apr 2011 22:27:16 +0200
> The problem is that half of them are out of date. I at first sent a
> patch to change them all over to buytenh@wantstofly.org, but then got:
>
> http://marc.info/?l=linux-kernel&m=129858453409012&w=2
>
> which seemed sensible. :-/
It's not just about maintainership, it's about copyright too.
For example, whether someone does or does not use their employer's
email address in the copyright can have an impact on whether their
employer can make a claim on copyright of the work. There
are therefore real implications for what email address is there.
Like Andrew said, if people want to reach the active maintainer
they can use MAINTAINERS or look into the recent GIT logs for
the associated files.
Changing copyright email addresses can get into unrelated areas.
^ permalink raw reply
* Re: [Qemu-devel] [PATCH 15/15] tcg: use ext op for deposit
From: Aurelien Jarno @ 2011-04-10 20:28 UTC (permalink / raw)
To: Alexander Graf; +Cc: peter.maydell, QEMU-devel Developers, Richard Henderson
In-Reply-To: <AC5D31F8-FF49-40FC-ACB2-E3E835DDF9F1@suse.de>
On Sun, Apr 10, 2011 at 10:17:26PM +0200, Alexander Graf wrote:
>
> On 10.04.2011, at 22:08, Aurelien Jarno wrote:
>
> > On Sun, Apr 10, 2011 at 09:25:33PM +0200, Alexander Graf wrote:
> >>
> >> On 10.04.2011, at 21:23, Aurelien Jarno wrote:
> >>
> >>> On Tue, Apr 05, 2011 at 09:55:09AM +0200, Alexander Graf wrote:
> >>>>
> >>>> On 05.04.2011, at 06:54, Aurelien Jarno wrote:
> >>>>
> >>>>> On Mon, Apr 04, 2011 at 04:32:24PM +0200, Alexander Graf wrote:
> >>>>>> With the s390x target we use the deposit instruction to store 32bit values
> >>>>>> into 64bit registers without clobbering the upper 32 bits.
> >>>>>>
> >>>>>> This specific operation can be optimized slightly by using the ext operation
> >>>>>> instead of an explicit and in the deposit instruction. This patch adds that
> >>>>>> special case to the generic deposit implementation.
> >>>>>>
> >>>>>> Signed-off-by: Alexander Graf <agraf@suse.de>
> >>>>>> ---
> >>>>>> tcg/tcg-op.h | 6 +++++-
> >>>>>> 1 files changed, 5 insertions(+), 1 deletions(-)
> >>>>>
> >>>>> Have you really measuring a difference here? This should already be
> >>>>> handled, at least on x86, by this code:
> >>>>>
> >>>>> if (TCG_TARGET_REG_BITS == 64) {
> >>>>> if (val == 0xffffffffu) {
> >>>>> tcg_out_ext32u(s, r0, r0);
> >>>>> return;
> >>>>> }
> >>>>> if (val == (uint32_t)val) {
> >>>>> /* AND with no high bits set can use a 32-bit operation. */
> >>>>> rexw = 0;
> >>>>> }
> >>>>> }
> >>>>
> >>>> I've certainly looked at the -d op logs and seen that instead of creating a const tcg variable plus an AND there was now an extu opcode issued, yes. No idea why the case up there didn't trigger.
> >>>>
> >>>
> >>> The question there is looking at -d out_asm. They should be the same at
> >>> the end as the code I pasted above is from tcg/i386/tcg-target.c.
> >>
> >> Yes. I was trying to optimize for maximum op length. TCG defines a maximum number of tcg ops to be issued by each target instruction. Since s390 is very CISCy, there are instructions that translate into lots of microops, but are still faster than a C call (register save/restore mostly).
> >>
> >> Without this patch, there are some places where we hit that number :).
> >
> > Is it on 32-bit on or 64-bit? If we reach this number, it's probably
> > better to either implement this instruction with an helper, or maybe
> > increase the number of maximum ops. What is this instruction?
>
> This was on x86_64. I hit limits with LMH and LM, but reduced them to fit into the picture with this optimization :). If you like, I can give you a statically linked binary that could exceed the limits.
>
Yeah for what I see it's the loop is unrolled there. Not sure it is the
best to do. Also if the limit is exceeded on 64-bit it is for sure
exceeded on 32-bit hosts.
--
Aurelien Jarno GPG: 1024D/F1BCDB73
aurelien@aurel32.net http://www.aurel32.net
^ permalink raw reply
* Re: [Qemu-devel] [PATCH 01/15] s390x: fix virtio feature bitmap
From: Aurelien Jarno @ 2011-04-10 20:26 UTC (permalink / raw)
To: Alexander Graf; +Cc: peter.maydell, QEMU-devel Developers, Richard Henderson
In-Reply-To: <A6348A14-1D5D-44D5-94E0-25694A162C79@suse.de>
On Sun, Apr 10, 2011 at 10:11:15PM +0200, Alexander Graf wrote:
>
> On 10.04.2011, at 22:06, Aurelien Jarno wrote:
>
> > On Sun, Apr 10, 2011 at 09:26:26PM +0200, Alexander Graf wrote:
> >>
> >> On 10.04.2011, at 21:25, Aurelien Jarno wrote:
> >>
> >>> On Mon, Apr 04, 2011 at 04:32:10PM +0200, Alexander Graf wrote:
> >>>> The feature bitmap in the s390 virtio machine is little endian. To
> >>>> address for that, we need to bswap the values after reading them out.
> >>>>
> >>>> Signed-off-by: Alexander Graf <agraf@suse.de>
> >>>> ---
> >>>> hw/s390-virtio-bus.c | 4 ++--
> >>>> 1 files changed, 2 insertions(+), 2 deletions(-)
> >>>>
> >>>> diff --git a/hw/s390-virtio-bus.c b/hw/s390-virtio-bus.c
> >>>> index 58af164..60e0135 100644
> >>>> --- a/hw/s390-virtio-bus.c
> >>>> +++ b/hw/s390-virtio-bus.c
> >>>> @@ -223,7 +223,7 @@ void s390_virtio_device_sync(VirtIOS390Device *dev)
> >>>> cur_offs += num_vq * VIRTIO_VQCONFIG_LEN;
> >>>>
> >>>> /* Sync feature bitmap */
> >>>> - stl_phys(cur_offs, dev->host_features);
> >>>> + stl_phys(cur_offs, bswap32(dev->host_features));
> >>>
> >>> Is bswap32 correct here for both big and little endian guests? I don't
> >>> really understand the reason why a bswap is needed here, especially
> >>> given that AFAIK this code was already used when using KVM.
> >>
> >> This is target specific code. The s390-virtio-bus is s390 specific. And yes, the code was also broken with KVM. That's how I first found it actually.
> >>
> >
> > So in short, s390-virtio-bus is specific to big endian machines, but is
> > using little endian? That looks a bit weired. I guess it's probably to
> > late to change the specification anyway...
>
> Yeah. In fact, it mixes big and little endian pieces. But it really is too late to change the (unwritten) spec, unfortunately.
>
Ok, thanks for the explanations, I have applied it.
--
Aurelien Jarno GPG: 1024D/F1BCDB73
aurelien@aurel32.net http://www.aurel32.net
^ permalink raw reply
* Re: [Qemu-devel] [PATCH 04/15] linux-user: define a couple of syscalls for non-uid16 targets
From: Aurelien Jarno @ 2011-04-10 20:25 UTC (permalink / raw)
To: Alexander Graf
Cc: peter.maydell, Riku Voipio, QEMU-devel Developers,
Richard Henderson
In-Reply-To: <1301927544-32767-5-git-send-email-agraf@suse.de>
On Mon, Apr 04, 2011 at 04:32:13PM +0200, Alexander Graf wrote:
> From: Ulrich Hecht <uli@suse.de>
>
> Quite a number of syscalls are only defined on systems with USE_UID16
> defined; this patch defines them on other systems as well.
>
> Fixes a large number of uid/gid-related testcases on the s390x target
> (and most likely on other targets as well)
>
> Signed-off-by: Ulrich Hecht <uli@suse.de>
> ---
> linux-user/syscall.c | 125 ++++++++++++++++++++++++++++++++++++++++++--------
> 1 files changed, 105 insertions(+), 20 deletions(-)
>
> diff --git a/linux-user/syscall.c b/linux-user/syscall.c
> index fabe815..0bce466 100644
> --- a/linux-user/syscall.c
> +++ b/linux-user/syscall.c
> @@ -326,7 +326,7 @@ static int sys_fchmodat(int dirfd, const char *pathname, mode_t mode)
> return (fchmodat(dirfd, pathname, mode, 0));
> }
> #endif
> -#if defined(TARGET_NR_fchownat) && defined(USE_UID16)
> +#if defined(TARGET_NR_fchownat)
> static int sys_fchownat(int dirfd, const char *pathname, uid_t owner,
> gid_t group, int flags)
> {
> @@ -435,7 +435,7 @@ _syscall3(int,sys_faccessat,int,dirfd,const char *,pathname,int,mode)
> #if defined(TARGET_NR_fchmodat) && defined(__NR_fchmodat)
> _syscall3(int,sys_fchmodat,int,dirfd,const char *,pathname, mode_t,mode)
> #endif
> -#if defined(TARGET_NR_fchownat) && defined(__NR_fchownat) && defined(USE_UID16)
> +#if defined(TARGET_NR_fchownat) && defined(__NR_fchownat)
> _syscall5(int,sys_fchownat,int,dirfd,const char *,pathname,
> uid_t,owner,gid_t,group,int,flags)
> #endif
> @@ -6817,18 +6817,35 @@ abi_long do_syscall(void *cpu_env, int num, abi_long arg1,
> case TARGET_NR_setfsgid:
> ret = get_errno(setfsgid(arg1));
> break;
> +#else /* USE_UID16 */
> +#if defined(TARGET_NR_fchownat) && defined(__NR_fchownat)
> + case TARGET_NR_fchownat:
> + if (!(p = lock_user_string(arg2)))
> + goto efault;
> + ret = get_errno(sys_fchownat(arg1, p, arg3, arg4, arg5));
> + unlock_user(p, arg2, 0);
> + break;
> +#endif
> #endif /* USE_UID16 */
>
> -#ifdef TARGET_NR_lchown32
> +#if defined(TARGET_NR_lchown32) || !defined(USE_UID16)
> +#if defined(TARGET_NR_lchown32)
> case TARGET_NR_lchown32:
> +#else
> + case TARGET_NR_lchown:
> +#endif
> if (!(p = lock_user_string(arg1)))
> goto efault;
> ret = get_errno(lchown(p, arg2, arg3));
> unlock_user(p, arg1, 0);
> break;
> #endif
> -#ifdef TARGET_NR_getuid32
> +#if defined(TARGET_NR_getuid32) || (defined(TARGET_NR_getuid) && !defined(USE_UID16))
> +#if defined(TARGET_NR_getuid32)
> case TARGET_NR_getuid32:
> +#else
> + case TARGET_NR_getuid:
> +#endif
> ret = get_errno(getuid());
> break;
> #endif
> @@ -6973,33 +6990,57 @@ abi_long do_syscall(void *cpu_env, int num, abi_long arg1,
> break;
> #endif
>
> -#ifdef TARGET_NR_getgid32
> +#if defined(TARGET_NR_getgid32) || (defined(TARGET_NR_getgid) && !defined(USE_UID16))
> +#if defined(TARGET_NR_getgid32)
> case TARGET_NR_getgid32:
> +#else
> + case TARGET_NR_getgid:
> +#endif
> ret = get_errno(getgid());
> break;
> #endif
> -#ifdef TARGET_NR_geteuid32
> +#if defined(TARGET_NR_geteuid32) || (defined(TARGET_NR_geteuid) && !defined(USE_UID16))
> +#if defined(TARGET_NR_geteuid32)
> case TARGET_NR_geteuid32:
> +#else
> + case TARGET_NR_geteuid:
> +#endif
> ret = get_errno(geteuid());
> break;
> #endif
> -#ifdef TARGET_NR_getegid32
> +#if defined(TARGET_NR_getegid32) || (defined(TARGET_NR_getegid) && !defined(USE_UID16))
> +#if defined(TARGET_NR_getegid32)
> case TARGET_NR_getegid32:
> +#else
> + case TARGET_NR_getegid:
> +#endif
> ret = get_errno(getegid());
> break;
> #endif
> -#ifdef TARGET_NR_setreuid32
> +#if defined(TARGET_NR_setreuid32) || !defined(USE_UID16)
> +#if defined(TARGET_NR_setreuid32)
> case TARGET_NR_setreuid32:
> +#else
> + case TARGET_NR_setreuid:
> +#endif
> ret = get_errno(setreuid(arg1, arg2));
> break;
> #endif
> -#ifdef TARGET_NR_setregid32
> +#if defined(TARGET_NR_setregid32) || !defined(USE_UID16)
> +#if defined(TARGET_NR_setregid32)
> case TARGET_NR_setregid32:
> +#else
> + case TARGET_NR_setregid:
> +#endif
> ret = get_errno(setregid(arg1, arg2));
> break;
> #endif
> -#ifdef TARGET_NR_getgroups32
> +#if defined(TARGET_NR_getgroups32) || !defined(USE_UID16)
> +#if defined(TARGET_NR_getgroups32)
> case TARGET_NR_getgroups32:
> +#else
> + case TARGET_NR_getgroups:
> +#endif
> {
> int gidsetsize = arg1;
> uint32_t *target_grouplist;
> @@ -7023,8 +7064,12 @@ abi_long do_syscall(void *cpu_env, int num, abi_long arg1,
> }
> break;
> #endif
> -#ifdef TARGET_NR_setgroups32
> +#if defined(TARGET_NR_setgroups32) || !defined(USE_UID16)
> +#if defined(TARGET_NR_setgroups32)
> case TARGET_NR_setgroups32:
> +#else
> + case TARGET_NR_setgroups:
> +#endif
> {
> int gidsetsize = arg1;
> uint32_t *target_grouplist;
> @@ -7044,18 +7089,30 @@ abi_long do_syscall(void *cpu_env, int num, abi_long arg1,
> }
> break;
> #endif
> -#ifdef TARGET_NR_fchown32
> +#if defined(TARGET_NR_fchown32) || !defined(USE_UID16)
> +#if defined(TARGET_NR_fchown32)
> case TARGET_NR_fchown32:
> +#else
> + case TARGET_NR_fchown:
> +#endif
> ret = get_errno(fchown(arg1, arg2, arg3));
> break;
> #endif
> -#ifdef TARGET_NR_setresuid32
> +#if defined(TARGET_NR_setresuid32) || !defined(USE_UID16)
> +#if defined(TARGET_NR_setresuid32)
> case TARGET_NR_setresuid32:
> +#else
> + case TARGET_NR_setresuid:
> +#endif
> ret = get_errno(setresuid(arg1, arg2, arg3));
> break;
> #endif
> -#ifdef TARGET_NR_getresuid32
> +#if defined(TARGET_NR_getresuid32) || !defined(USE_UID16)
> +#if defined(TARGET_NR_getresuid32)
> case TARGET_NR_getresuid32:
> +#else
> + case TARGET_NR_getresuid:
> +#endif
> {
> uid_t ruid, euid, suid;
> ret = get_errno(getresuid(&ruid, &euid, &suid));
> @@ -7068,13 +7125,21 @@ abi_long do_syscall(void *cpu_env, int num, abi_long arg1,
> }
> break;
> #endif
> -#ifdef TARGET_NR_setresgid32
> +#if defined(TARGET_NR_setresgid32) || !defined(USE_UID16)
> +#if defined(TARGET_NR_setresgid32)
> case TARGET_NR_setresgid32:
> +#else
> + case TARGET_NR_setresgid:
> +#endif
> ret = get_errno(setresgid(arg1, arg2, arg3));
> break;
> #endif
> +#if defined(TARGET_NR_getresgid32) || !defined(USE_UID16)
> #ifdef TARGET_NR_getresgid32
> case TARGET_NR_getresgid32:
> +#else
> + case TARGET_NR_getresgid:
> +#endif
> {
> gid_t rgid, egid, sgid;
> ret = get_errno(getresgid(&rgid, &egid, &sgid));
> @@ -7087,31 +7152,51 @@ abi_long do_syscall(void *cpu_env, int num, abi_long arg1,
> }
> break;
> #endif
> -#ifdef TARGET_NR_chown32
> +#if defined(TARGET_NR_chown32) || !defined(USE_UID16)
> +#if defined(TARGET_NR_chown32)
> case TARGET_NR_chown32:
> +#else
> + case TARGET_NR_chown:
> +#endif
> if (!(p = lock_user_string(arg1)))
> goto efault;
> ret = get_errno(chown(p, arg2, arg3));
> unlock_user(p, arg1, 0);
> break;
> #endif
> -#ifdef TARGET_NR_setuid32
> +#if defined(TARGET_NR_setuid32) || !defined(USE_UID16)
> +#if defined(TARGET_NR_setuid32)
> case TARGET_NR_setuid32:
> +#else
> + case TARGET_NR_setuid:
> +#endif
> ret = get_errno(setuid(arg1));
> break;
> #endif
> -#ifdef TARGET_NR_setgid32
> +#if defined(TARGET_NR_setgid32) || !defined(USE_UID16)
> +#if defined(TARGET_NR_setgid32)
> case TARGET_NR_setgid32:
> +#else
> + case TARGET_NR_setgid:
> +#endif
> ret = get_errno(setgid(arg1));
> break;
> #endif
> -#ifdef TARGET_NR_setfsuid32
> +#if defined(TARGET_NR_setfsuid32) || !defined(USE_UID16)
> +#if defined(TARGET_NR_setfsuid32)
> case TARGET_NR_setfsuid32:
> +#else
> + case TARGET_NR_setfsuid:
> +#endif
> ret = get_errno(setfsuid(arg1));
> break;
> #endif
> -#ifdef TARGET_NR_setfsgid32
> +#if defined(TARGET_NR_setfsgid32) || !defined(USE_UID16)
> +#if defined(TARGET_NR_setfsgid32)
> case TARGET_NR_setfsgid32:
> +#else
> + case TARGET_NR_setfsgid:
> +#endif
> ret = get_errno(setfsgid(arg1));
> break;
> #endif
This patch looks fine to me. That said as for the previous patch, I
don't know very well linux-user, and I would appreciate if someone with
a good knowledge of linux-user can review it. Riku maybe (CC:ed)?
--
Aurelien Jarno GPG: 1024D/F1BCDB73
aurelien@aurel32.net http://www.aurel32.net
^ permalink raw reply
* Re: [PATCH] Remove non-MAINTAINERS email address references for Lennert Buytenhek.
From: Lennert Buytenhek @ 2011-04-10 20:27 UTC (permalink / raw)
To: David Miller; +Cc: akpm, linux-kernel
In-Reply-To: <20110410.132002.193717670.davem@davemloft.net>
On Sun, Apr 10, 2011 at 01:20:02PM -0700, David Miller wrote:
> > This gets rid of all (obsolete as well as still valid) email addresses
> > for Lennert Buytenhek across the tree -- MAINTAINERS should be used for
> > obtaining a valid email address.
> >
> > Signed-off-by: Lennert Buytenhek <buytenh@wantstofly.org>
>
> Lennert, this is silly.
>
> That email address acts as part of the identification of who you
> are, and is part of the copyright.
The problem is that half of them are out of date. I at first sent a
patch to change them all over to buytenh@wantstofly.org, but then got:
http://marc.info/?l=linux-kernel&m=129858453409012&w=2
which seemed sensible. :-/
^ permalink raw reply
* [PATCH] Re: btrfs does not work on usermode linux
From: Sergei Trofimovich @ 2011-04-10 20:24 UTC (permalink / raw)
To: Sergei Trofimovich; +Cc: chris.mason, linux-btrfs, cwillu
In-Reply-To: <20110410230622.09e965ae@sf>
[-- Attachment #1.1: Type: text/plain, Size: 3870 bytes --]
On Sun, 10 Apr 2011 23:06:22 +0300
Sergei Trofimovich <slyich@gmail.com> wrote:
> > > According to https://btrfs.wiki.kernel.org/index.php/Debugging_Btrfs_with_GDB
> > > UML did work once.
> > >
> > > Now it corrupts data and triggers BUG_ON once you
> > > start to use it. I tried both 2.6.38 and 2.6.39-rc2 (x86_64)
> > > I need some help to track it down.
> > >
> > > doing 'touch `seq 1 11`; rm 11' kills the kernel:
> >
> > 2.6.36 works 2.6.37 doesn't. bsecting
>
> Bisected down to:
>
> commit 59daa706fbec745684702741b9f5373142dd9fdc (v2.6.36-rc2-2-g59daa70)
> Author: Ma Ling <ling.ma@intel.com>
> Date: Tue Jun 29 03:24:25 2010 +0800
>
> x86, mem: Optimize memcpy by avoiding memory false dependece
>
> Which means btrfs passes overlapping areas to memcpy. I've added some debug info
> and found out rough place:
> touching files 1 .. 11
> #run> touch 1 2 3 4 5 6 7 8 9 10 11
> [ 2.270000] memcpy overlap detected: memcpy(dst=0000000070654e8a, src=0000000070654ea9, size=171) [delta=31]
> [ 2.270000] ------------[ cut here ]------------
> [ 2.270000] WARNING: at /home/slyfox/linux-2.6/fs/btrfs/memcpy_debug.c:18 btrfs_memcpy+0x52/0x68()
> [ 2.270000] Call Trace:
> [ 2.270000] 7064b748: [<600eff46>] map_extent_buffer+0x62/0x9e
> [ 2.270000] 7064b758: [<60029ad9>] warn_slowpath_common+0x59/0x70
> [ 2.270000] 7064b798: [<60029b05>] warn_slowpath_null+0x15/0x17
> [ 2.270000] 7064b7a8: [<6011129e>] btrfs_memcpy+0x52/0x68
> [ 2.270000] 7064b7d8: [<600efa01>] memcpy_extent_buffer+0x18d/0x1da
> [ 2.270000] 7064b858: [<600efae2>] memmove_extent_buffer+0x94/0x208
> [ 2.270000] 7064b8d8: [<600bc4b0>] setup_items_for_insert+0x2b8/0x426
> [ 2.270000] 7064b8e8: [<600bb25a>] btrfs_leaf_free_space+0x62/0xa6
> [ 2.270000] 7064b9c8: [<600c13f3>] btrfs_insert_empty_items+0xa3/0xb5
> [ 2.270000] 7064ba38: [<600ce690>] insert_with_overflow+0x33/0xf1
> [ 2.270000] 7064ba88: [<600ce7d4>] btrfs_insert_dir_item+0x86/0x268
> [ 2.270000] 7064bae8: [<601b498b>] _raw_spin_unlock+0x9/0xb
> [ 2.270000] 7064bb48: [<600ddef1>] btrfs_add_link+0x10d/0x170
> [ 2.270000] 7064bbc8: [<600ddf7a>] btrfs_add_nondir+0x26/0x52
> [ 2.270000] 7064bc08: [<600de73f>] btrfs_create+0xf2/0x1c0
> [ 2.270000] 7064bc18: [<6007ccff>] generic_permission+0x57/0x9d
> [ 2.270000] 7064bc68: [<6007cf60>] vfs_create+0x6a/0x75
>
> which is in extent_io:copy_pages. I haven't dig further only made sure the following
> patch below (practically converts copy_pages to move_pages). It certainly does not
> look the right thing, but I don't understand extent_io contents yet to understand what
> actually happened.
>
> diff --git a/fs/btrfs/extent_io.c b/fs/btrfs/extent_io.c
> index 20ddb28..4cab7db 100644
> --- a/fs/btrfs/extent_io.c
> +++ b/fs/btrfs/extent_io.c
> @@ -3893,14 +3893,17 @@ static void copy_pages(struct page *dst_page, struct page *src_page,
> char *src_kaddr;
>
> if (dst_page != src_page)
> + {
> src_kaddr = kmap_atomic(src_page, KM_USER1);
> + memcpy(dst_kaddr + dst_off, src_kaddr + src_off, len);
> + kunmap_atomic(src_kaddr, KM_USER1);
> + }
> else
> + {
> src_kaddr = dst_kaddr;
> -
> - memcpy(dst_kaddr + dst_off, src_kaddr + src_off, len);
> + memmove(dst_kaddr + dst_off, src_kaddr + src_off, len);
> + }
> kunmap_atomic(dst_kaddr, KM_USER0);
> - if (dst_page != src_page)
> - kunmap_atomic(src_kaddr, KM_USER1);
> }
>
> void memcpy_extent_buffer(struct extent_buffer *dst, unsigned long dst_offset,
Attached nicer patch. Looks like original logic expected ceritain memcpy copy direction,
but there isn't one!
--
Sergei
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1.2: 0001-btrfs-properly-handle-overlapping-areas-in-memmove_e.patch --]
[-- Type: text/x-patch, Size: 2763 bytes --]
From 0eaf33265f8a2e0d76ee6db1ad74ee4422efb122 Mon Sep 17 00:00:00 2001
From: Sergei Trofimovich <slyfox@gentoo.org>
Date: Sun, 10 Apr 2011 23:19:53 +0300
Subject: [PATCH] btrfs: properly handle overlapping areas in memmove_extent_buffer
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
Fix data corruption caused by memcpy() usage on overlapping data.
I've observed it first when found out usermode linux crash on btrfs.
Сall chain is the following:
------------[ cut here ]------------
WARNING: at /home/slyfox/linux-2.6/fs/btrfs/extent_io.c:3900 memcpy_extent_buffer+0x1a5/0x219()
Call Trace:
6fa39a58: [<601b495e>] _raw_spin_unlock_irqrestore+0x18/0x1c
6fa39a68: [<60029ad9>] warn_slowpath_common+0x59/0x70
6fa39aa8: [<60029b05>] warn_slowpath_null+0x15/0x17
6fa39ab8: [<600efc97>] memcpy_extent_buffer+0x1a5/0x219
6fa39b48: [<600efd9f>] memmove_extent_buffer+0x94/0x208
6fa39bc8: [<600becbf>] btrfs_del_items+0x214/0x473
6fa39c78: [<600ce1b0>] btrfs_delete_one_dir_name+0x7c/0xda
6fa39cc8: [<600dad6b>] __btrfs_unlink_inode+0xad/0x25d
6fa39d08: [<600d7864>] btrfs_start_transaction+0xe/0x10
6fa39d48: [<600dc9ff>] btrfs_unlink_inode+0x1b/0x3b
6fa39d78: [<600e04bc>] btrfs_unlink+0x70/0xef
6fa39dc8: [<6007f0d0>] vfs_unlink+0x58/0xa3
6fa39df8: [<60080278>] do_unlinkat+0xd4/0x162
6fa39e48: [<600517db>] call_rcu_sched+0xe/0x10
6fa39e58: [<600452a8>] __put_cred+0x58/0x5a
6fa39e78: [<6007446c>] sys_faccessat+0x154/0x166
6fa39ed8: [<60080317>] sys_unlink+0x11/0x13
6fa39ee8: [<60016b80>] handle_syscall+0x58/0x70
6fa39f08: [<60021377>] userspace+0x2d4/0x381
6fa39fc8: [<60014507>] fork_handler+0x62/0x69
---[ end trace 70b0ca2ef0266b93 ]---
http://www.mail-archive.com/linux-btrfs@vger.kernel.org/msg09302.html
Signed-off-by: Sergei Trofimovich <slyfox@gentoo.org>
---
fs/btrfs/extent_io.c | 3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/fs/btrfs/extent_io.c b/fs/btrfs/extent_io.c
index 20ddb28..3bbda41 100644
--- a/fs/btrfs/extent_io.c
+++ b/fs/btrfs/extent_io.c
@@ -3897,6 +3897,7 @@ static void copy_pages(struct page *dst_page, struct page *src_page,
else
src_kaddr = dst_kaddr;
+ BUG_ON(abs(src_off - dst_off) < len);
memcpy(dst_kaddr + dst_off, src_kaddr + src_off, len);
kunmap_atomic(dst_kaddr, KM_USER0);
if (dst_page != src_page)
@@ -3970,7 +3971,7 @@ void memmove_extent_buffer(struct extent_buffer *dst, unsigned long dst_offset,
"len %lu len %lu\n", dst_offset, len, dst->len);
BUG_ON(1);
}
- if (dst_offset < src_offset) {
+ if (abs(dst_offset - src_offset) >= len) {
memcpy_extent_buffer(dst, dst_offset, src_offset, len);
return;
}
--
1.7.3.4
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]
^ permalink raw reply related
* Re: [PATCH] Remove non-MAINTAINERS email address references for Lennert Buytenhek.
From: David Miller @ 2011-04-10 20:20 UTC (permalink / raw)
To: buytenh; +Cc: akpm, linux-kernel
In-Reply-To: <20110410134504.GG22881@wantstofly.org>
From: Lennert Buytenhek <buytenh@wantstofly.org>
Date: Sun, 10 Apr 2011 15:45:04 +0200
> This gets rid of all (obsolete as well as still valid) email addresses
> for Lennert Buytenhek across the tree -- MAINTAINERS should be used for
> obtaining a valid email address.
>
> Signed-off-by: Lennert Buytenhek <buytenh@wantstofly.org>
Lennert, this is silly.
That email address acts as part of the identification of who you
are, and is part of the copyright.
^ permalink raw reply
* GET BACK TO ME IMMEDIATELY
From: GET BACK TO ME IMMEDIATELY @ 2011-04-10 20:20 UTC (permalink / raw)
Hello
I wish to ask for your consent for a partnership project that I would want both of us to execute mutually which is beneficial. However my name is Mr. Rodney Smith. Kindly get back to me to confirm the receipt of this massage so that I will give you full details of the project.
Send your reply to my private email at rodney_smith@ibibo.com
I am waiting for your permission.
Warm regards
Mr. Rodney Smith
Email:smithrodney@ibibo.com
^ permalink raw reply
* [Qemu-devel] Re: [PATCH 3/5] target-i386: fix cpu-exec.o build with softfloat
From: Peter Maydell @ 2011-04-10 20:18 UTC (permalink / raw)
To: Aurelien Jarno; +Cc: qemu-devel
In-Reply-To: <1302462807-8795-3-git-send-email-aurelien@aurel32.net>
On 10 April 2011 20:13, Aurelien Jarno <aurelien@aurel32.net> wrote:
> Fixing the definition of CPU86_LDoubleU allow building cpu-exec.o with
> softfloat.
>
> Cc: Peter Maydell <peter.maydell@linaro.org>
> Signed-off-by: Aurelien Jarno <aurelien@aurel32.net>
> ---
> target-i386/exec.h | 4 ++--
> 1 files changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/target-i386/exec.h b/target-i386/exec.h
> index 6f9f709..d6922f3 100644
> --- a/target-i386/exec.h
> +++ b/target-i386/exec.h
> @@ -145,7 +145,7 @@ static inline void svm_check_intercept(uint32_t type)
>
> /* only for x86 */
> typedef union {
> - long double d;
> + floatx80 d;
> struct {
> unsigned long long lower;
> unsigned short upper;
> @@ -164,7 +164,7 @@ typedef union {
>
> /* NOTE: arm is horrible as double 32 bit words are stored in big endian ! */
> typedef union {
> - double d;
> + float64 d;
> #if !defined(HOST_WORDS_BIGENDIAN) && !defined(__arm__)
> struct {
> uint32_t lower;
I note that the !USE_X86LDOUBLE typedef for CPU86_LDoubleU is an
out-of-date version of cpu-all.h's CPU_DoubleU (it doesn't
get the ARM VFP endianness right).
Given patch 1 in this series, is it possible now just to have
#ifdef USE_X86LDOUBLE
typedef CPU_LDoubleU CPU86_LDoubleU;
/* other stuff */
#else
typedef CPU_DoubleU CPU86_LDoubleU;
/* ... */
#endif
?
-- PMM
^ permalink raw reply
* [Qemu-devel] Re: [PATCH] target-ppc: remove #ifdef FLOAT128
From: Alexander Graf @ 2011-04-10 20:18 UTC (permalink / raw)
To: Peter Maydell; +Cc: qemu-devel, Aurelien Jarno
In-Reply-To: <BANLkTikmrCCAyXOQLPbahH001xaNhbkAWg@mail.gmail.com>
On 10.04.2011, at 22:08, Peter Maydell wrote:
> On 10 April 2011 20:23, Alexander Graf <agraf@suse.de> wrote:
>> On 10.04.2011, at 21:12, Aurelien Jarno wrote:
>>> Now that PPC defaults to softfloat which always provides float128
>>> support, there is no need to keep two version of the code, depending if
>>> float128 support is available or not. Suggested by Peter Maydell.
>
>> Looks good to me, but I'd leave this to Peter's ack.
>
> I think it's a sensible (and pretty straightforward) cleanup, yes.
> [my bias towards emulation-accuracy means I don't really see
> much place for softfloat-native in a tcg qemu target, so I have
> no compunction about dropping support for it. :-)]
I'm fairly indifferent. The easier we can make the targets, the better IMHO. Of course, if we're dog slow and accurate that doesn't help too much either :).
Alex
^ permalink raw reply
* Re: [Qemu-devel] [PATCH 15/15] tcg: use ext op for deposit
From: Alexander Graf @ 2011-04-10 20:17 UTC (permalink / raw)
To: Aurelien Jarno; +Cc: peter.maydell, QEMU-devel Developers, Richard Henderson
In-Reply-To: <20110410200812.GF4551@volta.aurel32.net>
On 10.04.2011, at 22:08, Aurelien Jarno wrote:
> On Sun, Apr 10, 2011 at 09:25:33PM +0200, Alexander Graf wrote:
>>
>> On 10.04.2011, at 21:23, Aurelien Jarno wrote:
>>
>>> On Tue, Apr 05, 2011 at 09:55:09AM +0200, Alexander Graf wrote:
>>>>
>>>> On 05.04.2011, at 06:54, Aurelien Jarno wrote:
>>>>
>>>>> On Mon, Apr 04, 2011 at 04:32:24PM +0200, Alexander Graf wrote:
>>>>>> With the s390x target we use the deposit instruction to store 32bit values
>>>>>> into 64bit registers without clobbering the upper 32 bits.
>>>>>>
>>>>>> This specific operation can be optimized slightly by using the ext operation
>>>>>> instead of an explicit and in the deposit instruction. This patch adds that
>>>>>> special case to the generic deposit implementation.
>>>>>>
>>>>>> Signed-off-by: Alexander Graf <agraf@suse.de>
>>>>>> ---
>>>>>> tcg/tcg-op.h | 6 +++++-
>>>>>> 1 files changed, 5 insertions(+), 1 deletions(-)
>>>>>
>>>>> Have you really measuring a difference here? This should already be
>>>>> handled, at least on x86, by this code:
>>>>>
>>>>> if (TCG_TARGET_REG_BITS == 64) {
>>>>> if (val == 0xffffffffu) {
>>>>> tcg_out_ext32u(s, r0, r0);
>>>>> return;
>>>>> }
>>>>> if (val == (uint32_t)val) {
>>>>> /* AND with no high bits set can use a 32-bit operation. */
>>>>> rexw = 0;
>>>>> }
>>>>> }
>>>>
>>>> I've certainly looked at the -d op logs and seen that instead of creating a const tcg variable plus an AND there was now an extu opcode issued, yes. No idea why the case up there didn't trigger.
>>>>
>>>
>>> The question there is looking at -d out_asm. They should be the same at
>>> the end as the code I pasted above is from tcg/i386/tcg-target.c.
>>
>> Yes. I was trying to optimize for maximum op length. TCG defines a maximum number of tcg ops to be issued by each target instruction. Since s390 is very CISCy, there are instructions that translate into lots of microops, but are still faster than a C call (register save/restore mostly).
>>
>> Without this patch, there are some places where we hit that number :).
>
> Is it on 32-bit on or 64-bit? If we reach this number, it's probably
> better to either implement this instruction with an helper, or maybe
> increase the number of maximum ops. What is this instruction?
This was on x86_64. I hit limits with LMH and LM, but reduced them to fit into the picture with this optimization :). If you like, I can give you a statically linked binary that could exceed the limits.
Alex
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
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.