On 03/06/2013 05:41 AM, Marcelo Tosatti wrote:
> On Tue, Mar 05, 2013 at 02:22:08PM -0600, Michael Wolf wrote:
>> Sorry for the delay in the response. I did not see the email
>> right away.
>>
>> On Mon, 2013-02-18 at 22:11 -0300, Marcelo Tosatti wrote:
>>> On Mon, Feb 18, 2013 at 05:43:47PM +0100
On Sun, Mar 03, 2013 at 11:17:38AM +0200, Gleb Natapov wrote:
> On Thu, Feb 28, 2013 at 08:13:10PM +0800, Hu Tao wrote:
> > This series implements a new interface, kvm pv event, to notify host when
> > some events happen in guest. Right now there is one supported event: guest
> > panic.
> >
> What
Hi,
On Mon, Mar 04, 2013 at 11:05:37AM +0100, Paolo Bonzini wrote:
> Il 03/03/2013 10:17, Gleb Natapov ha scritto:
> > On Thu, Feb 28, 2013 at 08:13:10PM +0800, Hu Tao wrote:
> >> This series implements a new interface, kvm pv event, to notify host when
> >> some events happen in guest. Right now
On Tue, Mar 05, 2013 at 09:26:18AM +0100, Paolo Bonzini wrote:
> Il 05/03/2013 04:17, Hu Tao ha scritto:
> > Will
> >
> > if (runstate_check(RUN_STATE_INTERNAL_ERROR) ||
> > runstate_check(RUN_STATE_SHUTDOWN) ||
> > runstate_check(RUN_STATE_GUEST_PANICKED)) {
>
On Wed, Mar 06, 2013 at 02:16:27PM +0800, Asias He wrote:
> This helper is useful to check if a feature is supported.
>
> Signed-off-by: Asias He
> ---
> drivers/vhost/tcm_vhost.c | 14 ++
> 1 file changed, 14 insertions(+)
>
> diff --git a/drivers/vhost/tcm_vhost.c b/drivers/vhost/
Il 06/03/2013 09:56, Hu Tao ha scritto:
>> >
>> > Something like this should work (in SeaBIOS's src/acpi-dsdt-isa.dsl):
>> >
>> > Device(PEVT) {
>> > Name(_HID, EisaId("QEMU0001"))
>> > OperationRegion(PEOR, SystemIO, 0x505, 0x01)
>> > Field(PEOR, ByteAcc, NoLock, Pres
On Wed, Mar 06, 2013 at 02:16:30PM +0800, Asias He wrote:
> +static struct tcm_vhost_evt *tcm_vhost_allocate_evt(struct vhost_scsi *vs,
> + u32 event, u32 reason)
> +{
> + struct tcm_vhost_evt *evt;
> +
> + if (atomic_read(&vs->vs_events_nr) > VHOST_SCSI_MAX_EVENT)
> + retur
On Tue, Mar 05, 2013 at 11:14:31PM -0800, H. Peter Anvin wrote:
> On 03/05/2013 04:05 PM, H. Peter Anvin wrote:
> > On 02/28/2013 07:24 AM, Michael S. Tsirkin wrote:
> >>
> >> 3. hypervisor assigned IO address
> >>qemu can reserve IO addresses and assign to virtio devices.
> >>2 bytes per d
在 2013-03-06三的 10:07 +0100，Paolo Bonzini写道：
> Il 06/03/2013 09:56, Hu Tao ha scritto:
> >> >
> >> > Something like this should work (in SeaBIOS's src/acpi-dsdt-isa.dsl):
> >> >
> >> > Device(PEVT) {
> >> > Name(_HID, EisaId("QEMU0001"))
> >> > OperationRegion(PEOR, SystemIO, 0
On Wed, Mar 06, 2013 at 04:46:58PM +0800, Hu Tao wrote:
> On Sun, Mar 03, 2013 at 11:17:38AM +0200, Gleb Natapov wrote:
> > On Thu, Feb 28, 2013 at 08:13:10PM +0800, Hu Tao wrote:
> > > This series implements a new interface, kvm pv event, to notify host when
> > > some events happen in guest. Righ
On Wed, Mar 06, 2013 at 10:07:31AM +0100, Paolo Bonzini wrote:
> Il 06/03/2013 09:56, Hu Tao ha scritto:
> >> >
> >> > Something like this should work (in SeaBIOS's src/acpi-dsdt-isa.dsl):
> >> >
> >> > Device(PEVT) {
> >> > Name(_HID, EisaId("QEMU0001"))
> >> > OperationRegio
Il 05/03/2013 16:25, Gleb Natapov ha scritto:
>> 1) We need to set the generic interrupt type of the system before we create
>> vcpus.
>>
>> This is a new ioctl that sets the overall system interrupt controller type
>> to a specific model. This used so that when we create vcpus, we can create
>>
> On Wed, Mar 06, 2013 at 10:07:31AM +0100, Paolo Bonzini wrote:
> > Il 06/03/2013 09:56, Hu Tao ha scritto:
> > >> >
> > >> > Something like this should work (in SeaBIOS's
> > >> > src/acpi-dsdt-isa.dsl):
> > >> >
> > >> > Device(PEVT) {
> > >> > Name(_HID, EisaId("QEMU0001"))
> > >
On Wed, Mar 06, 2013 at 10:40:18AM +0100, Paolo Bonzini wrote:
> Il 05/03/2013 16:25, Gleb Natapov ha scritto:
> >> 1) We need to set the generic interrupt type of the system before we
> >> create vcpus.
> >>
> >> This is a new ioctl that sets the overall system interrupt controller type
> >> to
On Wed, Mar 06, 2013 at 04:48:17AM -0500, Paolo Bonzini wrote:
>
> > On Wed, Mar 06, 2013 at 10:07:31AM +0100, Paolo Bonzini wrote:
> > > Il 06/03/2013 09:56, Hu Tao ha scritto:
> > > >> >
> > > >> > Something like this should work (in SeaBIOS's
> > > >> > src/acpi-dsdt-isa.dsl):
> > > >> >
> >
Am 06.03.2013 um 10:58 schrieb Gleb Natapov :
> On Wed, Mar 06, 2013 at 10:40:18AM +0100, Paolo Bonzini wrote:
>> Il 05/03/2013 16:25, Gleb Natapov ha scritto:
1) We need to set the generic interrupt type of the system before we
create vcpus.
This is a new ioctl that sets t
On Wed, Mar 06, 2013 at 11:04:21AM +0100, Alexander Graf wrote:
>
>
> Am 06.03.2013 um 10:58 schrieb Gleb Natapov :
>
> > On Wed, Mar 06, 2013 at 10:40:18AM +0100, Paolo Bonzini wrote:
> >> Il 05/03/2013 16:25, Gleb Natapov ha scritto:
> 1) We need to set the generic interrupt type of the s
On Wed, Mar 06, 2013 at 01:48:33PM +1100, Benjamin Herrenschmidt wrote:
> On Wed, 2013-02-13 at 23:49 -0600, Scott Wood wrote:
> > Currently, devices that are emulated inside KVM are configured in a
> > hardcoded manner based on an assumption that any given architecture
> > only has one way to do i
- Messaggio originale -
> Da: "Gleb Natapov"
> A: "Paolo Bonzini"
> Cc: "Alexander Graf" , kvm@vger.kernel.org,
> kvm-...@vger.kernel.org, "Stuart Yoder"
> , "Scott Wood" , "Paul
> Mackerras" , "Peter
> Maydell"
> Inviato: Mercoledì, 6 marzo 2013 10:58:35
> Oggetto: Re: in-kernel int
- Messaggio originale -
> Da: "Gleb Natapov"
> A: "Paolo Bonzini"
> Cc: "Alexander Graf" , kvm@vger.kernel.org,
> kvm-...@vger.kernel.org, "Stuart Yoder"
> , "Scott Wood" , "Paul
> Mackerras" , "Peter
> Maydell"
> Inviato: Mercoledì, 6 marzo 2013 10:58:35
> Oggetto: Re: in-kernel int
On 03/06/2013 01:21 AM, Michael S. Tsirkin wrote:
>
> Right. Though even with better granularify bridge windows
> would still be a (smaller) problem causing fragmentation.
>
> If we were to extend the PCI spec I would go for a bridge without
> windows at all: a bridge can snoop on configuration t
On Wed, Mar 06, 2013 at 05:38:33AM -0500, Paolo Bonzini wrote:
>
>
> - Messaggio originale -
> > Da: "Gleb Natapov"
> > A: "Paolo Bonzini"
> > Cc: "Alexander Graf" , kvm@vger.kernel.org,
> > kvm-...@vger.kernel.org, "Stuart Yoder"
> > , "Scott Wood" , "Paul
> > Mackerras" , "Peter
> >
On 06.03.2013, at 12:26, Gleb Natapov wrote:
> On Wed, Mar 06, 2013 at 05:38:33AM -0500, Paolo Bonzini wrote:
>>
>>
>> - Messaggio originale -
>>> Da: "Gleb Natapov"
>>> A: "Paolo Bonzini"
>>> Cc: "Alexander Graf" , kvm@vger.kernel.org,
>>> kvm-...@vger.kernel.org, "Stuart Yoder"
>>>
> > > So what is the difference between calling this special ioctl before
> > > creating vcpus and calling create device ioctl instead and create
> > > QEMU proxy device at whatever point in time QEMU wants to create
> > > it?
> >
> > Because you'd have to stash the handle that KVM_CREATE_DEVICE
On 06.03.2013, at 12:44, Paolo Bonzini wrote:
>
So what is the difference between calling this special ioctl before
creating vcpus and calling create device ioctl instead and create
QEMU proxy device at whatever point in time QEMU wants to create
it?
>>>
>>> Because you'd ha
> Please go ahead and try to describe an interface the way you envision
> it. It needs to fulfill the following criteria:
>
> * different machine models have different interrupt controller
> types
> * we need to be able to fetch information from interrupt
> controllers, this should be as f
On 06.03.2013, at 12:46, Paolo Bonzini wrote:
>> Please go ahead and try to describe an interface the way you envision
>> it. It needs to fulfill the following criteria:
>>
>> * different machine models have different interrupt controller
>> types
>> * we need to be able to fetch information
> > I agree. But is the device really being created at CREATE_DEVICE
> > time? What happens if you create N CPUs and N-1 irqchips?
>
> irqchip in CREATE_DEVICE is the IOAPIC, not the LAPIC. The LAPIC gets
> spawned at vcpu creation.
>
> > On x86, the LAPIC is created magically together with the V
On 06.03.2013, at 12:57, Paolo Bonzini wrote:
>>> I agree. But is the device really being created at CREATE_DEVICE
>>> time? What happens if you create N CPUs and N-1 irqchips?
>>
>> irqchip in CREATE_DEVICE is the IOAPIC, not the LAPIC. The LAPIC gets
>> spawned at vcpu creation.
>>
>>> On x8
On Wed, Mar 06, 2013 at 03:15:16AM -0800, H. Peter Anvin wrote:
> On 03/06/2013 01:21 AM, Michael S. Tsirkin wrote:
> >
> > Right. Though even with better granularify bridge windows
> > would still be a (smaller) problem causing fragmentation.
> >
> > If we were to extend the PCI spec I would go
On 06.03.2013, at 12:59, Gleb Natapov wrote:
> On Wed, Mar 06, 2013 at 12:46:52PM +0100, Alexander Graf wrote:
>>
>> On 06.03.2013, at 12:44, Paolo Bonzini wrote:
>>
>>>
>> So what is the difference between calling this special ioctl before
>> creating vcpus and calling create device i
> > So what is the difference between calling this special ioctl
> > before
> > creating vcpus and calling create device ioctl instead and
> > create
> > QEMU proxy device at whatever point in time QEMU wants to
> > create
> > it?
> > >>>
> > >>> Because you'd h
On 06.03.2013, at 13:14, Paolo Bonzini wrote:
>
>>> So what is the difference between calling this special ioctl
>>> before
>>> creating vcpus and calling create device ioctl instead and
>>> create
>>> QEMU proxy device at whatever point in time QEMU wants to
>>> create
>
> > Alex, would the PPC patches let you run with in-kernel "LAPICs"
> > and userspace "IOAPICs"? If so, the new model would not be a
> > problem with QEMU at all.
>
> The split on PPC isn't that clean. The MPIC doesn't split it at all
> for example. There we only have an "IOAPIC" without a "LAPIC
On Wed, Mar 06, 2013 at 12:46:52PM +0100, Alexander Graf wrote:
>
> On 06.03.2013, at 12:44, Paolo Bonzini wrote:
>
> >
> So what is the difference between calling this special ioctl before
> creating vcpus and calling create device ioctl instead and create
> QEMU proxy device at
On Wed, Mar 06, 2013 at 01:20:39PM +0100, Alexander Graf wrote:
> > The problem would only start if KVM_SET_IRQCHIP_TYPE (new name of
> > KVM_CREATE_IRQCHIP_ARGS) forced you to later call KVM_CREATE_DEVICE.
>
> Ah, I see. I don't see why it would. The fact that there is a "LAPIC" doesn't
> mean t
On Wed, Mar 06, 2013 at 12:58:39PM +0100, Alexander Graf wrote:
>
> On 06.03.2013, at 12:57, Paolo Bonzini wrote:
>
> >>> I agree. But is the device really being created at CREATE_DEVICE
> >>> time? What happens if you create N CPUs and N-1 irqchips?
> >>
> >> irqchip in CREATE_DEVICE is the IO
2013/2/19 Marcelo Tosatti :
> On Mon, Feb 18, 2013 at 05:43:47PM +0100, Frederic Weisbecker wrote:
>> 2013/2/5 Michael Wolf :
>> > In the case of where you have a system that is running in a
>> > capped or overcommitted environment the user may see steal time
>> > being reported in accounting tools
On 06.03.2013, at 14:14, Gleb Natapov wrote:
> On Wed, Mar 06, 2013 at 01:20:39PM +0100, Alexander Graf wrote:
>>> The problem would only start if KVM_SET_IRQCHIP_TYPE (new name of
>>> KVM_CREATE_IRQCHIP_ARGS) forced you to later call KVM_CREATE_DEVICE.
>>
>> Ah, I see. I don't see why it would.
2013/3/5 Michael Wolf :
> Sorry for the delay in the response. I did not see the email
> right away.
>
> On Mon, 2013-02-18 at 22:11 -0300, Marcelo Tosatti wrote:
>> On Mon, Feb 18, 2013 at 05:43:47PM +0100, Frederic Weisbecker wrote:
>> > 2013/2/5 Michael Wolf :
>> > > In the case of where you ha
Il 06/03/2013 14:14, Gleb Natapov ha scritto:
The problem would only start if KVM_SET_IRQCHIP_TYPE (new name of
KVM_CREATE_IRQCHIP_ARGS) forced you to later call KVM_CREATE_DEVICE.
>>>
>>> Ah, I see. I don't see why it would. The fact that there is a
>>> "LAPIC" doesn't mean that the per
On Wed, Mar 06, 2013 at 02:22:15PM +0100, Alexander Graf wrote:
>
> On 06.03.2013, at 14:14, Gleb Natapov wrote:
>
> > On Wed, Mar 06, 2013 at 01:20:39PM +0100, Alexander Graf wrote:
> >>> The problem would only start if KVM_SET_IRQCHIP_TYPE (new name of
> >>> KVM_CREATE_IRQCHIP_ARGS) forced you
On 06.03.2013, at 14:56, Gleb Natapov wrote:
> On Wed, Mar 06, 2013 at 02:22:15PM +0100, Alexander Graf wrote:
>>
>> On 06.03.2013, at 14:14, Gleb Natapov wrote:
>>
>>> On Wed, Mar 06, 2013 at 01:20:39PM +0100, Alexander Graf wrote:
> The problem would only start if KVM_SET_IRQCHIP_TYPE (ne
On Wed, Mar 06, 2013 at 02:41:04PM +0100, Paolo Bonzini wrote:
> Il 06/03/2013 14:14, Gleb Natapov ha scritto:
> The problem would only start if KVM_SET_IRQCHIP_TYPE (new name of
> KVM_CREATE_IRQCHIP_ARGS) forced you to later call KVM_CREATE_DEVICE.
> >>>
> >>> Ah, I see. I don't see why
Il 06/03/2013 15:03, Alexander Graf ha scritto:
> KVM_IRQ_LINE is basically an IOAPIC interrupt line assert. That's
> fine. That ioctl should get an ioapic device handle to work on.
It would be a KVM_SET_DEVICE_ATTR in your case, right?
> Whether we call the IOAPIC PINs GSIs or something differen
Il 05/03/2013 23:51, Nicholas A. Bellinger ha scritto:
> For making progress with Paolo's vhost-scsi branch on my side, this was
> still being blocked by bios boot hangs:
>
> http://www.spinics.net/lists/target-devel/msg03830.html
>
> Paolo & Co, any ideas on the latter..?
Nope. Asias, do you h
On 06.03.2013, at 15:12, Paolo Bonzini wrote:
> Il 06/03/2013 15:03, Alexander Graf ha scritto:
>> KVM_IRQ_LINE is basically an IOAPIC interrupt line assert. That's
>> fine. That ioctl should get an ioapic device handle to work on.
>
> It would be a KVM_SET_DEVICE_ATTR in your case, right?
No,
On 06.03.2013, at 15:11, Gleb Natapov wrote:
> On Wed, Mar 06, 2013 at 02:41:04PM +0100, Paolo Bonzini wrote:
>> Il 06/03/2013 14:14, Gleb Natapov ha scritto:
>> The problem would only start if KVM_SET_IRQCHIP_TYPE (new name of
>> KVM_CREATE_IRQCHIP_ARGS) forced you to later call KVM_CREA
Il 06/03/2013 15:30, Alexander Graf ha scritto:
>>> >> KVM_IRQ_LINE is basically an IOAPIC interrupt line assert. That's
>>> >> fine. That ioctl should get an ioapic device handle to work on.
>> >
>> > It would be a KVM_SET_DEVICE_ATTR in your case, right?
> No, it would be KVM_IRQ_LINE. It's basi
On 06.03.2013, at 15:37, Paolo Bonzini wrote:
> Il 06/03/2013 15:30, Alexander Graf ha scritto:
>> KVM_IRQ_LINE is basically an IOAPIC interrupt line assert. That's
>> fine. That ioctl should get an ioapic device handle to work on.
It would be a KVM_SET_DEVICE_ATTR in your case
On Wed, Mar 06, 2013 at 03:03:53PM +0100, Alexander Graf wrote:
>
> On 06.03.2013, at 14:56, Gleb Natapov wrote:
>
> > On Wed, Mar 06, 2013 at 02:22:15PM +0100, Alexander Graf wrote:
> >>
> >> On 06.03.2013, at 14:14, Gleb Natapov wrote:
> >>
> >>> On Wed, Mar 06, 2013 at 01:20:39PM +0100, Alex
Properly set those bits to 1 that the spec demands in case bit 55 of
VMX_BASIC is 0 - like in our case.
Signed-off-by: Jan Kiszka
---
Changes in v3:
- rebase over queue
arch/x86/include/asm/vmx.h |4
arch/x86/kvm/vmx.c | 13 ++---
2 files changed, 14 insertions(+),
On 06.03.2013, at 15:41, Gleb Natapov wrote:
> On Wed, Mar 06, 2013 at 03:03:53PM +0100, Alexander Graf wrote:
>>
>> On 06.03.2013, at 14:56, Gleb Natapov wrote:
>>
>>> On Wed, Mar 06, 2013 at 02:22:15PM +0100, Alexander Graf wrote:
On 06.03.2013, at 14:14, Gleb Natapov wrote:
On 06.03.2013, at 15:48, Alexander Graf wrote:
>
> On 06.03.2013, at 15:41, Gleb Natapov wrote:
>
>> On Wed, Mar 06, 2013 at 03:03:53PM +0100, Alexander Graf wrote:
>>>
>>> On 06.03.2013, at 14:56, Gleb Natapov wrote:
>>>
On Wed, Mar 06, 2013 at 02:22:15PM +0100, Alexander Graf wrote:
>>
Il 06/03/2013 15:59, Alexander Graf ha scritto:
> Then we don't care about any ordering at all anymore from KVM's
> perspective. Alternatively, the above code could live inside kvm as
> well of course. create_vcpu() would have to register itself with "the
> interrupt controller" then to allow for h
On Wed, Mar 06, 2013 at 03:48:54PM +0100, Alexander Graf wrote:
>
> On 06.03.2013, at 15:41, Gleb Natapov wrote:
>
> > On Wed, Mar 06, 2013 at 03:03:53PM +0100, Alexander Graf wrote:
> >>
> >> On 06.03.2013, at 14:56, Gleb Natapov wrote:
> >>
> >>> On Wed, Mar 06, 2013 at 02:22:15PM +0100, Alex
On Tue, 2013-03-05 at 22:41 -0300, Marcelo Tosatti wrote:
> On Tue, Mar 05, 2013 at 02:22:08PM -0600, Michael Wolf wrote:
> > Sorry for the delay in the response. I did not see the email
> > right away.
> >
> > On Mon, 2013-02-18 at 22:11 -0300, Marcelo Tosatti wrote:
> > > On Mon, Feb 18, 2013 a
On Wed, 2013-03-06 at 12:13 +0400, Glauber Costa wrote:
> On 03/06/2013 05:41 AM, Marcelo Tosatti wrote:
> > On Tue, Mar 05, 2013 at 02:22:08PM -0600, Michael Wolf wrote:
> >> Sorry for the delay in the response. I did not see the email
> >> right away.
> >>
> >> On Mon, 2013-02-18 at 22:11 -0300,
Am 06.03.2013 um 16:30 schrieb Gleb Natapov :
> On Wed, Mar 06, 2013 at 03:48:54PM +0100, Alexander Graf wrote:
>>
>> On 06.03.2013, at 15:41, Gleb Natapov wrote:
>>
>>> On Wed, Mar 06, 2013 at 03:03:53PM +0100, Alexander Graf wrote:
On 06.03.2013, at 14:56, Gleb Natapov wrote:
On Wed, 2013-03-06 at 14:34 +0100, Frederic Weisbecker wrote:
> 2013/3/5 Michael Wolf :
> > Sorry for the delay in the response. I did not see the email
> > right away.
> >
> > On Mon, 2013-02-18 at 22:11 -0300, Marcelo Tosatti wrote:
> >> On Mon, Feb 18, 2013 at 05:43:47PM +0100, Frederic Weisbec
Il 06/03/2013 02:28, Asias He ha scritto:
>> > This can queue up quite a bit of memory if the handler thread
>> > is delayed, no? Can we limit the # of outstanding events?
>> > Will guest recover from a missed event?
> Hmm, good point. Will limit the number. The size of 'struct
> tcm_vhost_evt' is
On 6 March 2013 22:31, Alexander Graf wrote:
> On 06.03.2013, at 15:11, Gleb Natapov wrote:
>> KVM_INTERRUPT is synchronous.
>
> Ah, I think that's where my thinko is. On PPC, KVM_INTERRUPT is
> asynchronous.
As an aside, would it be worth moving PPC into line with other
archs by providing and us
Am 06.03.2013 um 19:46 schrieb Peter Maydell :
> On 6 March 2013 22:31, Alexander Graf wrote:
>> On 06.03.2013, at 15:11, Gleb Natapov wrote:
>>> KVM_INTERRUPT is synchronous.
>>
>> Ah, I think that's where my thinko is. On PPC, KVM_INTERRUPT is
>> asynchronous.
>
> As an aside, would it be w
On Tue, Feb 26, 2013 at 05:40:10PM +, Peter Maydell wrote:
> KVM ARM support has just hit Linus' kernel tree, so we can
> finally commit this series to QEMU. Since all the patches got
> reviewed last time round this should be ready to commit.
> I plan to commit this via arm-devs.next.
>
> NB:
On Mar 2, 2013, at 7:45 AM, Peter Maydell wrote:
> On 2 March 2013 15:18, Sanjay Lal wrote:
>> +/* If we have an interrupt but the guest is not ready to receive an
>> + * interrupt, request an interrupt window exit. This will
>> + * cause a return to userspace as soon as the guest i
On Mar 2, 2013, at 12:03 PM, Peter Maydell wrote:
> On 2 March 2013 15:18, Sanjay Lal wrote:
>> --- /dev/null
>> +++ b/hw/mips_cps_bootcode.h
>> @@ -0,0 +1,310 @@
>> +/* Sample boot code for 1004K CPS (Coherent Processing System.)
>> + * Not Generic for all Release 2 or higher MIPS32 or MIPS64 p
On Mar 2, 2013, at 7:27 AM, Peter Maydell wrote:
> 2013/3/2 Sanjay Lal :
>> +static void gt64xxx_save(QEMUFile *f, void *opaque)
>> +{
>> +GT64120State *s = opaque;
>> +
>> +/* CPU Configuration */
>> +qemu_put_be32s(f, &s->regs[GT_CPU]);
>> +qemu_put_be32s(f, &s->regs[GT_MULTI]);
On Wed, Mar 06, 2013 at 01:12:52AM -0500, Paolo Bonzini wrote:
>
> > On Tue, Mar 05, 2013 at 08:16:41PM -0300, Marcelo Tosatti wrote:
> > > On Mon, Mar 04, 2013 at 10:41:43PM +0100, Jan Kiszka wrote:
> > > > From: Jan Kiszka
> > > >
> > > > A VCPU sending INIT or SIPI to some other VCPU races fo
On Wed, Mar 06, 2013 at 08:57:54AM +0100, Jan Kiszka wrote:
> On 2013-03-06 07:12, Paolo Bonzini wrote:
> >
> >> On Tue, Mar 05, 2013 at 08:16:41PM -0300, Marcelo Tosatti wrote:
> >>> On Mon, Mar 04, 2013 at 10:41:43PM +0100, Jan Kiszka wrote:
> From: Jan Kiszka
>
> A VCPU sending
On 2013-03-06 22:30, Marcelo Tosatti wrote:
> On Wed, Mar 06, 2013 at 08:57:54AM +0100, Jan Kiszka wrote:
>> On 2013-03-06 07:12, Paolo Bonzini wrote:
>>>
On Tue, Mar 05, 2013 at 08:16:41PM -0300, Marcelo Tosatti wrote:
> On Mon, Mar 04, 2013 at 10:41:43PM +0100, Jan Kiszka wrote:
>> F
On Wed, Mar 06, 2013 at 10:39:27PM +0100, Jan Kiszka wrote:
> On 2013-03-06 22:30, Marcelo Tosatti wrote:
> > On Wed, Mar 06, 2013 at 08:57:54AM +0100, Jan Kiszka wrote:
> >> On 2013-03-06 07:12, Paolo Bonzini wrote:
> >>>
> On Tue, Mar 05, 2013 at 08:16:41PM -0300, Marcelo Tosatti wrote:
> >>
On 2013-03-06 22:50, Marcelo Tosatti wrote:
> On Wed, Mar 06, 2013 at 10:39:27PM +0100, Jan Kiszka wrote:
>> On 2013-03-06 22:30, Marcelo Tosatti wrote:
>>> On Wed, Mar 06, 2013 at 08:57:54AM +0100, Jan Kiszka wrote:
On 2013-03-06 07:12, Paolo Bonzini wrote:
>
>> On Tue, Mar 05, 2013 a
Il 06/03/2013 22:19, Marcelo Tosatti ha scritto:
> Vcpu should only invoke kvm_emulate_halt if it has been through a
> KVM_MP_STATE_UNINITIALIZED -> KVM_MP_STATE_INIT_RECEIVED ->
> KVM_MP_STATE_SIPI_RECEIVED -> KVM_MP_STATE_RUNNABLE transition.
>
> If it has been through that, how can a KVM_MP_ST
On Wed, Mar 06, 2013 at 11:43:30PM +0100, Paolo Bonzini wrote:
> Il 06/03/2013 22:19, Marcelo Tosatti ha scritto:
> > Vcpu should only invoke kvm_emulate_halt if it has been through a
> > KVM_MP_STATE_UNINITIALIZED -> KVM_MP_STATE_INIT_RECEIVED ->
> > KVM_MP_STATE_SIPI_RECEIVED -> KVM_MP_STATE_RUN
On Tue, Mar 05, 2013 at 02:42:54AM +, Marc Zyngier wrote:
> This patch series is reworking KVM/arm in order to prepare the code
> to be shared with the upcoming KVM/arm64.
>
> Nothing major here, just a lot of accessors, small cleanups and fixes
> to make the code useable on arm64.
>
> This c
On Wed, Mar 06, 2013 at 10:21:09AM +0100, Stefan Hajnoczi wrote:
> On Wed, Mar 06, 2013 at 02:16:30PM +0800, Asias He wrote:
> > +static struct tcm_vhost_evt *tcm_vhost_allocate_evt(struct vhost_scsi *vs,
> > + u32 event, u32 reason)
> > +{
> > + struct tcm_vhost_evt *evt;
> > +
> > + if (ato
(Re-sending this, since my Gmail interface decided to compose the
previous one in rich format and the kvm list rejected it - no changes
to the content)
Hi Marcelo / Gleb,
Please pull these KVM/ARM fixes mostly centered around preparation for
Marc's ARMv8 KVM work.
Thanks,
-Christoffer
The follo
On Wed, Mar 06, 2013 at 10:06:20AM +0100, Stefan Hajnoczi wrote:
> On Wed, Mar 06, 2013 at 02:16:27PM +0800, Asias He wrote:
> > This helper is useful to check if a feature is supported.
> >
> > Signed-off-by: Asias He
> > ---
> > drivers/vhost/tcm_vhost.c | 14 ++
> > 1 file changed
On Wed, Mar 06, 2013 at 06:41:47PM +0100, Paolo Bonzini wrote:
> Il 06/03/2013 02:28, Asias He ha scritto:
> >> > This can queue up quite a bit of memory if the handler thread
> >> > is delayed, no? Can we limit the # of outstanding events?
> >> > Will guest recover from a missed event?
> > Hmm, go
On Mon, Mar 04, 2013 at 08:40:29PM +0100, Jan Kiszka wrote:
> The logic for calculating the value with which we call kvm_set_cr0/4 was
> broken (will definitely be visible with nested unrestricted guest mode
> support). Also, we performed the check regarding CR0_ALWAYSON too early
> when in guest m
On Wed, Mar 06, 2013 at 03:44:03PM +0100, Jan Kiszka wrote:
> Properly set those bits to 1 that the spec demands in case bit 55 of
> VMX_BASIC is 0 - like in our case.
>
> Signed-off-by: Jan Kiszka
> ---
>
> Changes in v3:
> - rebase over queue
>
> arch/x86/include/asm/vmx.h |4
> ar
On Tue, Mar 05, 2013 at 03:18:00AM +, Marc Zyngier wrote:
> In order to be able to correctly profile what is happening on the
> host, we need to be able to identify when we're running on the guest,
> and log these events differently.
>
> Perf offers a simple way to register callbacks into KVM.
On Wed, Mar 06, 2013 at 03:28:00PM +0100, Paolo Bonzini wrote:
> Il 05/03/2013 23:51, Nicholas A. Bellinger ha scritto:
> > For making progress with Paolo's vhost-scsi branch on my side, this was
> > still being blocked by bios boot hangs:
> >
> > http://www.spinics.net/lists/target-devel/msg0383
Commit 523f0e5421c12610527c620b983b443f329e3a32 ("KVM: PPC: E500:
Explicitly mark shadow maps invalid") began using E500_TLB_VALID
for guest TLB1 entries, and skipping invalidations if it's not set.
However, when E500_TLB_VALID was set for such entries, it was on a
fake local ref, and so the inval
On Wed, Mar 06, 2013 at 10:29:12AM -0600, Michael Wolf wrote:
> On Wed, 2013-03-06 at 12:13 +0400, Glauber Costa wrote:
> > On 03/06/2013 05:41 AM, Marcelo Tosatti wrote:
> > > On Tue, Mar 05, 2013 at 02:22:08PM -0600, Michael Wolf wrote:
> > >> Sorry for the delay in the response. I did not see t
On Wed, Mar 06, 2013 at 10:27:13AM -0600, Michael Wolf wrote:
> On Tue, 2013-03-05 at 22:41 -0300, Marcelo Tosatti wrote:
> > On Tue, Mar 05, 2013 at 02:22:08PM -0600, Michael Wolf wrote:
> > > Sorry for the delay in the response. I did not see the email
> > > right away.
> > >
> > > On Mon, 2013
On Wed, Mar 06, 2013 at 03:48:54PM +0100, Alexander Graf wrote:
>
> Paul, Scott, do you think we can move the "this CPU can receive
> interrupts from MPIC / XICS" part into an ENABLE_CAP that gets set
> dynamically? That ENABLE_CAP would allocate the structures in the vcpu
> and register the vcpu
On Wed, Mar 06, 2013 at 09:52:16PM -0300, Marcelo Tosatti wrote:
> On Wed, Mar 06, 2013 at 10:29:12AM -0600, Michael Wolf wrote:
> > I looked at doing that once but was told that I was changing the
> > interface in an unacceptable way, because now I was not reporting all of
> > the elapsed time. I
This adds a new ioctl, KVM_SET_IRQ_ARCHITECTURE, which is intended to
be called by userspace to specify that it wishes the kernel to emulate
a specific interrupt controller architecture. This doesn't imply the
creation of any specific device, but does indicate that when vcpus are
created, space fo
On Wed, 6 Mar 2013 16:31:48 -0800, Christoffer Dall
wrote:
Hi Christoffer,
>
> Please pull these KVM/ARM fixes mostly centered around preparation for
> Marc's ARMv8 KVM work.
Can we please hold on that for a while? asm-offset.c is usually a
candidate for merge conflicts as people start pushing
On Wed, Mar 6, 2013 at 7:54 PM, Marc Zyngier wrote:
> On Wed, 6 Mar 2013 16:31:48 -0800, Christoffer Dall
>
> wrote:
>
> Hi Christoffer,
>
>>
>> Please pull these KVM/ARM fixes mostly centered around preparation for
>> Marc's ARMv8 KVM work.
>
> Can we please hold on that for a while? asm-offset.
After commit 2b8b328b61c799957a456a5a8dab8cc7dea68575 (vhost_net: handle polling
errors when setting backend), we in fact track the polling state through
poll->wqh, so there's no need to duplicate the work with an extra
vhost_net_polling_state. So this patch removes this and make the code simpler.
On Wed, 6 Mar 2013 20:40:00 -0800, Christoffer Dall
wrote:
> On Wed, Mar 6, 2013 at 7:54 PM, Marc Zyngier
wrote:
>> On Wed, 6 Mar 2013 16:31:48 -0800, Christoffer Dall
>>
>> wrote:
>>
>> Hi Christoffer,
>>
>>>
>>> Please pull these KVM/ARM fixes mostly centered around preparation for
>>> Marc's
> On Wed, Mar 06, 2013 at 03:48:54PM +0100, Alexander Graf wrote:
> >
> > Paul, Scott, do you think we can move the "this CPU can receive
> > interrupts from MPIC / XICS" part into an ENABLE_CAP that gets set
> > dynamically? That ENABLE_CAP would allocate the structures in the
> > vcpu and regis
On Mon, Mar 04, 2013 at 08:40:29PM +0100, Jan Kiszka wrote:
> The logic for calculating the value with which we call kvm_set_cr0/4 was
> broken (will definitely be visible with nested unrestricted guest mode
> support). Also, we performed the check regarding CR0_ALWAYSON too early
> when in guest m
95 matches
Mail list logo
