On 01/09/2012 09:29 PM, Scott Wood wrote:
> >
> > Best to include their signoffs, if possible.
>
> These patches are based in part on a bunch of different patches from
> these people (for which I did receive signoffs). I was reluctant to put
> their signoff directly on the new patches, since I di
On Mon, Jan 09, 2012 at 09:10:10PM +0100, Kevin Wolf wrote:
> * This works with VMX, but with SVM I have an additional problem: When
> trying to exit VM86 (usually by an exception) through a task gate in
> the IDT, the code runs into the reason = TASK_SWITCH_CALL path. I
> searched a bit in t
On 01/10/2012 07:37 AM, Zhang, Yang Z wrote:
Also, I'm not sure if the update in progress flag still works.
Clients are supposed to wait for UIP=0 before reading the RTC,
and an update is supposed to be at least 220 microseconds away
when UIP=0.
Hardware need a period time to update clock and i
Am 10.01.2012 10:01, schrieb Gleb Natapov:
> On Mon, Jan 09, 2012 at 09:10:10PM +0100, Kevin Wolf wrote:
>> * This works with VMX, but with SVM I have an additional problem: When
>> trying to exit VM86 (usually by an exception) through a task gate in
>> the IDT, the code runs into the reason =
Anybody?
On 09/01/12 11:49, Oriol Martí wrote:
Hello, I have an Ubuntu Server with KVM, the extensions in the BIOS
are enabled:
root@cluster03:~# kvm-ok
INFO: Your CPU supports KVM extensions
INFO: /dev/kvm exists
KVM acceleration can be used
The problem is that when i do a save of a virtual m
On Tue, Jan 10, 2012 at 10:28:06AM +0100, Kevin Wolf wrote:
> Am 10.01.2012 10:01, schrieb Gleb Natapov:
> > On Mon, Jan 09, 2012 at 09:10:10PM +0100, Kevin Wolf wrote:
> >> * This works with VMX, but with SVM I have an additional problem: When
> >> trying to exit VM86 (usually by an exception) t
Am 10.01.2012 10:28, schrieb Kevin Wolf:
> Am 10.01.2012 10:01, schrieb Gleb Natapov:
>> On Mon, Jan 09, 2012 at 09:10:10PM +0100, Kevin Wolf wrote:
>>> * This works with VMX, but with SVM I have an additional problem: When
>>> trying to exit VM86 (usually by an exception) through a task gate in
On Tue, Jan 10, 2012 at 12:25:18PM +0100, Kevin Wolf wrote:
> Am 10.01.2012 10:28, schrieb Kevin Wolf:
> > Am 10.01.2012 10:01, schrieb Gleb Natapov:
> >> On Mon, Jan 09, 2012 at 09:10:10PM +0100, Kevin Wolf wrote:
> >>> * This works with VMX, but with SVM I have an additional problem: When
> >>>
The virtio config area in PIO space is a bit special. The initial
header is little endian but the rest (device specific) is guest
native endian.
The PIO accessors for PCI on machines that don't have native IO ports
assume that all PIO is little endian, which works fine for everything
except the ab
ping
On Fri, 2012-01-06 at 15:06 +0100, Davidlohr Bueso wrote:
> From: Davidlohr Bueso
>
> We can remove the first ->nx state assignment since it is assigned afterwards
> anyways.
>
> Signed-off-by: Davidlohr Bueso
> ---
> arch/x86/kvm/mmu.c |1 -
> 1 files changed, 0 insertions(+), 1 de
On Fri, Jan 06, 2012 at 03:06:18PM +0100, Davidlohr Bueso wrote:
> From: Davidlohr Bueso
>
> We can remove the first ->nx state assignment since it is assigned afterwards
> anyways.
>
> Signed-off-by: Davidlohr Bueso
> ---
> arch/x86/kvm/mmu.c |1 -
> 1 files changed, 0 insertions(+), 1 d
On Mon, Jan 09, 2012 at 02:00:35PM -0500, Boris Ostrovsky wrote:
> From: Boris Ostrovsky
>
> In some cases guests should not provide workarounds for errata even when the
> physical processor is affected. For example, because of erratum 400 on family
> 10h processors a Linux guest will read an MSR
On 2012-01-09 23:05, Alex Williamson wrote:
> On Mon, 2012-01-09 at 22:25 +0100, Jan Kiszka wrote:
>> On 2012-01-09 20:45, Alex Williamson wrote:
>>> On Mon, 2012-01-09 at 15:03 +0100, Jan Kiszka wrote:
+static int kvm_vm_ioctl_set_pci_irq_mask(struct kvm *kvm,
+ struct kvm_assig
>From 2168285ffb30716f30e129c3ce98ce42d19c4d4e Mon Sep 17 00:00:00 2001
From: Stephan Baerwolf
Date: Tue, 10 Jan 2012 14:13:22 +0100
Subject: [PATCH 0/2] KVM guest-kernel panics double fault
regarding: https://lkml.org/lkml/2011/12/28/170
On tested computers (Intel Core i5-2520M, Intel Xeon X556
>From c603d51a02539c89dec05fd54de336b282b1cc12 Mon Sep 17 00:00:00 2001
From: Stephan Baerwolf
Date: Sun, 8 Jan 2012 23:25:59 +
Subject: [PATCH 1/2] KVM: extend "struct x86_emulate_ops" with "get_cpuid"
In order to be able to proceed checks on CPU-specific properties
within the emulator, func
>From 2168285ffb30716f30e129c3ce98ce42d19c4d4e Mon Sep 17 00:00:00 2001
From: Stephan Baerwolf
Date: Sun, 8 Jan 2012 02:03:47 +
Subject: [PATCH 2/2] KVM: fix missing "illegal instruction"-trap in
protected modes
On hosts without this patch, 32bit guests will crash
(and 64bit guests may behave
Hi
short call today. Topics talked about included:
second QOM series
- Anthony wants to rebase on top of Andreas
make check testing posted by Anthony
- everybody should run that before sending patches
- we should make a requirement that "make check" passes
if regressions still happen -> we
On Mon, Jan 09, 2012 at 03:03:00PM +0100, Jan Kiszka wrote:
> PCI 2.3 allows to generically disable IRQ sources at device level. This
> enables us to share legacy IRQs of such devices with other host devices
> when passing them to a guest.
>
> The new IRQ sharing feature introduced here is optiona
As we work on mapping the Freescale IOMMU (called PAMU) into the existing
Linux iommu infrastructure, one issue is that we have additional domain
attributes that need to be set. This was discussed briefly a month ago
or so and I believe there was a need for a similar mechanism by IBM.
We are pro
Wanted to get some input and feedback on a limitation we have run into
with the current
iommu_ops architecture regarding attaching (and detaching) devices.
The attach_dev API is defined as:
extern int iommu_attach_device(struct iommu_domain *domain,
struct device *d
On 2012-01-10 17:17, Michael S. Tsirkin wrote:
> On Mon, Jan 09, 2012 at 03:03:00PM +0100, Jan Kiszka wrote:
>> PCI 2.3 allows to generically disable IRQ sources at device level. This
>> enables us to share legacy IRQs of such devices with other host devices
>> when passing them to a guest.
>>
>> T
On Fri, Jan 06, 2012 at 01:20:55PM +, Peter Maydell wrote:
> On 6 January 2012 07:37, Zhang, Yang Z wrote:
> > use int64 when compare two time
> >
> > int32 only represent only 136 years when comparing two times based on
> > second. It would be better to use int64.
>
> "int32", "int32_t" and
On Tue, Jan 10, 2012 at 01:30:47PM +0200, Gleb Natapov wrote:
> On Tue, Jan 10, 2012 at 12:25:18PM +0100, Kevin Wolf wrote:
> > Did that now, and it looks like exit_int_info is always 0 during the
> > task switch intercept for a task gate in the IDT. So special-casing VM86
> > won't help, I'm afrai
On Tue, Jan 10, 2012 at 06:29:51PM +0100, Jan Kiszka wrote:
> On 2012-01-10 17:17, Michael S. Tsirkin wrote:
> > On Mon, Jan 09, 2012 at 03:03:00PM +0100, Jan Kiszka wrote:
> >> PCI 2.3 allows to generically disable IRQ sources at device level. This
> >> enables us to share legacy IRQs of such devi
On 2012-01-10 19:10, Michael S. Tsirkin wrote:
> On Tue, Jan 10, 2012 at 06:29:51PM +0100, Jan Kiszka wrote:
>> On 2012-01-10 17:17, Michael S. Tsirkin wrote:
>>> On Mon, Jan 09, 2012 at 03:03:00PM +0100, Jan Kiszka wrote:
PCI 2.3 allows to generically disable IRQ sources at device level. This
On Tue, Jan 10, 2012 at 07:21:01PM +0100, Jan Kiszka wrote:
> > ATM writes to msi/msix mask bit have no effect for assigned
> > devices. For virtio, they are implemented by deassigning irqfd
> > which is a very slow operation (rcu write side).
> >
> > Instead, When guest writes to mask, qemu can s
On Tue, 2012-01-10 at 11:26 -0500, Konrad Rzeszutek Wilk wrote:
> On Wed, Dec 21, 2011 at 02:42:02PM -0700, Alex Williamson wrote:
> > This series includes the core framework for the VFIO driver.
> > VFIO is a userspace driver interface meant to replace both the
> > KVM device assignment code as we
On 2012-01-10 19:31, Michael S. Tsirkin wrote:
> On Tue, Jan 10, 2012 at 07:21:01PM +0100, Jan Kiszka wrote:
>>> ATM writes to msi/msix mask bit have no effect for assigned
>>> devices. For virtio, they are implemented by deassigning irqfd
>>> which is a very slow operation (rcu write side).
>>>
>>
On Tue, Jan 10, 2012 at 07:43:36PM +0100, Jan Kiszka wrote:
> On 2012-01-10 19:31, Michael S. Tsirkin wrote:
> > On Tue, Jan 10, 2012 at 07:21:01PM +0100, Jan Kiszka wrote:
> >>> ATM writes to msi/msix mask bit have no effect for assigned
> >>> devices. For virtio, they are implemented by deassigni
Am 10.01.2012 00:44, schrieb Andreas Färber:
> Am 09.01.2012 12:29, schrieb Juan Quintela:
>> Please send in any agenda items you are interested in covering.
>
> Coordination of second QOM series: Who fixes what and til when.
Recapping this part of the call:
* Anthony will review and merge my pr
On 10.01.2012, at 20:11, Andreas Färber wrote:
> Am 10.01.2012 00:44, schrieb Andreas Färber:
>> Am 09.01.2012 12:29, schrieb Juan Quintela:
>>> Please send in any agenda items you are interested in covering.
>>
>> Coordination of second QOM series: Who fixes what and til when.
>
> Recapping th
On 2012-01-10 20:04, Michael S. Tsirkin wrote:
>>> But IMO this
>>> shows it is a more generic interface.
>>
>> I'm worried about adding something new that will soon become obsolete
>> again. That's wasted effort IMHO unless we say today that there will be
>> no in-kernel MSI-X support.
>>
>> Jan
Hello All,
I am preparing for a presentation for my community college, newbie to
the kvm world. I am trying to understand kvm implementation. I am
interested in doing a small presentation on kvm and its internals at
my school. I am looking at __direct_map() . I see
for_each_shadow_entry()->shadow
On 10.01.2012, at 12:35, Benjamin Herrenschmidt wrote:
> The virtio config area in PIO space is a bit special. The initial
> header is little endian but the rest (device specific) is guest
> native endian.
>
> The PIO accessors for PCI on machines that don't have native IO ports
> assume that al
Am 10.01.2012 21:30, schrieb Alexander Graf:
> Maybe the RTAS callbacks really want you to return stuff in little endian?
IIRC all RTAS callbacks need to be in the same bitness and endianness
(MSR LE+SB) as when instantiating RTAS from OF.
Andreas
--
SUSE LINUX Products GmbH, Maxfeldstr. 5, 904
On Tue, Jan 10, 2012 at 08:40:59PM +0100, Jan Kiszka wrote:
> On 2012-01-10 20:04, Michael S. Tsirkin wrote:
> >>> But IMO this
> >>> shows it is a more generic interface.
> >>
> >> I'm worried about adding something new that will soon become obsolete
> >> again. That's wasted effort IMHO unless w
On 10.01.2012, at 21:35, Andreas Färber wrote:
> Am 10.01.2012 21:30, schrieb Alexander Graf:
>> Maybe the RTAS callbacks really want you to return stuff in little endian?
>
> IIRC all RTAS callbacks need to be in the same bitness and endianness
> (MSR LE+SB) as when instantiating RTAS from OF.
On Tue, 2012-01-10 at 21:46 +0100, Alexander Graf wrote:
> On 10.01.2012, at 21:35, Andreas Färber wrote:
>
> > Am 10.01.2012 21:30, schrieb Alexander Graf:
> >> Maybe the RTAS callbacks really want you to return stuff in little
> endian?
> >
> > IIRC all RTAS callbacks need to be in the same bit
On 2012-01-10 21:44, Michael S. Tsirkin wrote:
> On Tue, Jan 10, 2012 at 08:40:59PM +0100, Jan Kiszka wrote:
>> On 2012-01-10 20:04, Michael S. Tsirkin wrote:
> But IMO this
> shows it is a more generic interface.
I'm worried about adding something new that will soon become obsol
On Tue, Jan 10, 2012 at 10:18:12PM +0100, Jan Kiszka wrote:
> On 2012-01-10 21:44, Michael S. Tsirkin wrote:
> > On Tue, Jan 10, 2012 at 08:40:59PM +0100, Jan Kiszka wrote:
> >> On 2012-01-10 20:04, Michael S. Tsirkin wrote:
> > But IMO this
> > shows it is a more generic interface.
>
On 10.01.2012, at 22:04, Benjamin Herrenschmidt wrote:
> On Tue, 2012-01-10 at 21:46 +0100, Alexander Graf wrote:
>> On 10.01.2012, at 21:35, Andreas Färber wrote:
>>
>>> Am 10.01.2012 21:30, schrieb Alexander Graf:
Maybe the RTAS callbacks really want you to return stuff in little
>> endia
On 01/10/2012 05:35 AM, Benjamin Herrenschmidt wrote:
The virtio config area in PIO space is a bit special. The initial
header is little endian but the rest (device specific) is guest
native endian.
The PIO accessors for PCI on machines that don't have native IO ports
assume that all PIO is litt
On 01/09/2012 09:11 PM, Alexander Graf wrote:
> On 10.01.2012, at 01:51, Scott Wood wrote:
>> On 01/09/2012 11:46 AM, Alexander Graf wrote:
>>> On 21.12.2011, at 02:34, Scott Wood wrote:
+ /* For debugging, encode the failing instruction and
+ * report it to userspace.
On Tue, 2012-01-10 at 22:45 +0100, Alexander Graf wrote:
> Here's the thing that I don't understand. What exactly is breaking for
> you? I tried -M pseries on a ppc box and on an x86 box and both times
> was able to see /dev/vda.
And mount it and use it ? Here I get the capacity wrong if I don't h
On Wed, 2012-01-11 at 09:04 +1100, Benjamin Herrenschmidt wrote:
> On Tue, 2012-01-10 at 22:45 +0100, Alexander Graf wrote:
> > Here's the thing that I don't understand. What exactly is breaking for
> > you? I tried -M pseries on a ppc box and on an x86 box and both times
> > was able to see /dev/v
On 01/10/2012 02:37 AM, Avi Kivity wrote:
> On 01/09/2012 09:29 PM, Scott Wood wrote:
>>>
>>> Best to include their signoffs, if possible.
>>
>> These patches are based in part on a bunch of different patches from
>> these people (for which I did receive signoffs). I was reluctant to put
>> their
On 10.01.2012, at 23:02, Anthony Liguori wrote:
> On 01/10/2012 05:35 AM, Benjamin Herrenschmidt wrote:
>> The virtio config area in PIO space is a bit special. The initial
>> header is little endian but the rest (device specific) is guest
>> native endian.
>>
>> The PIO accessors for PCI on mac
On Tue, 2012-01-10 at 23:41 +0100, Alexander Graf wrote:
>
> No. Libhw shouldn't be able to know anything about target endianness.
> If a device is as brokenly spec'ed as virtio and is coupled to the
> "main CPU endianness", it clearly belongs with the CPU, not into
> libhw.
Ok, can you guys solv
On 10.01.2012, at 23:49, Benjamin Herrenschmidt wrote:
> On Tue, 2012-01-10 at 23:41 +0100, Alexander Graf wrote:
>>
>> No. Libhw shouldn't be able to know anything about target endianness.
>> If a device is as brokenly spec'ed as virtio and is coupled to the
>> "main CPU endianness", it clearly
On 10.01.2012, at 23:52, Alexander Graf wrote:
>
> On 10.01.2012, at 23:49, Benjamin Herrenschmidt wrote:
>
>> On Tue, 2012-01-10 at 23:41 +0100, Alexander Graf wrote:
>>>
>>> No. Libhw shouldn't be able to know anything about target endianness.
>>> If a device is as brokenly spec'ed as virtio
On 10.01.2012, at 23:03, Scott Wood wrote:
> On 01/09/2012 09:11 PM, Alexander Graf wrote:
>> On 10.01.2012, at 01:51, Scott Wood wrote:
>>> On 01/09/2012 11:46 AM, Alexander Graf wrote:
On 21.12.2011, at 02:34, Scott Wood wrote:
> + /* For debugging, encode the failing instructi
On Tue, 2012-01-10 at 14:47 +0100, Jan Kiszka wrote:
> On 2012-01-09 23:05, Alex Williamson wrote:
> > On Mon, 2012-01-09 at 22:25 +0100, Jan Kiszka wrote:
> >> On 2012-01-09 20:45, Alex Williamson wrote:
> >>> On Mon, 2012-01-09 at 15:03 +0100, Jan Kiszka wrote:
> +static int kvm_vm_ioctl_set
> -Original Message-
> From: Paolo Bonzini [mailto:pbonz...@redhat.com]
> Sent: Tuesday, January 10, 2012 5:25 PM
> >> Also, I'm not sure if the update in progress flag still works.
> >> Clients are supposed to wait for UIP=0 before reading the RTC, and an
> >> update is supposed to be at l
By adding the a module alias, programs (or users) won't have to explicitly
call modprobe. Vhost-net will always be available if built into the kernel.
It does require assigning a permanent minor number for depmod to work.
Choose one next to TUN since this driver is related to it.
Also, use C99 sty
On 11.01.2012 08:54, Stephen Hemminger wrote:
> By adding the a module alias, programs (or users) won't have to explicitly
> call modprobe. Vhost-net will always be available if built into the kernel.
> It does require assigning a permanent minor number for depmod to work.
> Choose one next to TUN
utils.run()'s parameter "ignore_status" is set to "True" in virsh_cmd().
In this case we are not able to know whether the command succeeds.
This patch sets it to "False", and utils.run() will throw an exception
when command fails.
Signed-off-by: Tang Chen
---
client/virt/libvirt_vm.py |2
On 01/11/2012 01:56 AM, Zhang, Yang Z wrote:
Clients are supposed to wait for UIP=0 before reading the RTC,
and an update is supposed to be at least 220 microseconds away
when UIP=0.
>>>
>>> Hardware need a period time to update clock and it would not
>>> provide the right value dur
57 matches
Mail list logo
