On 07/04/2011 08:34 AM, Paolo Bonzini wrote:
On 07/04/2011 08:13 AM, Hannes Reinecke wrote:
On 07/03/2011 04:36 PM, Paolo Bonzini wrote:
On 07/02/2011 03:50 PM, Hannes Reinecke wrote:
(And no, I will not getting into another dog-fight with Paul B.
here.
Virtio can do without bounce buffers. AH
On Sun, 3 Jul 2011 15:11:37 +0300, "Michael S. Tsirkin" wrote:
> On Sun, Jul 03, 2011 at 01:52:29PM +0300, Sasha Levin wrote:
> > This just leads me to believe that we should either not notify the host,
> > or not wait_for_completion() when telling the host.
>
> Interesting. The spec says
>
> (a
Hi
Please send in any agenda items you are interested in covering.
Later, Juan.
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
On 07/02/2011 06:14 PM, Stefan Hajnoczi wrote:
On Fri, Jul 1, 2011 at 4:35 PM, Hannes Reinecke wrote:
+static void megasas_mmio_writel(void *opaque, target_phys_addr_t addr,
+uint32_t val)
+{
+MPTState *s = opaque;
+target_phys_addr_t frame_addr;
+uin
* Alexander Graf wrote:
> >> I don't see how it would. Once you overrun device buffers, you
> >> have to do something. Either you drop packets or you stall the
> >> guest. I'd usually prefer the former :).
> >
> > What scenario do you see where we'd have to drop packets?
> >
> > When the gue
On 04.07.2011, at 11:11, Ingo Molnar wrote:
>
> * Alexander Graf wrote:
>
I don't see how it would. Once you overrun device buffers, you
have to do something. Either you drop packets or you stall the
guest. I'd usually prefer the former :).
>>>
>>> What scenario do you see wh
* Alexander Graf wrote:
>
> On 04.07.2011, at 11:11, Ingo Molnar wrote:
>
> >
> > * Alexander Graf wrote:
> >
> I don't see how it would. Once you overrun device buffers, you
> have to do something. Either you drop packets or you stall the
> guest. I'd usually prefer the fo
On 07/03/2011 08:44 PM, Sasha Levin wrote:
On Sun, 2011-07-03 at 20:16 +0300, Avi Kivity wrote:
> On 07/03/2011 08:04 PM, Sasha Levin wrote:
> > The new flag allows passing a write side of a pipe instead of an
> > eventfd to be notified of writes to the specified memory region.
> >
> > In
On 07/04/2011 09:26 AM, Hannes Reinecke wrote:
Cool.
Exactly what I need.
FWIW, feel free to add my 'Acked-by' to it.
Any chance of getting them included?
I'm not very tied to pvscsi; I just needed an HBA that is not a joke by
modern standards :) to play with the SCSI layer. There may be
On Sun, Jul 03, 2011 at 08:04:49PM +0300, Sasha Levin wrote:
> The new flag allows passing a write side of a pipe instead of an
> eventfd to be notified of writes to the specified memory region.
>
> Instead of signaling an event, the value written to the memory region
> is written to the pipe.
>
On Sun, Jul 03, 2011 at 08:31:11PM +0200, Bernhard Held wrote:
> SYS_eventfd2 is not defined on systems with old glibc. These numbers
> are working for me, for 32 and 64 bit linux. What means
> "__NR_eventfd2 does seem to exit"?
My system seems to have a definition for the 64 bit
_NR_eventfd2 in u
On 07/04/2011 01:32 PM, Michael S. Tsirkin wrote:
On Sun, Jul 03, 2011 at 08:04:49PM +0300, Sasha Levin wrote:
> The new flag allows passing a write side of a pipe instead of an
> eventfd to be notified of writes to the specified memory region.
>
> Instead of signaling an event, the value writ
On Mon, Jul 04, 2011 at 01:27:45PM +0300, Avi Kivity wrote:
> I'd like to be able to forward an entire PCI BAR
> over a pipe. That means sending the address/data/length tuple, and
> both read and write support.
>
> >> Is the write guaranteed atomic? We probably need serialization here.
> >
> >a
On 07/04/2011 01:49 PM, Michael S. Tsirkin wrote:
On Mon, Jul 04, 2011 at 01:27:45PM +0300, Avi Kivity wrote:
> I'd like to be able to forward an entire PCI BAR
> over a pipe. That means sending the address/data/length tuple, and
> both read and write support.
>
> >> Is the write guarantee
On 03.07.2011, at 11:12, Avi Kivity wrote:
> On 07/03/2011 12:09 PM, Alexander Graf wrote:
>> >
>> > Right. The idea is that if KVM_FLAG_BLAH implies a field
>> > kvm_struct::blah, then either both are present in the headers, or none of
>> > them.
>>
>> Yup, makes sense. I like the idea :).
On Mon, Jul 04, 2011 at 01:45:07PM +0300, Avi Kivity wrote:
> On 07/04/2011 01:32 PM, Michael S. Tsirkin wrote:
> >On Sun, Jul 03, 2011 at 08:04:49PM +0300, Sasha Levin wrote:
> >> The new flag allows passing a write side of a pipe instead of an
> >> eventfd to be notified of writes to the specif
On 07/04/2011 02:07 PM, Michael S. Tsirkin wrote:
On Mon, Jul 04, 2011 at 01:45:07PM +0300, Avi Kivity wrote:
> On 07/04/2011 01:32 PM, Michael S. Tsirkin wrote:
> >On Sun, Jul 03, 2011 at 08:04:49PM +0300, Sasha Levin wrote:
> >> The new flag allows passing a write side of a pipe instead of
On 07/04/2011 01:59 PM, Alexander Graf wrote:
On 03.07.2011, at 11:12, Avi Kivity wrote:
> On 07/03/2011 12:09 PM, Alexander Graf wrote:
>> >
>> > Right. The idea is that if KVM_FLAG_BLAH implies a field
kvm_struct::blah, then either both are present in the headers, or none of them.
>>
>
On 04.07.2011, at 13:22, Avi Kivity wrote:
> On 07/04/2011 01:59 PM, Alexander Graf wrote:
>> On 03.07.2011, at 11:12, Avi Kivity wrote:
>>
>> > On 07/03/2011 12:09 PM, Alexander Graf wrote:
>> >> >
>> >> > Right. The idea is that if KVM_FLAG_BLAH implies a field
>> >> kvm_struct::blah, t
On 07/04/2011 02:36 PM, Alexander Graf wrote:
>
> What intermediate steps? We can't add fields to the structure before we get
the extensibility infrastructure, but that's all.
If we add it now without extensibility code, we will have a kernel that only knows the
ioctl with the size as it is
On 04.07.2011, at 13:37, Avi Kivity wrote:
> On 07/04/2011 02:36 PM, Alexander Graf wrote:
>> >
>> > What intermediate steps? We can't add fields to the structure before we
>> > get the extensibility infrastructure, but that's all.
>>
>> If we add it now without extensibility code, we will ha
On Mon, Jul 04, 2011 at 02:19:39PM +0300, Avi Kivity wrote:
> >Also noting that the fd can be set not to block, or that
> >a signal can interrupt the write. Both cases are not errors.
>
> One thing we can do is return via the normal KVM_EXIT_MMIO method
> and hope userspace knows how to handle thi
On 07/04/2011 02:45 PM, Michael S. Tsirkin wrote:
On Mon, Jul 04, 2011 at 02:19:39PM +0300, Avi Kivity wrote:
> >Also noting that the fd can be set not to block, or that
> >a signal can interrupt the write. Both cases are not errors.
>
> One thing we can do is return via the normal KVM_EXIT_MM
On Fri, Jul 01, 2011 at 11:37:42AM -0700, Dave Hansen wrote:
> On Wed, 2011-06-29 at 20:21 +1000, Paul Mackerras wrote:
> > +struct kvmppc_pginfo {
> > + unsigned long pfn;
> > + atomic_t refcnt;
> > +};
>
> I only see this refcnt inc'd in one spot and never decremented or read.
> Is the refc
On Mon, Jul 04, 2011 at 02:49:23PM +0300, Avi Kivity wrote:
> On 07/04/2011 02:45 PM, Michael S. Tsirkin wrote:
> >On Mon, Jul 04, 2011 at 02:19:39PM +0300, Avi Kivity wrote:
> >> >Also noting that the fd can be set not to block, or that
> >> >a signal can interrupt the write. Both cases are not
Am 04.07.2011 12:37, schrieb Michael S. Tsirkin:
On Sun, Jul 03, 2011 at 08:31:11PM +0200, Bernhard Held wrote:
SYS_eventfd2 is not defined on systems with old glibc. These numbers
are working for me, for 32 and 64 bit linux. What means
"__NR_eventfd2 does seem to exit"?
My system seems to hav
On 07/04/2011 12:29 PM, Paolo Bonzini wrote:
On 07/04/2011 09:26 AM, Hannes Reinecke wrote:
Cool.
Exactly what I need.
FWIW, feel free to add my 'Acked-by' to it.
Any chance of getting them included?
I'm not very tied to pvscsi; I just needed an HBA that is not a joke
by modern standards :
On 07/04/2011 02:52 PM, Hannes Reinecke wrote:
However, I probably will see to fixup the megasas emulation with the
current infrastructure, get that in, and then move over to the iovec
infrastructure.
Makes sense also for ease of review.
But if you promise to merge the iovec infrastructure I'
On Mon, Jul 04, 2011 at 02:13:36PM +0200, Bernhard Held wrote:
> Am 04.07.2011 12:37, schrieb Michael S. Tsirkin:
> >On Sun, Jul 03, 2011 at 08:31:11PM +0200, Bernhard Held wrote:
> >>SYS_eventfd2 is not defined on systems with old glibc. These numbers
> >>are working for me, for 32 and 64 bit linu
On 07/01/2011 09:14 AM, Hannes Reinecke wrote:
Actually, the kernel does _not_ do a LUN remapping.
Not the kernel, the in-kernel target. The in-kernel target can and will
map hardware LUNs (target_lun in drivers/target/*) to arbitrary LUNs
(mapped_lun).
Put in another way: the virtio-scsi de
On Wed, Jun 29, 2011 at 05:27:25PM +0100, Will Deacon wrote:
> Hi Frederic,
>
> Thanks for including me on CC.
>
> On Wed, Jun 29, 2011 at 05:08:45PM +0100, Frederic Weisbecker wrote:
> > On Wed, Jun 29, 2011 at 06:42:35PM +0300, Avi Kivity wrote:
> > > The perf_event overflow handler does not re
On 07/04/2011 04:58 PM, Frederic Weisbecker wrote:
Another thing I would like to do in the even longer term is to not use perf
anymore
for ptrace breakpoints, because that involves a heavy dependency and few people
are
happy with that. Instead we should just have a generic hook into the
sched_
From: Paul Mackerras
Commit 69acc0d3ba ("KVM: PPC: Resolve real-mode handlers through
function exports") resulted in vcpu->arch.trampoline_lowmem and
vcpu->arch.trampoline_enter ending up with kernel virtual addresses
rather than physical addresses. This is OK on 64-bit Book3S machines,
which ig
From: Paul Mackerras
Instead of branching out-of-line with the DO_KVM macro to check if we
are in a KVM guest at the time of an interrupt, this moves the KVM
check inline in the first-level interrupt handlers. This speeds up
the non-KVM case and makes sure that none of the interrupt handlers
are
From: Paul Mackerras
This adds the infrastructure for handling PAPR hcalls in the kernel,
either early in the guest exit path while we are still in real mode,
or later once the MMU has been turned back on and we are in the full
kernel context. The advantage of handling hcalls in real mode if
pos
From: Paul Mackerras
In hypervisor mode, the LPCR controls several aspects of guest
partitions, including virtual partition memory mode, and also controls
whether the hypervisor decrementer interrupts are enabled. This sets
up LPCR at boot time so that guest partitions will use a virtual real
me
From: Paul Mackerras
There are several fields in struct kvmppc_book3s_shadow_vcpu that
temporarily store bits of host state while a guest is running,
rather than anything relating to the particular guest or vcpu.
This splits them out into a new kvmppc_host_state structure and
modifies the definit
From: Paul Mackerras
Instead of doing the kvm_guest_enter/exit() and local_irq_dis/enable()
calls in powerpc.c, this moves them down into the subarch-specific
book3s_pr.c and booke.c. This eliminates an extra local_irq_enable()
call in book3s_pr.c, and will be needed for when we do SMT4 guest
su
From: Paul Mackerras
This lifts the restriction that book3s_hv guests can only run one
hardware thread per core, and allows them to use up to 4 threads
per core on POWER7. The host still has to run single-threaded.
This capability is advertised to qemu through a new KVM_CAP_PPC_SMT
capability.
From: Paul Mackerras
This replaces the single CPU_FTR_HVMODE_206 bit with two bits, one to
indicate that we have a usable hypervisor mode, and another to indicate
that the processor conforms to PowerISA version 2.06. We also add
another bit to indicate that the processor conforms to ISA version
From: Paul Mackerras
This adds infrastructure which will be needed to allow book3s_hv KVM to
run on older POWER processors, including PPC970, which don't support
the Virtual Real Mode Area (VRMA) facility, but only the Real Mode
Offset (RMO) facility. These processors require a physically
contig
Commit c8f729d408 (KVM: PPC: Deliver program interrupts right away instead
of queueing them) made away with all users of prog_flags, so we can just
remove it from the headers.
Signed-off-by: Alexander Graf
---
arch/powerpc/include/asm/kvm_book3s.h |1 -
1 files changed, 0 insertions(+), 1 de
From: Paul Mackerras
This arranges for the top-level arch/powerpc/kvm/powerpc.c file to
pass down some of the calls it gets to the lower-level subarchitecture
specific code. The lower-level implementations (in booke.c and book3s.c)
are no-ops. The coming book3s_hv.c will need this.
Signed-off-
From: Paul Mackerras
This adds support for running KVM guests in supervisor mode on those
PPC970 processors that have a usable hypervisor mode. Unfortunately,
Apple G5 machines have supervisor mode disabled (MSR[HV] is forced to
1), but the YDL PowerStation does have a usable hypervisor mode.
T
From: David Gibson
This improves I/O performance for guests using the PAPR
paravirtualization interface by making the H_PUT_TCE hcall faster, by
implementing it in real mode. H_PUT_TCE is used for updating virtual
IOMMU tables, and is used both for virtual I/O and for real I/O in the
PAPR interf
Hi Avi,
Here is my current patch queue for KVM on PPC. It contains support for
hardware accelerated KVM on 970 and POWER7 (no hardware) which is one
of the most interesting features we had added for a while now.
This new support doesn't work out-of-the-box with current Qemu, as it
requires some n
From: Paul Mackerras
Doing so means that we don't have to save the flags anywhere and gets
rid of the last reference to to_book3s(vcpu) in arch/powerpc/kvm/book3s.c.
Doing so is OK because a program interrupt won't be generated at the
same time as any other synchronous interrupt. If a program i
From: Paul Mackerras
This moves the slb field, which represents the state of the emulated
SLB, from the kvmppc_vcpu_book3s struct to the kvm_vcpu_arch, and the
hpte_hash_[v]pte[_long] fields from kvm_vcpu_arch to kvmppc_vcpu_book3s.
This is in accord with the principle that the kvm_vcpu_arch stru
On Mon, Jul 4, 2011 at 2:38 PM, Hai Dong,Li wrote:
> So if I understand correctly, virtio-scsi looks like an SCSI tranport
> protocol,
> such as iSCSI, FCP and SRP which use tcp/ip, FC and Infiniband RDMA
> respectively as the transfer media while virtio-scsi uses virtio, an virtual
> IO
> channel
On Mon, Jul 04, 2011 at 05:10:20PM +0300, Avi Kivity wrote:
> On 07/04/2011 04:58 PM, Frederic Weisbecker wrote:
> >Another thing I would like to do in the even longer term is to not use perf
> >anymore
> >for ptrace breakpoints, because that involves a heavy dependency and few
> >people are
> >h
On Mon, 2011-07-04 at 13:27 +0300, Avi Kivity wrote:
> On 07/03/2011 08:44 PM, Sasha Levin wrote:
> > On Sun, 2011-07-03 at 20:16 +0300, Avi Kivity wrote:
> > > On 07/03/2011 08:04 PM, Sasha Levin wrote:
> > > >
> > > > - eventfd_signal(p->eventfd, 1);
> > > > + if (p->pipe)
> > > >
On 07/04/2011 05:38 PM, Sasha Levin wrote:
>
> In general incremental development is great, but I don't want to
> fragment the ABI. I'd like to be able to forward an entire PCI BAR over
> a pipe. That means sending the address/data/length tuple, and both read
> and write support.
Would thi
On Mon, 2011-07-04 at 17:45 +0300, Avi Kivity wrote:
> On 07/04/2011 05:38 PM, Sasha Levin wrote:
> > >
> > > In general incremental development is great, but I don't want to
> > > fragment the ABI. I'd like to be able to forward an entire PCI BAR over
> > > a pipe. That means sending the addr
On 07/04/2011 05:52 PM, Sasha Levin wrote:
>
> I can't really see that as useful. eventfds destroy information;
> without datamatch, you have no idea what value was written. Even with
> datamatch, you have no idea how many times it was written. With a
> range, you also have no idea which a
This is a follow up on the last series. No significant changes.
Only change is in patch 7/9, where the steal time accounting
function is made inline, and also called from
irqtime_process_acount_tick(). At least in my box ( gcc 4.4.5),
gcc insists in not inlining it. So I am resorting to __always_in
From: Gleb Natapov
Introduce kvm_read_guest_cached() function in addition to write one we
already have.
[ by glauber: export function signature in kvm header ]
Signed-off-by: Gleb Natapov
Signed-off-by: Glauber Costa
---
include/linux/kvm_host.h |2 ++
virt/kvm/kvm_main.c | 20 +++
To implement steal time, we need the hypervisor to pass the guest information
about how much time was spent running other processes outside the VM.
This is per-vcpu, and using the kvmclock structure for that is an abuse
we decided not to make.
In this patchset, I am introducing a new msr, KVM_MSR_
To implement steal time, we need the hypervisor to pass the guest
information about how much time was spent running other processes
outside the VM, while the vcpu had meaningful work to do - halt
time does not count.
This information is acquired through the run_delay field of
delayacct/schedstats
This patch is simple, put in a different commit so it can be more easily
shared between guest and hypervisor. It just defines a named constant
to indicate the enable bit for KVM-specific MSRs.
Signed-off-by: Glauber Costa
CC: Rik van Riel
CC: Jeremy Fitzhardinge
CC: Peter Zijlstra
CC: Avi Kivi
This patch makes update_rq_clock() aware of steal time.
The mechanism of operation is not different from irq_time,
and follows the same principles. This lives in a CONFIG
option itself, and can be compiled out independently of
the rest of steal time reporting. The effect of disabling it
is that the
This patch adds a function pointer in one of the many paravirt_ops
structs, to allow guests to register a steal time function. Besides
a steal time function, we also declare two jump_labels. They will be
used to allow the steal time code to be easily bypassed when not
in use.
Signed-off-by: Glaube
This patch accounts steal time time in account_process_tick.
If one or more tick is considered stolen in the current
accounting cycle, user/system accounting is skipped. Idle is fine,
since the hypervisor does not report steal time if the guest
is halted.
Accounting steal time from the core schedu
Since in a later patch I intend to call jump labels inside
CONFIG_PARAVIRT, IA64 would fail to compile if they are not
provided. This patch provides those jump labels for the IA64
architecture.
Signed-off-by: Glauber Costa
CC: Isaku Yamahata
CC: Eddie Dong
CC: Rik van Riel
CC: Jeremy Fitzhardi
This patch implements the kvm bits of the steal time infrastructure.
The most important part of it, is the steal time clock. It is an
continuous clock that shows the accumulated amount of steal time
since vcpu creation. It is supposed to survive cpu offlining/onlining.
Signed-off-by: Glauber Costa
On 07/04/2011 09:52 AM, Juan Quintela wrote:
Hi
Please send in any agenda items you are interested in covering.
SCSI without bounce buffers: talk now, or forever hold your peace.
Paolo
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majord...@vger
On Tue, Jun 21, 2011 at 05:23:01AM -0700, Zachary Amsden wrote:
>
>
> Original Message
> Subject: [KVM TSC emulation 9/9] Add software TSC emulation
> Date: Mon, 20 Jun 2011 16:59:37 -0700
> From: Zachary Amsden
> To: Avi Kivity , Marcelo Tosatti
> , Glau
On Thu, Jun 23, 2011 at 10:23:10AM +0200, Jan Kiszka wrote:
> From: Jan Kiszka
>
> Bit-wise or the feature flags and drop the obsolete #ifdef.
>
> Signed-off-by: Jan Kiszka
> ---
> hw/kvmclock.c |7 ++-
> 1 files changed, 2 insertions(+), 5 deletions(-)
Applied, thanks.
--
To unsubsc
On Thu, Jun 23, 2011 at 10:26:27AM +0200, Jan Kiszka wrote:
> From: Jan Kiszka
>
> Signed-off-by: Jan Kiszka
> ---
> kvm-all.c |8
> 1 files changed, 0 insertions(+), 8 deletions(-)
Applied, thanks.
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of
Hi,
With default configure, the qemu-kvm client build was failing for me
since Werror is enabled by default in configure.
Deprecations (gnutls), gcc signed-overflow optimization
(Werror=strict-overflows) and few unused-but-set variables were
causing it. I have attached the patch
The gnutls_*_set_priority family of functions has been marked deprecated
in 2.12.x. These functions have been superceded by
gnutls_priority_set_direct().
Signed-off-by: Raghavendra D Prabhu
---
ui/vnc-tls.c | 20 +---
1 files changed, 1 insertions(+), 19 deletions(-)
diff --gi
This is to avoid gcc optimizating out the comparison in assert,
due to assumption of signed overflow being undefined by default
(-Werror=strict-overflow).
Signed-off-by: Raghavendra D Prabhu
---
Makefile.hw |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/Makefile.hw b/
In a few cases, variable attributed 'unused' has been added, in other cases
unused variable has been either removed or commented out.
Signed-off-by: Raghavendra D Prabhu
---
hw/device-assignment.c |6 +++---
simpletrace.c |2 +-
xen-mapcache.c |7 ++-
3 files cha
On 4 July 2011 23:00, Raghavendra D Prabhu wrote:
> This is to avoid gcc optimizating out the comparison in assert,
> due to assumption of signed overflow being undefined by default
> (-Werror=strict-overflow).
>--- a/Makefile.hw
>+++ b/Makefile.hw
>@@ -9,7 +9,7 @@ include $(SRC_PATH)/rules.mak
Add a module parameter 'check_inuse' to allow disabling the check of whether
virtualization has already been enabled on the given cpu.
This is needed to deal with broken BIOS which set the SVM/VMX bit by default.
Cc: Avi Kivity
Cc: Marcelo Tosatti
Suggested-by: Alexander Graf
Signed-off-by: Sa
Instead of exiting quietly, print an error if the VMX or the SVM bits
were already set when loading the module.
Having VMX/SVM bits set means that either there is someone else doing
hardware virtualization, or that the BIOS is buggy and sets it on
by default.
Cc: Avi Kivity
Cc: Marcelo Tosatti
On 05.07.2011, at 01:09, Sasha Levin wrote:
> Instead of exiting quietly, print an error if the VMX or the SVM bits
> were already set when loading the module.
>
> Having VMX/SVM bits set means that either there is someone else doing
> hardware virtualization, or that the BIOS is buggy and sets
> -Original Message-
> From: kvm-ow...@vger.kernel.org [mailto:kvm-ow...@vger.kernel.org] On
> Behalf Of Xiao Guangrong
> Sent: Friday, July 01, 2011 4:06 PM
> To: Yang, Wei Y
> Cc: a...@redhat.com; kvm@vger.kernel.org
> Subject: Re: [PATCH kvm-unit-tests v2] access: check SMEP on prefetc
On Mon, Jul 4, 2011 at 11:38 PM, Peter Maydell wrote:
> On 4 July 2011 23:00, Raghavendra D Prabhu wrote:
>> This is to avoid gcc optimizating out the comparison in assert,
>> due to assumption of signed overflow being undefined by default
>> (-Werror=strict-overflow).
>
>>--- a/Makefile.hw
>>++
On 07/05/2011 09:24 AM, Yang, Wei Y wrote:
>
>
>> -Original Message-
>> From: kvm-ow...@vger.kernel.org [mailto:kvm-ow...@vger.kernel.org] On
>> Behalf Of Xiao Guangrong
>> Sent: Friday, July 01, 2011 4:06 PM
>> To: Yang, Wei Y
>> Cc: a...@redhat.com; kvm@vger.kernel.org
>> Subject: Re: [
Typo in subject: "unsed". The warning is spelled
"unused-but-set-variable", the option "-Wunused-but-set-variable".
Raghavendra D Prabhu writes:
> In a few cases, variable attributed 'unused' has been added, in other cases
> unused variable has been either removed or commented out.
>
> Signed-o
> From: Sasha Levin
> Sent: Tuesday, July 05, 2011 7:09 AM
>
> Instead of exiting quietly, print an error if the VMX or the SVM bits
> were already set when loading the module.
>
> Having VMX/SVM bits set means that either there is someone else doing
> hardware virtualization, or that the BIOS is
> From: Alexander Graf
> Sent: Tuesday, July 05, 2011 8:42 AM
>
>
> On 05.07.2011, at 01:09, Sasha Levin wrote:
>
> > Instead of exiting quietly, print an error if the VMX or the SVM bits
> > were already set when loading the module.
> >
> > Having VMX/SVM bits set means that either there is som
hi
kvm-kmod-2.6.39 fails to build on debian squeeze (debian kernel 2.6.32).
error messages:
In file included from /usr/src/kvm-kmod-2.6.39/x86/x86.c:93:
/lib/modules/2.6.32-5-amd64/source/arch/x86/include/asm/pvclock.h:19:
error: redefinition of ‘pvclock_scale_delta’
/usr/src/kvm-kmod-2.6.39/x
83 matches
Mail list logo
