* oerg Roedel j...@8bytes.org wrote:
It can decide whether it exposes the files. Nor are there any security
issues to begin with.
I am not talking about security. [...]
You were talking about security, in the portion of your mail that you snipped
out, and which i replied to:
2.
* oerg Roedel j...@8bytes.org wrote:
On Sun, Mar 21, 2010 at 07:43:00PM +0100, Ingo Molnar wrote:
Having access to the actual executable files that include the symbols
achieves
precisely that - with the additional robustness that all this functionality
is
concentrated
* Avi Kivity a...@redhat.com wrote:
IMO the reason perf is more usable than oprofile has less to do with the
kernel/userspace boundary and more do to with effort and attention spent on
the userspace/user boundary.
[...]
If you are interested in the first-hand experience of the people who
* Avi Kivity a...@redhat.com wrote:
On 03/21/2010 10:37 PM, Ingo Molnar wrote:
That includes the guest kernel. If you can deploy a new kernel in the
guest, presumably you can deploy a userspace package.
Note that with perf we can instrument the guest with zero guest-kernel
* Avi Kivity a...@redhat.com wrote:
My 10+ years experience with kernel instrumentation solutions is that
kernel-driven, self-sufficient, robust, trustable, well-enumerated sources
of information work far better in practice.
What about line number information? And the source? Into
* Anthony Liguori anth...@codemonkey.ws wrote:
On 03/21/2010 04:54 PM, Ingo Molnar wrote:
* Avi Kivitya...@redhat.com wrote:
On 03/21/2010 10:55 PM, Ingo Molnar wrote:
Of course you could say the following:
' Thanks, I'll mark this for v2.6.36 integration. Note that we
* oerg Roedel j...@8bytes.org wrote:
On Sun, Mar 21, 2010 at 09:31:21PM +0100, Ingo Molnar wrote:
Lets see one example of that thought process in action: Oprofile.
Since you are talking so much about oProfile in this thread I think it is
important to mention that the problem
* Joerg Roedel j...@8bytes.org wrote:
On Mon, Mar 22, 2010 at 11:59:27AM +0100, Ingo Molnar wrote:
Best would be if you demonstrated any problems of the perf symbol lookup
code
you are aware of on the host side, as it has that exact design you are
criticising here. We are eager
* Avi Kivity a...@redhat.com wrote:
On 03/22/2010 01:14 PM, Ingo Molnar wrote:
I think we agree at last. Neither I nor my employer are interested in
running qemu as a desktop-on-desktop tool, therefore I don't invest any
effort in that direction, or require it from volunteers.
Obviously
* Daniel P. Berrange berra...@redhat.com wrote:
On Mon, Mar 22, 2010 at 02:31:49PM +0200, Pekka Enberg wrote:
On Mon, Mar 22, 2010 at 1:48 PM, Ingo Molnar mi...@elte.hu wrote:
What about line number information? ?And the source? ?Into the kernel
with
them as well?
Sigh. Please
* Daniel P. Berrange berra...@redhat.com wrote:
On Mon, Mar 22, 2010 at 01:54:40PM +0100, Ingo Molnar wrote:
* Daniel P. Berrange berra...@redhat.com wrote:
FYI, for offline guests, you can use libguestfs[1] to access change
files
inside the guest, and read-only access
* Richard W.M. Jones rjo...@redhat.com wrote:
On Mon, Mar 22, 2010 at 01:05:13PM +, Daniel P. Berrange wrote:
This is close to the way libguestfs already works. It boots QEMU/KVM
pointing
to a minimal stripped down appliance linux OS image, containing a small
agent
it talks to
* Richard W.M. Jones rjo...@redhat.com wrote:
On Mon, Mar 22, 2010 at 02:56:47PM +0100, Ingo Molnar wrote:
Just curious: any plans to extend this to include live read/write access as
well?
I.e. to have the 'agent' (guestfsd) running universally, so that
tools such as perf
* Avi Kivity a...@redhat.com wrote:
On 03/22/2010 01:39 PM, Ingo Molnar wrote:
Reality is, the server space never was and never will be self-sustaining
in the long run (as Novell has found it out with Netware), it is the
desktop that dictates future markets. This is why i find your
* Avi Kivity a...@redhat.com wrote:
On 03/22/2010 02:44 PM, Ingo Molnar wrote:
This is why i consider that line of argument rather dishonest ...
I am not going to reply to any more email from you on this thread.
Because i pointed out that i consider a line of argument intellectually
* Avi Kivity a...@redhat.com wrote:
On 03/22/2010 01:23 PM, Ingo Molnar wrote:
* Avi Kivitya...@redhat.com wrote:
IMO the reason perf is more usable than oprofile has less to do with the
kernel/userspace boundary and more do to with effort and attention spent on
the userspace/user
* Pekka Enberg penb...@cs.helsinki.fi wrote:
Hi Avi,
On Mon, Mar 22, 2010 at 2:49 PM, Avi Kivity a...@redhat.com wrote:
Seems like perf is also split, with sysprof being developed outside the
kernel. ?Will you bring sysprof into the kernel? ?Will every feature be
duplicated in prof and
* Anthony Liguori anth...@codemonkey.ws wrote:
[...]
I've been trying very hard to turn this into a productive thread attempting
to capture your feedback and give clear suggestions about how you can solve
achieve your desired functionality.
I'm glad that we are at this more productive
* Avi Kivity a...@redhat.com wrote:
On 03/22/2010 04:32 PM, Ingo Molnar wrote:
* Avi Kivitya...@redhat.com wrote:
On 03/22/2010 02:44 PM, Ingo Molnar wrote:
This is why i consider that line of argument rather dishonest ...
I am not going to reply to any more email from you on this thread
.
On Mon, Mar 22, 2010 at 01:22:28PM +0100, Ingo Molnar wrote:
* Joerg Roedel j...@8bytes.org wrote:
[...] Basically the reason of the oProfile failure is a disfunctional
community. [...]
Caused by: repository separation and the inevitable code and social fork a
decade later
* Avi Kivity a...@redhat.com wrote:
The crux of the problem is very simple. To quote my earlier mail:
|
| - The inconvenience of having to type:
| perf kvm --host --guest
--guestkallsyms=/home/ymzhang/guest/kallsyms \
|
* Anthony Liguori anth...@codemonkey.ws wrote:
On 03/22/2010 10:55 AM, Ingo Molnar wrote:
* Anthony Liguorianth...@codemonkey.ws wrote:
[...]
I've been trying very hard to turn this into a productive thread attempting
to capture your feedback and give clear suggestions about how you
* Anthony Liguori anth...@codemonkey.ws wrote:
- Easy default reference to guest instances, and a way for tools to
reference them symbolically as well in the multi-guest case. Preferably
something trustable and kernel-provided - not some indirect information
like a PID file
* Avi Kivity a...@redhat.com wrote:
- Easy default reference to guest instances, and a way for tools to
reference them symbolically as well in the multi-guest case. Preferably
something trustable and kernel-provided - not some indirect information
like a PID file created by
* Avi Kivity a...@redhat.com wrote:
On 03/22/2010 07:27 PM, Pekka Enberg wrote:
It's kinda funny to see people argue that having an external repository is
not a problem and that it's not a big deal if building something from the
repository is slightly painful as long as it doesn't
* Pekka Enberg penb...@cs.helsinki.fi wrote:
Hi Frank,
On Mon, Mar 22, 2010 at 7:17 PM, Frank Ch. Eigler f...@redhat.com wrote:
In your very previous paragraphs, you enumerate two separate causes:
repository structure and development/maintenance process as being
sources of fun. ?Please
* Avi Kivity a...@redhat.com wrote:
On 03/22/2010 06:32 PM, Ingo Molnar wrote:
So, what do you think creates code communities and keeps them alive?
Developers and code. And the wellbeing of developers are primarily
influenced by the repository structure and by the development
* Avi Kivity a...@redhat.com wrote:
Lets look at the ${HOME}/.qemu/qmp/ enumeration method suggested by
Anthony. There's numerous ways that this can break:
I don't like it either. We have libvirt for enumerating guests.
Which has pretty much the same problems to the ${HOME}/.qemu/qmp/
* Anthony Liguori anth...@codemonkey.ws wrote:
On 03/22/2010 12:34 PM, Ingo Molnar wrote:
* Avi Kivitya...@redhat.com wrote:
- Easy default reference to guest instances, and a way for tools to
reference them symbolically as well in the multi-guest case.
Preferably
something
* Anthony Liguori anth...@codemonkey.ws wrote:
On 03/22/2010 12:34 PM, Ingo Molnar wrote:
This is really just the much-discredited microkernel approach for keeping
global enumeration data that should be kept by the kernel ...
Lets look at the ${HOME}/.qemu/qmp/ enumeration method suggested
* Joerg Roedel j...@8bytes.org wrote:
On Mon, Mar 22, 2010 at 05:32:15PM +0100, Ingo Molnar wrote:
I dont know how you can find the situation of Alpha comparable, which is a
legacy architecture for which no new CPU was manufactored in the past ~10
years.
The negative effects
* Alexander Graf ag...@suse.de wrote:
Yes. I think the point was that every layer in between brings potential
slowdown and loss of features.
Exactly. The more 'fragmented' a project is into sub-projects, without a
single, unified, functional reference implementation in the center of it, the
* Alexander Graf ag...@suse.de wrote:
Furthermore, another negative effect is that many times features are
implemented not in their technically best way, but in a way to keep them
local to the project that originates them. This is done to keep deployment
latencies and general
* Avi Kivity a...@redhat.com wrote:
I think you didnt understand my point. I am talking about 'perf kvm top'
hanging if Qemu hangs.
Use non-blocking I/O, report that guest as dead. No point in profiling it,
it isn't making any progress.
Erm, at what point do i decide that a guest is
* Anthony Liguori anth...@codemonkey.ws wrote:
On 03/22/2010 02:22 PM, Ingo Molnar wrote:
Transitive had a product that was using a KVM context to run their
binary translator which allowed them full access to the host
processes virtual address space range. In this case, there is no
kernel
* Avi Kivity a...@redhat.com wrote:
On 03/22/2010 09:22 PM, Ingo Molnar wrote:
Transitive had a product that was using a KVM context to run their binary
translator which allowed them full access to the host processes virtual
address space range. In this case, there is no kernel
* Avi Kivity a...@redhat.com wrote:
On 03/22/2010 09:27 PM, Ingo Molnar wrote:
If your position basically boils down to, we can't trust userspace
and we can always trust the kernel, I want to eliminate any
userspace path, then I can't really help you out.
Why would you want to 'help
* Avi Kivity a...@redhat.com wrote:
On 04/14/2030 12:05 PM, Zhang, Yanmin wrote:
Here is the new patch of V3 against tip/master of April 13th
if anyone wants to try it.
Thanks for persisting despite the flames.
Can you please separate arch/x86/kvm part of the patch? That will make
* Avi Kivity a...@redhat.com wrote:
On 04/17/2010 10:13 PM, Ingo Molnar wrote:
* Avi Kivitya...@redhat.com wrote:
On 04/16/2010 10:34 AM, Zhang, Yanmin wrote:
Below is the kernel patch to enable perf to collect guest os statistics.
Joerg,
Would you like to add support on svm? I
* Zhang, Yanmin yanmin_zh...@linux.intel.com wrote:
Here is the new patch of V5 against tip/master of April 17th if anyone wants
to try it.
Ok, this looks pretty good from the perf angle - so once Avi likes patches #1
and #2 and creates a pullable branch we can apply #3 as well to
FYI, i found a few problems that need fixing:
+ unsigned long ip;
+ if (perf_guest_cbs perf_guest_cbs-is_in_guest())
missing newline.
+ int misc = 0;
+ if (perf_guest_cbs perf_guest_cbs-is_in_guest()) {
ditto.
+ PERF_RECORD_MISC_GUEST_KERNEL;
+
* Zhang, Yanmin yanmin_zh...@linux.intel.com wrote:
unsigned long perf_misc_flags(struct pt_regs *regs)
{
int misc = 0;
+
if (perf_guest_cbs perf_guest_cbs-is_in_guest()) {
+ if (perf_guest_cbs-is_user_mode())
+ misc |=
* Ingo Molnar mi...@elte.hu wrote:
* Zhang, Yanmin yanmin_zh...@linux.intel.com wrote:
unsigned long perf_misc_flags(struct pt_regs *regs)
{
int misc = 0;
+
if (perf_guest_cbs perf_guest_cbs-is_in_guest()) {
+ if (perf_guest_cbs-is_user_mode
* Avi Kivity a...@redhat.com wrote:
On 09/19/2009 09:40 AM, Avi Kivity wrote:
Add a general per-cpu notifier that is called whenever the kernel is
about to return to userspace. The notifier uses a thread_info flag
and existing checks, so there is no impact on user return or context
switch
* Avi Kivity a...@redhat.com wrote:
When CONFIG_USER_RETURN_NOTIFIER is set, we need to link
kernel/user-return-notifier.o.
Signed-off-by: Avi Kivity a...@redhat.com
---
kernel/Makefile |1 +
1 files changed, 1 insertions(+), 0 deletions(-)
Applied, thanks.
I suspect you want to
* Gleb Natapov g...@redhat.com wrote:
diff --git a/arch/x86/mm/fault.c b/arch/x86/mm/fault.c
index f4cee90..14707dc 100644
--- a/arch/x86/mm/fault.c
+++ b/arch/x86/mm/fault.c
@@ -952,6 +952,9 @@ do_page_fault(struct pt_regs *regs, unsigned long
error_code)
int write;
int
* Gleb Natapov g...@redhat.com wrote:
Signed-off-by: Gleb Natapov g...@redhat.com
---
arch/x86/mm/gup.c |2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/arch/x86/mm/gup.c b/arch/x86/mm/gup.c
index 71da1bc..cea0dfe 100644
--- a/arch/x86/mm/gup.c
+++
* Gleb Natapov g...@redhat.com wrote:
Do not preempt kernel. Just maintain counter to know if task can sleep.
Signed-off-by: Gleb Natapov g...@redhat.com
---
include/linux/hardirq.h |6 ++
include/linux/preempt.h | 22 --
kernel/sched.c |6
* Gleb Natapov g...@redhat.com wrote:
On Mon, Nov 02, 2009 at 10:22:14AM +0100, Ingo Molnar wrote:
* Gleb Natapov g...@redhat.com wrote:
diff --git a/arch/x86/mm/fault.c b/arch/x86/mm/fault.c
index f4cee90..14707dc 100644
--- a/arch/x86/mm/fault.c
+++ b/arch/x86/mm/fault.c
* Gleb Natapov g...@redhat.com wrote:
On Mon, Nov 02, 2009 at 05:12:48PM +0100, Ingo Molnar wrote:
* Gleb Natapov g...@redhat.com wrote:
On Mon, Nov 02, 2009 at 10:22:14AM +0100, Ingo Molnar wrote:
* Gleb Natapov g...@redhat.com wrote:
diff --git a/arch/x86/mm
* Gleb Natapov g...@redhat.com wrote:
On Mon, Nov 02, 2009 at 05:29:41PM +0100, Ingo Molnar wrote:
* Gleb Natapov g...@redhat.com wrote:
On Mon, Nov 02, 2009 at 05:12:48PM +0100, Ingo Molnar wrote:
* Gleb Natapov g...@redhat.com wrote:
On Mon, Nov 02, 2009 at 10:22
* Avi Kivity a...@redhat.com wrote:
On 11/08/2009 01:36 PM, Ingo Molnar wrote:
Three existing callbacks are: kmemcheck, mmiotrace, notifier. Two
of them kmemcheck, mmiotrace are enabled only for debugging, should
not be performance concern. And notifier call sites (two of them
* Avi Kivity a...@redhat.com wrote:
On 11/08/2009 02:51 PM, Ingo Molnar wrote:
Maybe we should generalize paravirt-ops patching in case if (x) f() is
deemed too expensive.
Yes, that's a nice idea. We have quite a number of 'conditional
callbacks' in various critical paths that could be made
* H. Peter Anvin h...@zytor.com wrote:
On 11/08/2009 04:51 AM, Ingo Molnar wrote:
* Avi Kivity a...@redhat.com wrote:
On 11/08/2009 01:36 PM, Ingo Molnar wrote:
Three existing callbacks are: kmemcheck, mmiotrace, notifier. Two
of them kmemcheck, mmiotrace are enabled only
* Gregory Haskins gregory.hask...@gmail.com wrote:
Hi Linus,
Please pull AlacrityVM guest support for 2.6.33 from:
git://git.kernel.org/pub/scm/linux/kernel/git/ghaskins/alacrityvm/linux-2.6.git
for-linus
All of these patches have stewed in linux-next for quite a while now:
Gregory
* Gregory Haskins gregory.hask...@gmail.com wrote:
On 12/18/09 4:51 PM, Ingo Molnar wrote:
* Gregory Haskins gregory.hask...@gmail.com wrote:
Hi Linus,
Please pull AlacrityVM guest support for 2.6.33 from:
git://git.kernel.org/pub/scm/linux/kernel/git/ghaskins/alacrityvm/linux
* Anthony Liguori anth...@codemonkey.ws wrote:
On 12/22/2009 10:01 AM, Bartlomiej Zolnierkiewicz wrote:
new e1000 driver is more superior in architecture and do the required
work to make the new e1000 driver a full replacement for the old one.
Right, like everyone actually does things this
* Andi Kleen a...@firstfloor.org wrote:
- Are a pure software concept and any compatibility mismatch is
self-inflicted. The patches are in fact breaking the ABI to KVM
In practice, especially
33a37eb411d193851c334060780ab834ba534292
Author: Ingo Molnar [EMAIL PROTECTED]
Date: Mon Jul 21 10:57:15 2008 +0200
KVM: fix exception entry / build bug, on 64-bit
-tip testing found this build bug:
arch/x86/kvm/built-in.o:(.text.fixup+0x1): relocation truncated to fit:
R_X86_64_32 against `.text
on emergency reboot.
looks good to me - i was bitten by that problem on a testbox.
Acked-by: Ingo Molnar [EMAIL PROTECTED]
Seems best to merge this via the KVM tree, right?
Ingo
--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to [EMAIL PROTECTED]
More
* Avi Kivity [EMAIL PROTECTED] wrote:
Ingo Molnar wrote:
* Avi Kivity [EMAIL PROTECTED] wrote:
Enabling Intel VT has the curious side effect whereby the INIT signal
is blocked. Rather than comment on the wisdom of this side effect,
this patch adds an emergency restart reboot
* Avi Kivity [EMAIL PROTECTED] wrote:
reboot was always a bit fragile - i think we should only do that if
we find a box where the FADT reset works better than the first-wave
approaches we try.
It worked on my host. Since it will fall back to keyboard reset and
triple fault, it seems
* Avi Kivity [EMAIL PROTECTED] wrote:
Triple-fault and keyboard reset may assert INIT instead of RESET;
however INIT is blocked when Intel VT is enabled. This leads to a
partially reset machine when invoking emergency_restart via sysrq-b:
the processor is still working but other parts of
* Frans Meulenbroeks [EMAIL PROTECTED] wrote:
2008/8/26 Avi Kivity [EMAIL PROTECTED]:
It seems excessive. Most machines will hardly run without acpi.
Well, I'm fairly sure that most of the systems running linux (or some
variant like uclinux), do not support acpi.
Linux is used a
* Avi Kivity [EMAIL PROTECTED] wrote:
Peter Zijlstra wrote:
Avi, the below fixes it for me..
For me too. Thanks!
applied to tip/sched/urgent - thanks!
Ingo
--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to [EMAIL PROTECTED]
More
* Muli Ben-Yehuda [EMAIL PROTECTED] wrote:
+static int calgary_device_supported(struct device *dev)
+{
+ return translation_enabled(find_iommu_table(dev));
+}
Sure, but I prefer the explicit form since it lends itself to easier
debugging (oops line numbers, adding printks, etc.).
* Yu Zhao [EMAIL PROTECTED] wrote:
+static char *pci_assign_pio;
+static char *pci_assign_mmio;
+
+static int pcibios_bus_resource_needs_fixup(struct pci_bus *bus)
+{
+ int i;
+ int type = 0;
+ int domain, busnr;
+
+ if (!bus-self)
+ return 0;
+
+ for
* Avi Kivity [EMAIL PROTECTED] wrote:
Eduardo Habkost wrote:
Hi,
This is a new version of the series to disabling virtualization on kdump,
now extended to do the same tricks on emergency_restart() if needed.
Looks good. If you me to push it upstream, I'll need kexec/kdump
acks.
* Eduardo Habkost [EMAIL PROTECTED] wrote:
On Thu, Nov 06, 2008 at 08:14:45AM +0100, Ingo Molnar wrote:
* Eduardo Habkost [EMAIL PROTECTED] wrote:
This reverts commit c7ffa6c26277b403920e2255d10df849bd613380.
Now that we have the hooks to disable virtualization
* Ingo Molnar [EMAIL PROTECTED] wrote:
Andrey Borzenkov's patch, for example, adds a new DMI entry
because reboot=acpi breaks his keyboard (even without KVM, I
guess). Andrey, was that the case?
hm, IIRC the problem was KVM in his case too.
actually, Andrey's problem seems
* Eduardo Habkost [EMAIL PROTECTED] wrote:
Hi, Ingo,
As tip/master is a moving target, I am splitting the previous
kdump/reboot virtualization-disable code series[1] into smaller
series so the simpler parts can be included sooner. This first
series is just for making
* Eduardo Habkost [EMAIL PROTECTED] wrote:
Hi, Ingo,
This is yet another spin of the series to disable vmx on kdump and
on emergency_restart, after some feedback from Avi.
this is going to interact with the KVM tree, wont it?
i think the best way forward would be to keep your changes in
* Avi Kivity [EMAIL PROTECTED] wrote:
Ingo Molnar wrote:
* Eduardo Habkost [EMAIL PROTECTED] wrote:
Hi, Ingo,
This is yet another spin of the series to disable vmx on kdump and
on emergency_restart, after some feedback from Avi.
this is going to interact with the KVM tree
* Mathieu Desnoyers [EMAIL PROTECTED] wrote:
* Wu Fengguang ([EMAIL PROTECTED]) wrote:
On Thu, Nov 27, 2008 at 10:00:03AM +0200, Mathieu Desnoyers wrote:
* Wu Fengguang ([EMAIL PROTECTED]) wrote:
+
+marker_synchronize_unregister() must be called before the first
occurrence of
* Avi Kivity a...@redhat.com wrote:
I would like to remove this limitation. I see several ways to go about
it:
1. Drop the use of IST
This would reduce the (perceived) reliability of the kernel and would
probably not be welcomed.
hpa/Ingo, any opinions?
i think we should actually do
* Avi Kivity a...@redhat.com wrote:
Ingo Molnar wrote:
i think we should actually do #1 unconditionally.
ISTs are bad for the native kernel too. They have various nasty
complications in the stack walker (and hence they _reduce_ reliability
in practice), and they are non-preemptible
* Ingo Molnar mi...@elte.hu wrote:
i'd suggest to reuse the irq-stacks for this. Right now on 64-bit we've
got the following stack layout: 8K process stacks, a 16K IRQ stack on
each CPU, shared by all IRQs. Then we have the IST stacks with weird
sizes: debug:8K, the others: 4K.
this has
* Avi Kivity a...@redhat.com wrote:
Ingo Molnar wrote:
* Ingo Molnar mi...@elte.hu wrote:
i'd suggest to reuse the irq-stacks for this. Right now on 64-bit
we've got the following stack layout: 8K process stacks, a 16K IRQ
stack on each CPU, shared by all IRQs. Then we have the IST
* Avi Kivity a...@redhat.com wrote:
Ingo Molnar wrote:
I think it's enough to switch %rsp before incrementing irqcount, no?
no - that would introduce a small race: if an exception (say an NMI or
MCE, or a debug trap) happens in that small window then the exception
context thinks
* Avi Kivity a...@redhat.com wrote:
The interrupt stack table (IST) mechanism is the only thing preventing
kvm from deferring saving and reloading of some significant state. It
is also somewhat complicated.
Remove it by switching the special exceptions to use the normal irqstack.
Avi
* Avi Kivity a...@redhat.com wrote:
The interrupt stack table (IST) mechanism is the only thing preventing
kvm from deferring saving and reloading of some significant state. It
is also somewhat complicated.
Remove it by switching the special exceptions to use the normal irqstack.
* Ingo Molnar mi...@elte.hu wrote:
They have the following commit IDs, and they are also in tip/master:
921e521: x86: move NMI back to interrupt stack
36ef6c9: x86: make interrupt stack switching atomic
dd64891: x86: consolidate irq stack switching to a single macro
955a368: x86: drop
syscore_ops for suspend/resume.
[5/6] - Make cpufreq use struct syscore_ops for boot CPU suspend/resume.
[6/6] - Introduce config switch allowing architectures to skip sysdev
suspend/resume/shutdown code.
The x86 bits look fine.
Acked-by: Ingo Molnar mi...@elte.hu
The patches affect a lot
* Anthony Liguori anth...@codemonkey.ws wrote:
On 03/31/2011 12:30 PM, Pekka Enberg wrote:
Hi all,
We’re proud to announce the native Linux KVM tool!
Neat!
As something of a lesson of history, I'd suggest picking a more unique name
while it's still a prototype :-)
I disagree, i
* Pekka Enberg penb...@kernel.org wrote:
Well, this is bound to cause confusion as the tool is yet quite immature.
Yes, that's really unfortunate. I don't care too much what we call the tool
but I definitely agree with Ingo that 'kvm' is more discoverable to users.
Any suggestions?
* Avi Kivity a...@redhat.com wrote:
Sure, any succcesful project becomes an ugly gooball. It's almost a
compliment.
I disagree strongly with that sentiment and there's several good counter
examples:
- the Git project is also highly successful and is kept very clean (and has a
project
* Gleb Natapov g...@redhat.com wrote:
On Wed, Apr 06, 2011 at 11:33:33AM +0200, Ingo Molnar wrote:
So no, your kind of cynical, defeatist sentiment about code quality is by
no means true in my experience. Projects become ugly gooballs once
maintainers stop caring enough.
In case
* Olivier Galibert galib...@pobox.com wrote:
On Wed, Apr 06, 2011 at 11:33:33AM +0200, Ingo Molnar wrote:
Examples: X11 and GCC - both were struggling for years to break through
magic
invisible barriers of growth and IMHO a lot of it had to do with the lack
of
code
* Prasad Joshi prasadjoshi...@gmail.com wrote:
- kvm-cmd.h: Adds a new structure cmd_struct to create a table of commands
and callback function.
- kvm-cmd.c: implements two main functions for command processing.
kvm_get_command(): searches table for specific command.
* Pekka Enberg penb...@kernel.org wrote:
On 04/07/11 13:47, Prasad Joshi wrote:
- parse-options.[ch] has argument processing code.
- types.h: Additional types for argument processing.
- strbuf.[ch]: Added a function prefixcmp to compare string prefix
On Thu, 2011-04-07 at
* Pekka Enberg penb...@kernel.org wrote:
On Thu, 2011-04-07 at 23:33 +0100, Prasad Joshi wrote:
On Thu, Apr 7, 2011 at 9:14 PM, Ingo Molnar mi...@elte.hu wrote:
* Prasad Joshi prasadjoshi...@gmail.com wrote:
- kvm-cmd.h: Adds a new structure cmd_struct to create a table
: No such device' to:
Fatal, could not open /dev/kvm: No such device
... should there be any future error returns that are neither -ENOENT,
nor -ENODEV.
Signed-off-by: Ingo Molnar mi...@elte.hu
---
tools/kvm/kvm.c |6 +-
1 files changed, 5 insertions(+), 1 deletions(-)
diff --git a/tools/kvm/kvm.c
fault.
disk_image__close (self=0x0) at disk-image.c:93
93if (self-ops-close)
(gdb)
Because disk_image__close() assumes that 'self' is never NULL.
Add a NULL check to allow a clean exit.
Signed-off-by: Ingo Molnar mi...@elte.hu
---
tools/kvm/disk-image.c |4
1 files
This delimits the kernel output properly and gives feedback to the user
that (despite the scary kernel messages) all fine from the KVM POV.
Signed-off-by: Ingo Molnar mi...@elte.hu
---
tools/kvm/main.c |2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/tools/kvm/main.c b/tools
* Andrea Arcangeli aarca...@redhat.com wrote:
[...] I thought the whole point of a native kvm tool was to go all the
paravirt way to provide max performance and maybe also depend on vhost as
much as possible.
To me it's more than that: today i can use it to minimally boot test various
- this necessiates the use of
the sane Linux definition of u64 instead of the brain-dead int64_t
variant.
That also allows (and necessiates) the removal of the ugly PRIu64 format
string hackery. Friends don't let friends use PRI* hackeries! :-)
Signed-off-by: Ingo Molnar mi...@elte.hu
---
tools/kvm
* Pekka Enberg penb...@kernel.org wrote:
In preparation for threaded execution model, this patch introduces a KVM VCPU
data structure 'struct kvm_cpu'.
Cc: Asias He asias.he...@gmail.com
Cc: Cyrill Gorcunov gorcu...@gmail.com
Cc: Ingo Molnar mi...@elte.hu
Signed-off-by: Pekka Enberg penb
* Ingo Molnar mi...@elte.hu wrote:
This commit causes a segfault for 'kvm run bzImage':
Weird - i tried to debug it, then the bug went away. I'm using the same sha1
now as before, but the crash does not trigger. Very weird.
But this definitely started triggering today and never triggered
* Cyrill Gorcunov gorcu...@gmail.com wrote:
On 04/09/2011 03:59 PM, Ingo Molnar wrote:
* Pekka Enberg penb...@kernel.org wrote:
In preparation for threaded execution model, this patch introduces a KVM
VCPU
data structure 'struct kvm_cpu'.
Cc: Asias He asias.he...@gmail.com
* Pekka Enberg penb...@kernel.org wrote:
On Sat, 9 Apr 2011, Ingo Molnar wrote:
Weird - i tried to debug it, then the bug went away. I'm using the same sha1
now as before, but the crash does not trigger. Very weird.
But this definitely started triggering today and never triggered before
1 - 100 of 617 matches
Mail list logo
