Marcelo Tosatti wrote on 2013-02-25:
> On Sun, Feb 24, 2013 at 01:55:07PM +, Zhang, Yang Z wrote:
>>> contexts, but only two use locks.
>> See following logic, I think the problem you mentioned will not
>> happened with current logic.
>>
>> get lock
>> if test_pir (this will ensure there is no
Marcelo Tosatti wrote on 2013-02-25:
> On Sun, Feb 24, 2013 at 01:17:59PM +, Zhang, Yang Z wrote:
>> Marcelo Tosatti wrote on 2013-02-24:
>>> On Sat, Feb 23, 2013 at 03:16:11PM +, Zhang, Yang Z wrote:
Marcelo Tosatti wrote on 2013-02-23:
> On Sat, Feb 23, 2013 at 02:05:28PM +,
If userspace wants to change some specific bits of TSR
(timer status register) then it uses GET/SET_SREGS ioctl interface.
So the steps will be:
i) user-space will make get ioctl,
ii) change TSR in userspace
iii) then make set ioctl.
It can happen that TSR gets changed by kerne
This is done so that same function can be called from SREGS and
ONE_REG interface (follow up patch).
Signed-off-by: Bharat Bhushan
---
v3:
- kvmppc_set_tsr() marked static function as this is not called
outside of booke.c
v2: No change
arch/powerpc/kvm/booke.c | 24 ++
This patchset adds the one_reg interface to get/set
TSR and TCR registers.This patchet also adds the one_reg
interface to or/clear specific bits in TSR register.
v3:
- kvmppc_set_tsr() marked static function as this is not called
outside of booke.c
v2:
- Added Documentation
Bharat Bhushan (
On Mon, Feb 11, 2013 at 03:16:43PM -0700, Alex Williamson wrote:
>
> Why do these all return long (vs int)? Is this a POWER-ism?
On ppc64 the compiler tends to generate slightly shorter code with
longs than with ints. The reason is that with ints the compiler has
to put in "extend sign word" in
On Wed, Feb 20, 2013 at 04:58:54PM -0300, Marcelo Tosatti wrote:
> This is probably a stupid question, but why the
> KVM_SET_IRQCHIP/KVM_SET_GSI_ROUTING interface is not appropriate for
> your purposes?
>
> x86 sets up a default GSI->IRQCHIP PIN mapping on creation (during
> KVM_SET_IRQCHIP), but
On Mon, Feb 18, 2013 at 02:21:59PM +0200, Gleb Natapov wrote:
> Copying Christoffer since ARM has in kernel irq chip too.
>
> On Wed, Feb 13, 2013 at 11:49:15PM -0600, Scott Wood wrote:
> > Currently, devices that are emulated inside KVM are configured in a
> > hardcoded manner based on an assumpt
Hi Linus,
Please pull for v3.9-rc1. Thanks,
Alex
The following changes since commit 323a72d83c9b2963bd1e46c8e6963e468d4658d7:
Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/net (2013-02-13
12:21:07 -0800)
are available in the git repository at:
git://github.com/awilliam/linu
On Wed, Feb 20, 2013 at 5:17 PM, Marcelo Tosatti wrote:
>
> Please pull from
>
> git://git.kernel.org/pub/scm/virt/kvm/kvm.git tags/kvm-3.9-1
>
> to receive the KVM updates for the 3.9 merge window [..]
Ok, particularly the s390 people should check me resolution of the
conflicts, since they inclu
Hi,
I have noticed that virtio-rng only returns zero for kernels >= 2.6.33
built with CONFIG_HW_RANDOM=m. This is a bit much too predictable for a
random generator ;-).
The reason for that is virtio expects guest real addresses, while
rng_core.ko (ie when built as a module) is passing a vmalloced
On Tue, 2013-02-19 at 10:26 +0200, Gleb Natapov wrote:
> On Mon, Feb 18, 2013 at 08:12:21PM -0500, Peter Hurley wrote:
> > On Mon, 2013-02-18 at 19:59 -0300, Marcelo Tosatti wrote:
> > > On Wed, Feb 13, 2013 at 06:57:09AM -0500, Peter Hurley wrote:
> > > > On Wed, 2013-02-13 at 12:51 +0200, Gleb Na
On Sun, Feb 24, 2013 at 9:15 PM, Jan Kiszka wrote:
>>
>> They all need consistency checks, otherwise userspace or the guest and
>> inject inconsistent values and perhaps exploit the host.
>
> To my understanding, the hardware does this for us: If we try to enter
> the guest (L1, L2) with invalid C
On 2013-02-24 19:56, Avi Kivity wrote:
> On Sun, Feb 24, 2013 at 12:49 PM, Jan Kiszka wrote:
>> On 2013-02-24 11:11, Avi Kivity wrote:
>>> On Sun, Feb 24, 2013 at 11:40 AM, Jan Kiszka wrote:
>>> We have the same problem in KVM_SET_SREGS.
>>
>> I don't see the problem. kvm_arch_vcpu_io
I didn't really follow, but is the root cause the need to keep track
of interrupt coalescing? If so we can recommend that users use
KVM_IRQ_LINE when coalescing is unneeded, and move interrupt injection
with irq coalescing support to vcpu context.
It's not pleasant to cause a performance regressi
On Sun, Feb 24, 2013 at 12:49 PM, Jan Kiszka wrote:
> On 2013-02-24 11:11, Avi Kivity wrote:
>> On Sun, Feb 24, 2013 at 11:40 AM, Jan Kiszka wrote:
>> We have the same problem in KVM_SET_SREGS.
>
> I don't see the problem. kvm_arch_vcpu_ioctl_set_sregs open-codes the
> state updat
On Sun, Feb 24, 2013 at 04:19:17PM +0200, Gleb Natapov wrote:
> On Sun, Feb 24, 2013 at 01:55:07PM +, Zhang, Yang Z wrote:
> > > I do not think it fixes it. There is no guaranty that IPI will be
> > > processed by remote cpu while sending cpu is still in locked section, so
> > > the same race m
On Sun, Feb 24, 2013 at 01:17:59PM +, Zhang, Yang Z wrote:
> Marcelo Tosatti wrote on 2013-02-24:
> > On Sat, Feb 23, 2013 at 03:16:11PM +, Zhang, Yang Z wrote:
> >> Marcelo Tosatti wrote on 2013-02-23:
> >>> On Sat, Feb 23, 2013 at 02:05:28PM +, Zhang, Yang Z wrote:
> Marcelo Tosa
On Sun, Feb 24, 2013 at 01:55:07PM +, Zhang, Yang Z wrote:
> > contexts, but only two use locks.
> See following logic, I think the problem you mentioned will not happened with
> current logic.
>
> get lock
> if test_pir (this will ensure there is no in flight IPI for same interrupt.
> Since
On Fri, 2013-02-22 at 23:36 -0800, Kees Cook wrote:
> The CONFIG_EXPERIMENTAL config item has not carried much meaning for a
> while now and is almost always enabled by default. As agreed during the
> Linux kernel summit, remove it from any "depends on" lines in Kconfigs.
>
> Signed-off-by: Kees C
On 23 February 2013 15:29, Andreas Färber wrote:
>> +static int kvm_arm_gic_init(SysBusDevice *dev)
>
> Please make this a realize function ...
Will do. As you've probably guessed, this was written some time
ago and I never updated it to match our current recommendations.
>> +KVMARMGICClass
On Thu, Feb 21, 2013 at 08:17:54PM -0600, Scott Wood wrote:
> On 02/21/2013 02:22:09 AM, Gleb Natapov wrote:
> >On Wed, Feb 20, 2013 at 08:05:12PM -0600, Scott Wood wrote:
> >> On 02/20/2013 07:09:49 AM, Gleb Natapov wrote:
> >> >On Tue, Feb 19, 2013 at 03:16:37PM -0600, Scott Wood wrote:
> >> >>
On Sun, Feb 24, 2013 at 02:26:36PM +, Zhang, Yang Z wrote:
> > I do not see where those assumptions are coming from. Testing pir does
> > not guaranty that the IPI is not processed by VCPU right now.
> >
> > iothread: vcpu:
> > send_irq()
> > lock(pir)
> > check pir a
Gleb Natapov wrote on 2013-02-24:
> On Sun, Feb 24, 2013 at 01:55:07PM +, Zhang, Yang Z wrote:
>>> I do not think it fixes it. There is no guaranty that IPI will be
>>> processed by remote cpu while sending cpu is still in locked section, so
>>> the same race may happen regardless. As you say a
On Sun, Feb 24, 2013 at 01:55:07PM +, Zhang, Yang Z wrote:
> > I do not think it fixes it. There is no guaranty that IPI will be
> > processed by remote cpu while sending cpu is still in locked section, so
> > the same race may happen regardless. As you say above there are 3
> > contexts, but o
On Wed, Feb 20, 2013 at 06:20:51PM -0600, Scott Wood wrote:
> On 02/20/2013 01:58:54 PM, Marcelo Tosatti wrote:
> >This is probably a stupid question, but why the
> >KVM_SET_IRQCHIP/KVM_SET_GSI_ROUTING interface is not appropriate for
> >your purposes?
> >
> >x86 sets up a default GSI->IRQCHIP PIN
From: Jan Kiszka
On Intel, raising INIT causing an unconditional vmexit. On AMD, this is
controlled by the interception mask.
Signed-off-by: Jan Kiszka
---
Sorry for double-posting, failed to CC the list on first try.
arch/x86/include/asm/kvm_host.h |1 +
arch/x86/include/asm/vmx.h
Gleb Natapov wrote on 2013-02-24:
> On Sat, Feb 23, 2013 at 02:05:13PM -0300, Marcelo Tosatti wrote:
>> On Sat, Feb 23, 2013 at 05:31:44PM +0200, Gleb Natapov wrote:
>>> On Sat, Feb 23, 2013 at 11:48:54AM -0300, Marcelo Tosatti wrote:
>>> 1. orig_irr = read irr from vapic page
>>> 2. if (or
On Tue, 19 Feb 2013 18:16:53 -0800, Christoffer Dall
wrote:
> On Tue, Feb 19, 2013 at 12:16 PM, Scott Wood
> wrote:
>> We at least need the numberspace to not be architecture-specific if we
>> want
>> to retain the possibility of changing later -- not to mention what
>> happens
>> if architectu
Marcelo Tosatti wrote on 2013-02-24:
> On Sat, Feb 23, 2013 at 03:16:11PM +, Zhang, Yang Z wrote:
>> Marcelo Tosatti wrote on 2013-02-23:
>>> On Sat, Feb 23, 2013 at 02:05:28PM +, Zhang, Yang Z wrote:
Marcelo Tosatti wrote on 2013-02-23:
>
> On Fri, Feb 22, 2013 at 09:42:32PM
From: Jan Kiszka
No need to re-read what vmx_vcpu_run already picked up for us.
Signed-off-by: Jan Kiszka
---
arch/x86/kvm/vmx.c |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/x86/kvm/vmx.c b/arch/x86/kvm/vmx.c
index d45f0e0..ccb6456 100644
--- a/arch/x86/kvm/
On 2013-02-24 11:11, Avi Kivity wrote:
> On Sun, Feb 24, 2013 at 11:40 AM, Jan Kiszka wrote:
> We have the same problem in KVM_SET_SREGS.
I don't see the problem. kvm_arch_vcpu_ioctl_set_sregs open-codes the
state update, not applying any transition checks.
>>>
>>> That's the pr
On Sun, Feb 24, 2013 at 11:40 AM, Jan Kiszka wrote:
We have the same problem in KVM_SET_SREGS.
>>>
>>> I don't see the problem. kvm_arch_vcpu_ioctl_set_sregs open-codes the
>>> state update, not applying any transition checks.
>>
>> That's the problem. We have this open coding in three diffe
On Fri, Feb 22, 2013 at 01:09:47PM +0100, Cornelia Huck wrote:
> Add a new bus type for s390 css kvm io devices.
>
> Signed-off-by: Cornelia Huck
> ---
> include/linux/kvm_host.h | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/include/linux/kvm_host.h b/include/linux/kvm_host.h
> index
On Fri, Feb 22, 2013 at 01:09:45PM +0100, Cornelia Huck wrote:
> Here's the second attempt at implementing ioeventfd for s390.
The patchset looks fine overall.
Minor comments and questions below.
>
> Rather than the architecture-specific functions used in v1, we
> now try to integrate with the k
On Fri, Feb 22, 2013 at 01:09:48PM +0100, Cornelia Huck wrote:
> Enhance KVM_IOEVENTFD with a new flag that allows to attach to s390 css
> devices.
>
> Signed-off-by: Cornelia Huck
> ---
> Documentation/virtual/kvm/api.txt | 7 +++
> include/uapi/linux/kvm.h | 2 ++
> virt/kvm/event
On Fri, Feb 22, 2013 at 01:09:49PM +0100, Cornelia Huck wrote:
> Enable ioeventfd support on s390 and hook up diagnose 500 virtio-ccw
> notifications.
>
> Signed-off-by: Cornelia Huck
> ---
> arch/s390/kvm/Kconfig| 1 +
> arch/s390/kvm/Makefile | 2 +-
> arch/s390/kvm/diag.c | 25 +++
On Fri, Feb 22, 2013 at 01:09:45PM +0100, Cornelia Huck wrote:
> Here's the second attempt at implementing ioeventfd for s390.
>
> Rather than the architecture-specific functions used in v1, we
> now try to integrate with the kvm_io_device infrastructure.
> Calls to diagnose 500 subcode 3 are now
On 2013-02-24 10:21, Avi Kivity wrote:
> On Sun, Feb 24, 2013 at 11:01 AM, Jan Kiszka wrote:
>> On 2013-02-24 09:56, Avi Kivity wrote:
>>> On Sat, Feb 23, 2013 at 11:57 PM, Jan Kiszka wrote:
On 2013-02-23 22:45, Nadav Har'El wrote:
> On Sat, Feb 23, 2013, Jan Kiszka wrote about "[PATCH]
On Fri, Feb 22, 2013 at 08:22:08AM +0100, Cornelia Huck wrote:
> On Thu, 21 Feb 2013 22:42:41 +0200
> "Michael S. Tsirkin" wrote:
>
> > On Thu, Feb 21, 2013 at 07:14:31PM +0100, Cornelia Huck wrote:
> > > On Thu, 21 Feb 2013 18:34:59 +0200
> > > "Michael S. Tsirkin" wrote:
> > >
> > > > On Thu,
On Sun, Feb 24, 2013 at 11:01 AM, Jan Kiszka wrote:
> On 2013-02-24 09:56, Avi Kivity wrote:
>> On Sat, Feb 23, 2013 at 11:57 PM, Jan Kiszka wrote:
>>> On 2013-02-23 22:45, Nadav Har'El wrote:
On Sat, Feb 23, 2013, Jan Kiszka wrote about "[PATCH] KVM: nVMX: Replace
kvm_set_cr0 with vmx
On 2013-02-24 09:56, Avi Kivity wrote:
> On Sat, Feb 23, 2013 at 11:57 PM, Jan Kiszka wrote:
>> On 2013-02-23 22:45, Nadav Har'El wrote:
>>> On Sat, Feb 23, 2013, Jan Kiszka wrote about "[PATCH] KVM: nVMX: Replace
>>> kvm_set_cr0 with vmx_set_cr0 in load_vmcs12_host_state":
-kvm_set_cr0(
On Sat, Feb 23, 2013 at 11:57 PM, Jan Kiszka wrote:
> On 2013-02-23 22:45, Nadav Har'El wrote:
>> On Sat, Feb 23, 2013, Jan Kiszka wrote about "[PATCH] KVM: nVMX: Replace
>> kvm_set_cr0 with vmx_set_cr0 in load_vmcs12_host_state":
>>> -kvm_set_cr0(vcpu, vmcs12->host_cr0);
>>> +vmx_set_cr0
On 2013-02-23 23:21, Jan Kiszka wrote:
> On 2013-02-23 22:57, Jan Kiszka wrote:
>> On 2013-02-23 22:45, Nadav Har'El wrote:
>>> On Sat, Feb 23, 2013, Jan Kiszka wrote about "[PATCH] KVM: nVMX: Replace
>>> kvm_set_cr0 with vmx_set_cr0 in load_vmcs12_host_state":
- kvm_set_cr0(vcpu, vmcs12->ho
44 matches
Mail list logo
