On Tue, 8 Nov 2011, Arnaldo Carvalho de Melo wrote:
> Em Tue, Nov 08, 2011 at 01:07:55PM +0100, Ingo Molnar escreveu:
> > * Vince Weaver wrote:
> > > as mentioned before I have my own perf_event test suite with 20+ tests.
> > > http://web.eecs.utk.edu/~vweaver1/projects/perf-events/validation.h
On Tue, 2011-11-08 at 20:17 -0800, Aaron Fabbri wrote:
> I'm going to send out chunks of comments as I go over this stuff. Below
> I've covered the documentation file and vfio_iommu.c. More comments coming
> soon...
>
> On 11/3/11 1:12 PM, "Alex Williamson" wrote:
>
> > VFIO provides a secure,
I'm going to send out chunks of comments as I go over this stuff. Below
I've covered the documentation file and vfio_iommu.c. More comments coming
soon...
On 11/3/11 1:12 PM, "Alex Williamson" wrote:
> VFIO provides a secure, IOMMU based interface for user space
> drivers, including device ass
The Buildbot has detected a new failure on builder
disable_kvm_x86_64_debian_5_0 while building qemu-kvm.
Full details are available at:
http://buildbot.b1-systems.de/qemu-kvm/builders/disable_kvm_x86_64_debian_5_0/builds/1009
Buildbot URL: http://buildbot.b1-systems.de/qemu-kvm/
Buildslave fo
The Buildbot has detected a new failure on builder disable_kvm_i386_debian_5_0
while building qemu-kvm.
Full details are available at:
http://buildbot.b1-systems.de/qemu-kvm/builders/disable_kvm_i386_debian_5_0/builds/1010
Buildbot URL: http://buildbot.b1-systems.de/qemu-kvm/
Buildslave for th
The Buildbot has detected a new failure on builder default_x86_64_debian_5_0
while building qemu-kvm.
Full details are available at:
http://buildbot.b1-systems.de/qemu-kvm/builders/default_x86_64_debian_5_0/builds/1019
Buildbot URL: http://buildbot.b1-systems.de/qemu-kvm/
Buildslave for this B
The Buildbot has detected a new failure on builder default_i386_debian_5_0
while building qemu-kvm.
Full details are available at:
http://buildbot.b1-systems.de/qemu-kvm/builders/default_i386_debian_5_0/builds/1021
Buildbot URL: http://buildbot.b1-systems.de/qemu-kvm/
Buildslave for this Build
int_pending was only being lowered if a bit in pending_exceptions
was cleared during exception delivery -- but for interrupts, we clear
it during IACK/TSR emulation. This caused paravirt for enabling
MSR[EE] to be ineffective.
Signed-off-by: Scott Wood
---
arch/powerpc/kvm/booke.c |6 +-
This prevents us from inappropriately blocking in a KVM_SET_REGS
ioctl -- the MSR[WE] will take effect when the guest is next entered.
It also causes SRR1[WE] to be set when we enter the guest's interrupt
handler, which is what e500 hardware is documented to do.
Signed-off-by: Scott Wood
---
ar
This allows additional registers to be accessed by the guest
in PR-mode KVM without trapping.
SPRG4-7 are readable from userspace. On booke, KVM will sync
these registers when it enters the guest, so that accesses from
guest userspace will work. The guest kernel, OTOH, must consistently
use eith
Also fix wrteei 1 paravirt to check for a pending interrupt.
Signed-off-by: Scott Wood
---
arch/powerpc/kernel/kvm.c | 92 +-
arch/powerpc/kernel/kvm_emul.S | 96 ++-
2 files changed, 154 insertions(+), 34 deletions
This function should be called with interrupts disabled, to avoid
a race where an exception is delivered after we check, but the
resched kick is received before we disable interrupts (and thus doesn't
actually trigger the exit code that would recheck exceptions).
booke already does this properly i
This function also updates paravirt int_pending, so rename it
to be more obvious that this is a collection of checks run prior
to (re)entering a guest.
Signed-off-by: Scott Wood
---
arch/powerpc/include/asm/kvm_ppc.h |2 +-
arch/powerpc/kvm/book3s.c |2 +-
arch/powerpc/kvm/book3
The first couple patches are some minor reorganization of the checking
done prior to entering the guest, which should avoid some races relative
to exception qeueing, and give us a more clearly-named place (which later
patches in the series use) to put other checks that we want to always run
before
From: Roopa Prabhu
This patch adds support to get MAC and VLAN filter netdev ops
on a macvlan interface. It adds support for get_rx_filter_addr_size,
get_rx_filter_vlan_size, fill_rx_filter_addr and fill_rx_filter_vlan
netdev ops
Signed-off-by: Roopa Prabhu
Signed-off-by: Christian Benvenuti
S
From: Roopa Prabhu
This patch adds support for MAC and VLAN filter netdev ops
on a macvlan interface. It adds support for set_rx_filter_addr and
set_rx_filter_vlan netdev operations. It currently supports only macvlan
PASSTHRU mode. And removes the code that puts the lowerdev in promiscous mode.
From: Roopa Prabhu
This patch adds support in rtnetlink for IFLA_RX_VF_FILTERS and
IFLA_RX_FILTER get. It gets the size of the filters using
netdev_ops->get_rx_filter_addr_size and netdev_ops->get_rx_filter_vlan_size
and uses netdev_ops->get_rx_filter_addr and netdev_ops->get_rx_filter_vlan.
In c
From: Roopa Prabhu
This patch adds the following netdev_ops to set and get MAC/VLAN
filters on a SRIOV VF or any netdev interface. Each op takes a vf argument.
vf value of SELF_VF or -1 is for applying the operation directly on the
interface.
ndo_set_rx_filter_addr - to set address filter
ndo_ge
From: Roopa Prabhu
This patch adds support in rtnetlink for IFLA_RX_FILTER and
IFLA_VF_RX_FILTERS set. It calls netdev_ops->set_rx_filter_addr and
rtnl_link_ops->set_rx_filter_vlan
Signed-off-by: Roopa Prabhu
Signed-off-by: Christian Benvenuti
Signed-off-by: David Wang
---
include/linux/if_l
From: Roopa Prabhu
This patch introduces the following netlink interface to set
MAC and VLAN filters on an network interface. It can be used to
set RX filter on any network interface (if supported by the driver) and
also on a SRIOV VF via its PF
Interface to set RX filter on a SRIOV VF
[IFLA_VF_
v3 -> v4
- Removed RFC in subject-prefix
- Regenerated patches over latest net-next
(no code changes)
Thanks to Greg Rose for evaluating v3
v2 -> v3
- Moved set and get filter ops from rtnl_link_ops to netdev_ops
- Support for SRIOV VFs.
[Note: The get filters msg (in the way current get
Currently we check prior to returning from a lightweight exit,
but not prior to initial entry.
book3s already does a similar test.
Signed-off-by: Scott Wood
---
arch/powerpc/kvm/booke.c | 10 +-
1 files changed, 9 insertions(+), 1 deletions(-)
diff --git a/arch/powerpc/kvm/booke.c b/
On Tue, Nov 08, 2011 at 08:51:38PM +1030, Rusty Russell wrote:
> On Tue, 8 Nov 2011 08:32:50 +0200, "Michael S. Tsirkin"
> wrote:
> > On Tue, Nov 08, 2011 at 10:23:33AM +1030, Rusty Russell wrote:
> > > Even so, should we just use the PCI cap list, and have each
> > > cap entry just contain a BIR
On Tue, 8 Nov 2011, Ted Ts'o wrote:
> On Tue, Nov 08, 2011 at 01:55:09PM +0100, Ingo Molnar wrote:
> > I guess you can do well with a split project as well - my main claim
> > is that good compatibility comes *naturally* with integration.
>
> Here I have to disagree; my main worry is that inte
On Tue, 8 Nov 2011 08:32:50 +0200, "Michael S. Tsirkin" wrote:
> On Tue, Nov 08, 2011 at 10:23:33AM +1030, Rusty Russell wrote:
> > Even so, should we just use the PCI cap list, and have each
> > cap entry just contain a BIR & offset?
> >
> > Thanks,
> > Rusty.
>
> And size :)
> I say, Rusty, di
On Thu, Oct 27, 2011 at 07:25:58PM +0200, Jan Kiszka wrote:
> Keep a per-VCPU xsave buffer for kvm_put/get_xsave instead of
> continuously allocating and freeing it on state sync.
>
> Signed-off-by: Jan Kiszka
> ---
> target-i386/cpu.h |3 ++-
> target-i386/kvm.c | 15 +++
> 2
On Mon, Nov 7, 2011 at 12:03 PM, Anthony Liguori wrote:
> On 11/07/2011 11:52 AM, Sasha Levin wrote:
>>
>> Hi Anthony,
>>
>> Thank you for your comments!
>>
>> On Mon, 2011-11-07 at 11:37 -0600, Anthony Liguori wrote:
>>>
>>> On 11/06/2011 02:40 PM, Sasha Levin wrote:
Hi all,
I
From: Thomas Meyer
Use kmemdup rather than duplicating its implementation
The semantic patch that makes this change is available
in scripts/coccinelle/api/memdup.cocci.
More information about semantic patching is available at
http://coccinelle.lip6.fr/
Signed-off-by: Thomas Meyer
---
di
On Tue, Nov 08, 2011 at 07:14:57PM +0200, Anca Emanuel wrote:
> @Ten Ts'o: you are sponsored by something like microsoft (joking) ?
> Stop trolling. If you are not familiar with perf, or other tools, save
> your time and do some useful things.
I am quite familiar with perf. A disagreement with ho
There's no point in including a file not necessary on a
cartesian config file, so it's more likely that the file
missing is actually a harmful problem.
So turn the missing file into a MissingIncludeError and
throw it.
Signed-off-by: Lucas Meneghel Rodrigues
---
client/common_lib/cartesian_confi
From: Thomas Meyer
Casting (void *) value returned by kmalloc is useless
as mentioned in Documentation/CodingStyle, Chap 14.
The semantic patch that makes this change is available
in scripts/coccinelle/api/alloc/drop_kmalloc_cast.cocci.
More information about semantic patching is available
> -Original Message-
> From: netdev-ow...@vger.kernel.org [mailto:netdev-ow...@vger.kernel.org]
> On Behalf Of Roopa Prabhu
> Sent: Tuesday, October 18, 2011 11:26 PM
> To: net...@vger.kernel.org
> Cc: s...@us.ibm.com; dragos.tatu...@gmail.com; a...@arndb.de;
> kvm@vger.kernel.org; m...@red
On 11/08/2011 07:34 PM, Alexander Graf wrote:
>>
>>> It could work with a btrfs snapshot, but not everyone uses that.
>> Or LVM snapshot. Either way, just reusing the root fs without care
>> is a dumb idea, and I really don't want any tool or script that
>> encurages such braindead behaviour in th
* Alexander Graf (ag...@suse.de) wrote:
> On 29.10.2011, at 20:45, Bharata B Rao wrote:
> > As guests become NUMA aware, it becomes important for the guests to
> > have correct NUMA policies when they run on NUMA aware hosts.
> > Currently limited support for NUMA binding is available via libvirt
>
On 11/07/2011 09:33 AM, Gerd Hoffmann wrote:
This patch adds a pc-1.0 machine type.
Signed-off-by: Gerd Hoffmann
Applied both. Thanks.
Regards,
Anthony Liguori
---
hw/pc_piix.c | 14 +++---
1 files changed, 11 insertions(+), 3 deletions(-)
diff --git a/hw/pc_piix.c b/hw/pc_p
On 11/08/2011 03:59 PM, Christoph Hellwig wrote:
On Tue, Nov 08, 2011 at 04:57:04PM +0200, Avi Kivity wrote:
Running qemu -snapshot on the actual root block device is the only
safe way to reuse the host installation, although it gets a bit
complicated if people have multiple devices mounted into
kvmppc_h_pr is only available if CONFIG_KVM_BOOK3S_64_PR.
Signed-off-by: Andreas Schwab
---
arch/powerpc/kvm/book3s_pr.c |2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/arch/powerpc/kvm/book3s_pr.c b/arch/powerpc/kvm/book3s_pr.c
index bc4d50d..05473b5 100644
--- a/arch/
@Ten Ts'o: you are sponsored by something like microsoft (joking) ?
Stop trolling. If you are not familiar with perf, or other tools, save
your time and do some useful things.
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majord...@vger.kernel.org
Mor
compute_tlbie_rb is only used on ppc64 and cannot be compiled on ppc32.
Signed-off-by: Andreas Schwab
---
arch/powerpc/include/asm/kvm_book3s.h| 33 --
arch/powerpc/include/asm/kvm_book3s_64.h | 33 ++
2 files changed, 33 insertions
On Tue, Nov 08, 2011 at 01:55:09PM +0100, Ingo Molnar wrote:
> I guess you can do well with a split project as well - my main claim
> is that good compatibility comes *naturally* with integration.
Here I have to disagree; my main worry is that integration makes it
*naturally* easy for people to s
Em Tue, Nov 08, 2011 at 04:38:48PM +0100, Gerd Hoffmann escreveu:
> Seems to have no effect, guess the distro perf is too old (RHEL-6).
> > [tui]
> > report = off
> That works. I don't want turn off the tui altogether though, I actually
> like the interactive expanding+collapsing of the call
On Tue, Nov 08, 2011 at 10:32:25AM +0100, Ingo Molnar wrote:
>
> None of the perf developers with whom i'm working complained about
> the shared repo so far - publicly or privately. By all means they are
> enjoying it and if you look at the stats and results you'll agree
> that they are highly
Hi,
>> documentation: Where the heck is the perf config file documented, other
>> than source code? Reading the parser to figure how the config file is
>> supposed to look like really isn't fun :(
>
>> I'm looking for a way to disable the colors in the perf report tui. Or
>> configure them
Hi Richard,
(I'm adding Sasha to the CC.)
On Tue, Nov 8, 2011 at 4:44 PM, richard -rw- weinberger
wrote:
> Pekka,
>
> On Fri, Nov 4, 2011 at 9:38 AM, Pekka Enberg wrote:
>> ./kvm run
>>
>> We also support booting both raw images and QCOW2 images in read-only
>> mode:
>>
>> ./kvm run -d de
On Tue, Nov 08, 2011 at 05:26:03PM +0200, Pekka Enberg wrote:
> On Tue, Nov 8, 2011 at 4:52 PM, Christoph Hellwig wrote:
> > Nevermind that running virtfs as a rootfs is a really dumb idea. ?You
> > do now want to run a VM that has a rootfs that gets changed all the
> > time behind your back.
>
>
On Tue, Nov 8, 2011 at 4:52 PM, Christoph Hellwig wrote:
> Nevermind that running virtfs as a rootfs is a really dumb idea. You
> do now want to run a VM that has a rootfs that gets changed all the
> time behind your back.
It's rootfs binaries that are shared, not configuration. It's
unfortunate
git://git.kernel.org/pub/scm/virt/kvm/kvm.git
git://git.kernel.org/pub/scm/virt/kvm/qemu-kvm.git
git://git.kernel.org/pub/scm/virt/kvm/kvm-unit-tests.git
happy fetching!
--
error compiling committee.c: too many arguments to function
--
To unsubscribe from this list: send the line "unsubscribe k
On 2011-11-08 15:52, Christoph Hellwig wrote:
> On Tue, Nov 08, 2011 at 04:41:40PM +0200, Avi Kivity wrote:
>> On 11/06/2011 03:35 AM, Alexander Graf wrote:
>>> To quickly get going, just execute the following as user:
>>>
>>> $ ./Documentation/run-qemu.sh -r / -a init=/bin/bash
>>>
>>> This wi
On Tue, Nov 08, 2011 at 04:57:04PM +0200, Avi Kivity wrote:
> > Running qemu -snapshot on the actual root block device is the only
> > safe way to reuse the host installation, although it gets a bit
> > complicated if people have multiple devices mounted into the namespace.
>
> How is -snapshot an
On 11/08/2011 04:52 PM, Christoph Hellwig wrote:
> On Tue, Nov 08, 2011 at 04:41:40PM +0200, Avi Kivity wrote:
> > On 11/06/2011 03:35 AM, Alexander Graf wrote:
> > > To quickly get going, just execute the following as user:
> > >
> > > $ ./Documentation/run-qemu.sh -r / -a init=/bin/bash
> > >
On Tue, Nov 8, 2011 at 4:52 PM, Christoph Hellwig wrote:
> On Tue, Nov 08, 2011 at 04:41:40PM +0200, Avi Kivity wrote:
>> On 11/06/2011 03:35 AM, Alexander Graf wrote:
>> > To quickly get going, just execute the following as user:
>> >
>> > $ ./Documentation/run-qemu.sh -r / -a init=/bin/bash
On Tue, Nov 08, 2011 at 04:41:40PM +0200, Avi Kivity wrote:
> On 11/06/2011 03:35 AM, Alexander Graf wrote:
> > To quickly get going, just execute the following as user:
> >
> > $ ./Documentation/run-qemu.sh -r / -a init=/bin/bash
> >
> > This will drop you into a shell on your rootfs.
> >
>
>
On 11/07/2011 03:45 PM, Juan Quintela wrote:
Hi
Please send in any agenda items you are interested in covering.
Null agenda -> null call, hope to get some next week.
Thanks, Juan.
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majord...@vger.
Pekka,
On Fri, Nov 4, 2011 at 9:38 AM, Pekka Enberg wrote:
> ./kvm run
>
> We also support booting both raw images and QCOW2 images in read-only
> mode:
>
> ./kvm run -d debian_squeeze_amd64_standard.qcow2 -p "root=/dev/vda1"
>
I'm trying to use the kvm tool, but the virtio_blk userland se
On 11/06/2011 03:35 AM, Alexander Graf wrote:
> To quickly get going, just execute the following as user:
>
> $ ./Documentation/run-qemu.sh -r / -a init=/bin/bash
>
> This will drop you into a shell on your rootfs.
>
Doesn't work on Fedora 15. F15's qemu-kvm doesn't have -machine or
-virtfs.
Em Tue, Nov 08, 2011 at 02:40:42PM +0100, Gerd Hoffmann escreveu:
> > Indeed, documentation is lacking, I think coming from a kernel
> > standpoint I relied too much in the "documentation is source code"
> > mantra of old days.
> Sorry for the shameless plug, but as you are speaking of lacking
T
On Tue, 2011-11-08 at 16:18 +0200, Gleb Natapov wrote:
> On Tue, Nov 08, 2011 at 03:12:27PM +0100, Peter Zijlstra wrote:
> > On Tue, 2011-11-08 at 15:54 +0200, Gleb Natapov wrote:
> > > Isn't it better to introduce mapping between ebx bits and architectural
> > > events and do for_each_set_bit loop
On Tue, Nov 8, 2011 at 3:29 PM, Karel Zak wrote:
>> I don't know if it makes sense to merge the tools you've mentioned above.
>> My gut feeling is that it's probably not reasonable - there's already a
>> community working on it with their own development process and coding
>> style. I don't think
On Tue, Nov 08, 2011 at 03:12:27PM +0100, Peter Zijlstra wrote:
> On Tue, 2011-11-08 at 15:54 +0200, Gleb Natapov wrote:
> > Isn't it better to introduce mapping between ebx bits and architectural
> > events and do for_each_set_bit loop?
>
> Probably, but I only thought of that halfway through ;-)
On Tue, Nov 8, 2011 at 1:53 AM, Rusty Russell wrote:
> On Mon, 7 Nov 2011 23:14:14 +0200, "Michael S. Tsirkin"
> wrote:
>> On Mon, Nov 07, 2011 at 03:46:23PM +1030, Rusty Russell wrote:
>> > So far, the only three things make sense to have in a capability list:
>> > MSI-X, the upper 32 feature b
On Tue, 2011-11-08 at 15:54 +0200, Gleb Natapov wrote:
> Isn't it better to introduce mapping between ebx bits and architectural
> events and do for_each_set_bit loop?
Probably, but I only thought of that halfway through ;-)
> But I wouldn't want to introduce
> patch as below as part of this ser
On Tue, Nov 08, 2011 at 02:26:51PM +0100, Peter Zijlstra wrote:
> On Tue, 2011-11-08 at 14:49 +0200, Gleb Natapov wrote:
> > > It might make sense to introduce cpuid10_ebx or so, also I think the
> > cpuid10_ebx will have only one field though (event_mask).
> >
> > > At the very least add a full e
Hi,
> Indeed, documentation is lacking, I think coming from a kernel
> standpoint I relied too much in the "documentation is source code"
> mantra of old days.
Sorry for the shameless plug, but as you are speaking of lacking
documentation: Where the heck is the perf config file documented, oth
On Mon, Nov 07, 2011 at 03:12:28PM +0200, Pekka Enberg wrote:
> On Mon, Nov 7, 2011 at 2:47 PM, Ted Ts'o wrote:
> > I don't think perf should be used as a precendent that now argues that
> > any new kernel utility should be moved into the kernel sources. Does
> > it make sense to move all of moun
On Tue, 2011-11-08 at 14:49 +0200, Gleb Natapov wrote:
> > It might make sense to introduce cpuid10_ebx or so, also I think the
> cpuid10_ebx will have only one field though (event_mask).
>
> > At the very least add a full ebx iteration to disable unsupported events
> > in the intel-v1 case.
> I d
Em Tue, Nov 08, 2011 at 01:07:55PM +0100, Ingo Molnar escreveu:
> * Vince Weaver wrote:
> > as mentioned before I have my own perf_event test suite with 20+ tests.
> > http://web.eecs.utk.edu/~vweaver1/projects/perf-events/validation.html
> That should probably be moved into perf test. Arnaldo
* Peter Zijlstra wrote:
> On Tue, 2011-11-08 at 13:15 +0100, Ingo Molnar wrote:
> >
> > The one notable thing that isnt being tested in a natural way is
> > the 'group of events' abstraction - which, ironically, has been
> > added on the perfmon guys' insistence. No app beyond the PAPI
> > s
* Theodore Tso wrote:
>
> On Nov 8, 2011, at 4:32 AM, Ingo Molnar wrote:
> >
> > No ifs and when about it, these are the plain facts:
> >
> > - Better features, better ABIs: perf maintainers can enforce clean,
> > functional and usable tooling support *before* committing to an
> > ABI o
Em Tue, Nov 08, 2011 at 05:21:50AM -0500, Theodore Tso escreveu:
>
> On Nov 8, 2011, at 4:32 AM, Ingo Molnar wrote:
> >
> > No ifs and when about it, these are the plain facts:
> >
> > - Better features, better ABIs: perf maintainers can enforce clean,
> > functional and usable tooling suppor
On Mon, Nov 07, 2011 at 03:07:50PM +0100, Peter Zijlstra wrote:
> On Thu, 2011-11-03 at 14:33 +0200, Gleb Natapov wrote:
> > @@ -1580,6 +1580,8 @@ __init int intel_pmu_init(void)
> > x86_pmu.num_counters= eax.split.num_counters;
> > x86_pmu.cntval_bits = eax.
On Tue, 2011-11-08 at 13:15 +0100, Ingo Molnar wrote:
>
> The one notable thing that isnt being tested in a natural way is the
> 'group of events' abstraction - which, ironically, has been added on
> the perfmon guys' insistence. No app beyond the PAPI self-test makes
> actual use of it though,
* Pekka Enberg wrote:
> [...] There's an easy fix for this too: improve "perf test" to
> cover the cases you're intested in. While ABI spec would be a nice
> addition, it's not going to make compatibility problems magically
> go away.
Yes, exactly - 'perf test' has been written with that exa
* Vince Weaver wrote:
> On Mon, 7 Nov 2011, Ingo Molnar wrote:
> > I think we needed to do only one revert along the way in the past
> > two years, to fix an unintended ABI breakage in PowerTop.
> > Considering the total complexity of the perf ABI our
> > compatibility track record is *very*
On Tue, 8 Nov 2011, Frank Ch. Eigler wrote:
Almost: they demonstrate that those parts of the ABI that these
particular perf commands rely on have been impressively compatible.
Do you have any sort of ABI coverage measurement, to see what
parts of the ABI these perf commands do not use?
It's pre
* Peter Zijlstra wrote:
> The ABI yes, the tool no, the tool very much relies on some newer
> ABI parts. Supporting fallbacks isn't always possible/wanted.
Yeah, sure - and an older tool cannot possibly support newer features
either.
Thanks,
Ingo
--
To unsubscribe from this list: se
Hi -
On Tue, Nov 08, 2011 at 11:22:35AM +0100, Ingo Molnar wrote:
> [...] These examples show *PICTURE PERFECT* forwards ABI
> compatibility, using the ancient perf tool on a bleeding edge
> kernel. [...]
Almost: they demonstrate that those parts of the ABI that these
particular perf commands r
On Tue, 8 Nov 2011, Theodore Tso wrote:
We have the staging tree because it's a widely acknowledged belief that
kernel code in the tree tends to improve over time compared to code
that's sitting out of the tree. Are you disputing that belief?
Kernel code in the kernel source tree improves; bec
On Nov 8, 2011, at 6:20 AM, Pekka Enberg wrote:
> We have the staging tree because it's a widely acknowledged belief that
> kernel code in the tree tends to improve over time compared to code that's
> sitting out of the tree. Are you disputing that belief?
Kernel code in the kernel source tree
On Tue, 8 Nov 2011, Theodore Tso wrote:
It's great to hear that! But in that case, there's an experiment we
can't really run, which is if perf had been developed in a separate
tree, would it have been just as successful?
Experiment, eh?
We have the staging tree because it's a widely acknowl
On Nov 8, 2011, at 5:22 AM, Ingo Molnar wrote:
> We do even more than that, the perf ABI is fully backwards *and*
> forwards compatible: you can run older perf on newer ABIs and newer
> perf on older ABIs.
It's great to hear that! But in that case, there's an experiment we can't
really run,
On Tue, 2011-11-08 at 11:22 +0100, Ingo Molnar wrote:
>
> We do even more than that, the perf ABI is fully backwards *and*
> forwards compatible: you can run older perf on newer ABIs and newer
> perf on older ABIs.
The ABI yes, the tool no, the tool very much relies on some newer ABI
parts. Su
On Nov 8, 2011, at 4:32 AM, Ingo Molnar wrote:
>
> No ifs and when about it, these are the plain facts:
>
> - Better features, better ABIs: perf maintainers can enforce clean,
> functional and usable tooling support *before* committing to an
> ABI on the kernel side.
"We don't have to be
* Ted Ts'o wrote:
> I don't believe there's ever been any guarantee that "perf test"
> from version N of the kernel will always work on a version N+M of
> the kernel. Perhaps I am wrong, though. If that is a guarantee
> that the perf developers are willing to stand behind, or have
> already
Hi,
>>> Wouldn't it be better to have the subsystem vendor and device id be
>>> configurable, set the default to the qemu subsystem ids, and then set it
>>> to 8086: for < 1.0?
>>
>> I don't want this being fully configurable just for the snake of
>> backward compatibility with old qemu vers
On 11/08/2011 10:08 AM, Gerd Hoffmann wrote:
> On 11/07/11 17:00, Anthony Liguori wrote:
> > On 11/07/2011 09:33 AM, Gerd Hoffmann wrote:
> >> This patch removes the code lines which set the subsystem id for the
> >> emulated ac97 card to 8086:. Due to the device id being zero the
> >> subsyst
* Theodore Tso wrote:
> On Nov 7, 2011, at 5:19 PM, Anthony Liguori wrote:
>
> > The kernel ecosystem does not have to be limited to linux.git.
> > There could be a process to be a "kernel.org project" for
> > projects that fit a certain set of criteria. These projects
> > could all share
Hi!
OpenBSD 5.0/i386 throws a kernel panic when I try to
boot it inside a Linux KVM (host: vanilla 3.0.4,
openSUSE 11.4/x86_64) unter qemu-kvm 0.14.1 and 0.15.1.
Note that OpenBSD 4.9/i386 works.
The OpenBSD developers say:
"the virtual machine emulator you are using has a bug. it declares
a cp
On 11/07/11 17:00, Anthony Liguori wrote:
> On 11/07/2011 09:33 AM, Gerd Hoffmann wrote:
>> This patch removes the code lines which set the subsystem id for the
>> emulated ac97 card to 8086:. Due to the device id being zero the
>> subsystem id isn't vaild anyway. With the patch applied the s
88 matches
Mail list logo
