Gleb Natapov wrote on 2013-01-08:
> On Tue, Jan 08, 2013 at 11:57:59AM -0200, Marcelo Tosatti wrote:
>> On Tue, Jan 08, 2013 at 12:57:42PM +, Zhang, Yang Z wrote:
>>> Gleb Natapov wrote on 2013-01-08:
On Mon, Jan 07, 2013 at 07:32:39PM -0200, Marcelo Tosatti wrote:
> On Mon, Jan 07, 20
On 01/08/2013 06:14 PM, Jason Wang wrote:
> On 01/08/2013 06:00 PM, Wanlong Gao wrote:
>> On 01/08/2013 05:51 PM, Jason Wang wrote:
>>> On 01/08/2013 05:49 PM, Wanlong Gao wrote:
On 01/08/2013 05:29 PM, Jason Wang wrote:
> On 01/08/2013 05:07 PM, Wanlong Gao wrote:
>> On 12/28/2012 06:
On Mon, Jan 07, 2013 at 05:08:13PM +0800, lei yang wrote:
> On Mon, Jan 7, 2013 at 4:58 PM, Stefan Hajnoczi wrote:
> > On Sun, Jan 6, 2013 at 12:27 PM, lei yang wrote:
> >> What's the different with below combos?
> >
> > The difference is historical, it's just how the command-line options
> > evo
On Wed, Jan 09, 2013 at 03:55:23PM +0800, ak...@redhat.com wrote:
> From: Amos Kong
>
> VIRTIO_NET_F_VTRL_VQ -> VIRTIO_NET_F_CTRL_VQ
> VIRTIO_NET_CTRL_MQ is defined to 4 in kernel code
>
> Signed-off-by: Amos Kong
> ---
> virtio-spec.lyx | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions
On Mon, 7 Jan 2013 16:20:43 -0200
Eduardo Habkost wrote:
> This is a cleanup that tries to solve two small issues:
>
> - We don't need a separate kvm_pv_eoi_features variable just to keep a
>constant calculated at compile-time, and this style would require
>adding a separate variable (
On 01/09/2013 04:23 PM, Wanlong Gao wrote:
> On 01/08/2013 06:14 PM, Jason Wang wrote:
>> On 01/08/2013 06:00 PM, Wanlong Gao wrote:
>>> On 01/08/2013 05:51 PM, Jason Wang wrote:
On 01/08/2013 05:49 PM, Wanlong Gao wrote:
> On 01/08/2013 05:29 PM, Jason Wang wrote:
>> On 01/08/2013 05:
On Fri, Dec 28, 2012 at 06:31:53PM +0800, Jason Wang wrote:
> diff --git a/qapi-schema.json b/qapi-schema.json
> index 5dfa052..583eb7c 100644
> --- a/qapi-schema.json
> +++ b/qapi-schema.json
> @@ -2465,7 +2465,7 @@
> { 'type': 'NetdevTapOptions',
>'data': {
> '*ifname': 'str',
> -
On 01/09/2013 05:30 PM, Jason Wang wrote:
> On 01/09/2013 04:23 PM, Wanlong Gao wrote:
>> On 01/08/2013 06:14 PM, Jason Wang wrote:
>>> On 01/08/2013 06:00 PM, Wanlong Gao wrote:
On 01/08/2013 05:51 PM, Jason Wang wrote:
> On 01/08/2013 05:49 PM, Wanlong Gao wrote:
>> On 01/08/2013 05:
Am 09.01.2013 um 00:49 schrieb Christoffer Dall :
> On Tue, Jan 8, 2013 at 6:29 PM, Scott Wood wrote:
>> On 01/08/2013 05:17:05 PM, Christoffer Dall wrote:
>>>
>>> On Tue, Jan 8, 2013 at 5:36 PM, Scott Wood
>>> wrote:
On 01/08/2013 12:41:30 PM, Christoffer Dall wrote:
> +struct kvm_d
On Tue, Jan 08, 2013 at 09:45:35PM +0100, Artur Samborski wrote:
> W dniu 08.01.2013 00:00, Marcelo Tosatti pisze:
> >On Mon, Jan 07, 2013 at 06:13:22PM +0100, Artur Samborski wrote:
> >>Hello,
> >>
> >>When i try to run FreeBSD-amd64 on more than 1 vcpu in quemu-kvm
> >>(Fedora Core 17) eg. to run
On Mon, Jan 7, 2013 at 8:14 PM, Will Deacon wrote:
> Hello kvm hackers,
>
> This patch series introduces some updates to the ARM (AArch32) kvm tools
> code:
>
> - virtio mmio fixes to deal with guest page sizes != 4k (in
> preparation for AArch64, which I will post separately).
>
Hi Will,
On Mon, Jan 7, 2013 at 8:43 PM, Will Deacon wrote:
> Hello again,
>
> These two patches add support for ARMv8 processors running an AArch64 instance
> of kvm to kvmtool. Both AArch32 and AArch64 guests are supported and, in the
> case of the latter, the guest page size may be either 64k
On Wed, Jan 09, 2013 at 11:16:42AM +, Pekka Enberg wrote:
> Hi Will,
Hello,
> On Mon, Jan 7, 2013 at 8:43 PM, Will Deacon wrote:
> > These two patches add support for ARMv8 processors running an AArch64
> > instance
> > of kvm to kvmtool. Both AArch32 and AArch64 guests are supported and, i
On Wed, Jan 09, 2013 at 09:41:37AM -0200, Eduardo Habkost wrote:
[...]
> Andreas, please ignore this patch (it is not necessary anymore as this
> series doesn't include machine-type compatibility code for kvm_mmu).
> Patches 2-7 don't depend on this patch and should apply cleanly without
> it.
I m
On Wed, Jan 09, 2013 at 11:13:58AM +, Pekka Enberg wrote:
> On Mon, Jan 7, 2013 at 8:14 PM, Will Deacon wrote:
> > Hello kvm hackers,
> >
> > This patch series introduces some updates to the ARM (AArch32) kvm tools
> > code:
> >
> > - virtio mmio fixes to deal with guest page sizes !=
On Wed, Jan 9, 2013 at 1:33 PM, Will Deacon wrote:
> I think we're getting our wires crossed a bit here, so I'll try to explain
> my madness:
>
> - Mainline ARM kernels cannot be booted by kvmtool yet, you
> currently have to use my virt/mach branch from
>
> git://git
On Wed, Jan 09, 2013 at 10:46:12AM +0100, Igor Mammedov wrote:
> On Mon, 7 Jan 2013 16:20:43 -0200
> Eduardo Habkost wrote:
>
> > This is a cleanup that tries to solve two small issues:
> >
> > - We don't need a separate kvm_pv_eoi_features variable just to keep a
> >constant calculated at
Hello,
I'd like to ask a few questions about the way migrations work in KVM
among different emulated machine types and different versions of the
qemu-kvm package. I am sending to both the kvm@ and qemu-devel@ lists,
please redirect me if I was wrong in doing so.
In a nutshell: while trying to liv
On Wed, Jan 09, 2013 at 02:23:50PM +0200, Vangelis Koukis wrote:
> Hello,
>
> I'd like to ask a few questions about the way migrations work in KVM
> among different emulated machine types and different versions of the
> qemu-kvm package. I am sending to both the kvm@ and qemu-devel@ lists,
> pleas
On Wed, Jan 09, 2013 at 01:10:45pm +, Daniel P. Berrange wrote:
> When doing migration, the fundamental requirement is that the guest
> OS visible machine ABI must not change. Thus there are three key
> things to take care of when launching QEMU on the migration target
> host.
>
> - The devic
Hello.
On 08-01-2013 22:42, Christoffer Dall wrote:
From: Marc Zyngier
It is now possible to select the VGIC configuration option.
Signed-off-by: Marc Zyngier
Signed-off-by: Christoffer Dall
---
arch/arm/kvm/Kconfig |8
1 file changed, 8 insertions(+)
diff --git a/ar
On Fri, Dec 28, 2012 at 06:31:52PM +0800, Jason Wang wrote:
> Perf Numbers:
>
> Two Intel Xeon 5620 with direct connected intel 82599EB
> Host/Guest kernel: David net tree
> vhost enabled
>
> - lots of improvents of both latency and cpu utilization in request-reponse
> test
> - get regression of
On 9 January 2013 10:02, Alexander Graf wrote:
> I think we should make thus at least potentially generic. In fact, I wouldn't
> even
> mind calling it DEV_REG with the same semantics as ONE_REG, just that it also
> gets a unique dev id that gets created during in-kernel device creation and
> th
On 09.01.2013, at 15:48, Peter Maydell wrote:
> On 9 January 2013 10:02, Alexander Graf wrote:
>> I think we should make thus at least potentially generic. In fact, I
>> wouldn't even
>> mind calling it DEV_REG with the same semantics as ONE_REG, just that it also
>> gets a unique dev id that g
On Wed, Jan 9, 2013 at 10:11 AM, Peter Maydell wrote:
> On 9 January 2013 14:58, Alexander Graf wrote:
>>
>> On 09.01.2013, at 15:48, Peter Maydell wrote:
>>
>>> On 9 January 2013 10:02, Alexander Graf wrote:
I think we should make thus at least potentially generic. In fact, I
wouldn'
On Mon, Jan 07, 2013 at 04:20:45PM -0200, Eduardo Habkost wrote:
> This introduces a FeatureWord enum, FeatureWordInfo struct (with
> generation information about a feature word), and a FeatureWordArray
> typedef, and changes add_flagname_to_bitmaps() code and
> cpu_x86_parse_featurestr() to use th
On 9 January 2013 14:58, Alexander Graf wrote:
>
> On 09.01.2013, at 15:48, Peter Maydell wrote:
>
>> On 9 January 2013 10:02, Alexander Graf wrote:
>>> I think we should make thus at least potentially generic. In fact, I
>>> wouldn't even
>>> mind calling it DEV_REG with the same semantics as O
On 09.01.2013, at 16:11, Peter Maydell wrote:
> On 9 January 2013 14:58, Alexander Graf wrote:
>>
>> On 09.01.2013, at 15:48, Peter Maydell wrote:
>>
>>> On 9 January 2013 10:02, Alexander Graf wrote:
I think we should make thus at least potentially generic. In fact, I
wouldn't eve
On Wed, Jan 09, 2013 at 08:07:31AM +, Zhang, Yang Z wrote:
> >>if(check_request(KVM_REQ_, )) {
> >>ioapic_lock(); (*)
> >>update local EOI exit bitmap from IOAPIC
> In my patch, it traverses IOAPIC entry once and only updates target vcpus's
> eoi exit b
On Mon, Jan 07, 2013 at 04:20:41PM -0200, Eduardo Habkost wrote:
> Changes on v3:
> - Patches 3-9 from v2 are now already on qom-cpu tree
> - Remove CONFIG_KVM #ifdefs by declaring fake KVM_* #defines on sysemu/kvm.h
> - Refactor code that uses the feature word arrays
>(to make it easier to
On 01/09/2013 05:56 PM, Stefan Hajnoczi wrote:
> On Fri, Dec 28, 2012 at 06:31:53PM +0800, Jason Wang wrote:
>> diff --git a/qapi-schema.json b/qapi-schema.json
>> index 5dfa052..583eb7c 100644
>> --- a/qapi-schema.json
>> +++ b/qapi-schema.json
>> @@ -2465,7 +2465,7 @@
>> { 'type': 'NetdevTapOpti
On 01/09/2013 06:01 PM, Wanlong Gao wrote:
> On 01/09/2013 05:30 PM, Jason Wang wrote:
>> On 01/09/2013 04:23 PM, Wanlong Gao wrote:
>>> On 01/08/2013 06:14 PM, Jason Wang wrote:
On 01/08/2013 06:00 PM, Wanlong Gao wrote:
> On 01/08/2013 05:51 PM, Jason Wang wrote:
>> On 01/08/2013 05:
On 09.01.2013, at 16:22, Marc Zyngier wrote:
> On Wed, 9 Jan 2013 15:11:39 +, Peter Maydell
>
> wrote:
>> On 9 January 2013 14:58, Alexander Graf wrote:
>>>
>>> Yeah, that was the basic idea. Considering that the patch set hasn't
>>> been going
>>> in for another 2 months after that discus
On Wed, Jan 09, 2013 at 03:29:24PM +0100, Stefan Hajnoczi wrote:
> On Fri, Dec 28, 2012 at 06:31:52PM +0800, Jason Wang wrote:
> > Perf Numbers:
> >
> > Two Intel Xeon 5620 with direct connected intel 82599EB
> > Host/Guest kernel: David net tree
> > vhost enabled
> >
> > - lots of improvents of
On 01/09/2013 11:32 PM, Michael S. Tsirkin wrote:
> On Wed, Jan 09, 2013 at 03:29:24PM +0100, Stefan Hajnoczi wrote:
>> On Fri, Dec 28, 2012 at 06:31:52PM +0800, Jason Wang wrote:
>>> Perf Numbers:
>>>
>>> Two Intel Xeon 5620 with direct connected intel 82599EB
>>> Host/Guest kernel: David net tree
On Wed, 9 Jan 2013 15:11:39 +, Peter Maydell
wrote:
> On 9 January 2013 14:58, Alexander Graf wrote:
>>
>> Yeah, that was the basic idea. Considering that the patch set hasn't
>> been going
>> in for another 2 months after that discussion indicates that this isn't
>> too much of
>> an issue t
On 09.01.2013, at 16:50, Marc Zyngier wrote:
> On Wed, 9 Jan 2013 16:28:03 +0100, Alexander Graf wrote:
>> On 09.01.2013, at 16:22, Marc Zyngier wrote:
>>
>>> On Wed, 9 Jan 2013 15:11:39 +, Peter Maydell
>>>
>>> wrote:
On 9 January 2013 14:58, Alexander Graf wrote:
>
> Yeah,
On 09/01/13 15:56, Alexander Graf wrote:
>
> On 09.01.2013, at 16:50, Marc Zyngier wrote:
>
>> On Wed, 9 Jan 2013 16:28:03 +0100, Alexander Graf wrote:
>>> On 09.01.2013, at 16:22, Marc Zyngier wrote:
>>>
On Wed, 9 Jan 2013 15:11:39 +, Peter Maydell
wrote:
> On 9 January
On Wed, 9 Jan 2013 16:28:03 +0100, Alexander Graf wrote:
> On 09.01.2013, at 16:22, Marc Zyngier wrote:
>
>> On Wed, 9 Jan 2013 15:11:39 +, Peter Maydell
>>
>> wrote:
>>> On 9 January 2013 14:58, Alexander Graf wrote:
Yeah, that was the basic idea. Considering that the patch set
On ARM (and possibly other architectures) some bits are specific to the
model being emulated for the guest and user space needs a way to tell
the kernel about those bits. An example is mmio device base addresses,
where KVM must know the base address for a given device to properly
emulate mmio acce
User space defines the model to emulate to a guest and should therefore
decide which addresses are used for both the virtual CPU interface
directly mapped in the guest physical address space and for the emulated
distributor interface, which is mapped in software by the in-kernel VGIC
support.
Sign
Renames the KVM_SET_DEVICE_ADDRESS to KVM_ARM_SET_DEVICE_ADDR
to make it obvious that this is ARM specific in lack of a better generic
interface.
Once we agree on a better interface the KVM/ARM code can also take
advantage of that, but until then we don't want to hold up the KVM/ARM
patches.
A ne
On Wed, Jan 9, 2013 at 11:12 AM, Marc Zyngier wrote:
> On 09/01/13 15:56, Alexander Graf wrote:
>>
>> On 09.01.2013, at 16:50, Marc Zyngier wrote:
>>
>>> On Wed, 9 Jan 2013 16:28:03 +0100, Alexander Graf wrote:
On 09.01.2013, at 16:22, Marc Zyngier wrote:
> On Wed, 9 Jan 2013 15:11:
On Wed, Jan 9, 2013 at 8:28 AM, Sergei Shtylyov wrote:
> Hello.
>
>
> On 08-01-2013 22:42, Christoffer Dall wrote:
>
>> From: Marc Zyngier
>
>
>> It is now possible to select the VGIC configuration option.
>
>
>> Signed-off-by: Marc Zyngier
>> Signed-off-by: Christoffer Dall
>> ---
>> arch/ar
On 09.01.2013, at 17:26, Christoffer Dall wrote:
> Renames the KVM_SET_DEVICE_ADDRESS to KVM_ARM_SET_DEVICE_ADDR
> to make it obvious that this is ARM specific in lack of a better generic
> interface.
>
> Once we agree on a better interface the KVM/ARM code can also take
> advantage of that, but
Here's what I have found so far...
Ubuntu 10.04 performed within +/- 2% so I'm not including those results.It
seems that it's more of an issue of disk access, so I'm going to run some more
disk specific benchmarks and I'll those results later. I'd be happy to run
any other perf tests that
On Wed, 2013-01-09 at 06:26 +, Pandarathil, Vijaymohan R wrote:
> - New ioctl which is used to pass the eventfd that is signaled when
> an error occurs in the vfio_pci_device
>
> - Register pci_error_handler for the vfio_pci driver
>
> - When the device encounters
On Wed, 2013-01-09 at 06:26 +, Pandarathil, Vijaymohan R wrote:
> - Create eventfd per vfio device assigned to a guest and register an
> event handler
>
> - This fd is passed to the vfio_pci driver through a new ioctl
>
> - When the device encounters an error, the
This is a cleanup that tries to solve two small issues:
- We don't need a separate kvm_pv_eoi_features variable just to keep a
constant calculated at compile-time, and this style would require
adding a separate variable (that's declared twice because of the
CONFIG_KVM ifdef) for each fea
This will allow each architecture to define how the VCPU ID is set on
the KVM_CREATE_VCPU ioctl call.
Signed-off-by: Eduardo Habkost
---
Cc: kvm@vger.kernel.org
Cc: Michael S. Tsirkin
Cc: Gleb Natapov
Cc: Marcelo Tosatti
Changes v2:
- Get CPUState as argument instead of CPUArchState
---
inc
Signed-off-by: Eduardo Habkost
---
Cc: kvm@vger.kernel.org
Cc: Michael S. Tsirkin
Cc: Gleb Natapov
Cc: Marcelo Tosatti
---
include/sysemu/kvm.h | 1 +
1 file changed, 1 insertion(+)
diff --git a/include/sysemu/kvm.h b/include/sysemu/kvm.h
index 6bdd513..22acf91 100644
--- a/include/sysemu/kvm
Currently, the pc-1.4 machine init function enables PV EOI and then
calls the pc-1.2 machine init function. The problem with this approach
is that now we can't enable any compatibility code inside the pc-1.2
init function because it would enable the compatibility behavior on
pc-1.3 and pc-1.4 as we
Signed-off-by: Eduardo Habkost
---
Changes v1 -> v2:
- Support 32-bit APIC IDs (in case x2APIC is going to be used)
- Coding style changes
- Use TARGET_I386_TOPOLOGY_H instead of __QEMU_X86_TOPOLOGY_H__
- Rename topo_make_apic_id() to topo_apicid_for_cpu()
- Rename __make_apicid() to topo_mak
PC will not use max_cpus for that field, so move it outside the common
code so it can use a different value on PC.
Signed-off-by: Eduardo Habkost
---
hw/fw_cfg.c | 1 -
hw/pc.c | 2 +-
hw/ppc_newworld.c | 1 +
hw/ppc_oldworld.c | 1 +
hw/sun4m.c| 3 +++
hw/sun4u.c
This changes FW_CFG_MAX_CPUS and FW_CFG_NUMA to use apic_id_for_cpu(),
so the NUMA table can be based on the APIC IDs, instead of CPU index
(SeaBIOS knows nothing about CPU indexes, just APIC IDs).
Signed-off-by: Eduardo Habkost
---
Changes v2:
- Get PC object as argument
- Add more detailed co
To make unit tests that depend on target-specific files, use
check-unit--y and test-obj--y.
Signed-off-by: Eduardo Habkost
---
tests/Makefile | 15 ---
1 file changed, 12 insertions(+), 3 deletions(-)
diff --git a/tests/Makefile b/tests/Makefile
index b09a343..fa96d1a 100644
--- a/t
The code that calculates the APIC ID will use smp_cores/smp_threads, so
just define them as 1 on *-user to avoid #ifdefs in the code.
Signed-off-by: Eduardo Habkost
---
include/sysemu/cpus.h | 7 +++
1 file changed, 7 insertions(+)
diff --git a/include/sysemu/cpus.h b/include/sysemu/cpus.h
The CPU ID in KVM is supposed to be the APIC ID, so change the
KVM_CREATE_VCPU call to match it. The current behavior didn't break
anything yet because today the APIC ID is assumed to be equal to the CPU
index, but this won't be true in the future.
Signed-off-by: Eduardo Habkost
---
Cc: kvm@vger.
This function will be used by both the CPU initialization code and the
fw_cfg table initialization code.
Later this function will be updated to generate APIC IDs according to
the CPU topology.
Signed-off-by: Eduardo Habkost
---
target-i386/cpu.c | 17 -
target-i386/cpu.h | 2 ++
This keeps compatibility on machine-types pc-1.2 and older, and prints a
warning in case the requested configuration won't get the correct
topology.
I couldn't think of a better way to warn about broken topology when in
compat mode other than using error_report(). The warning message will be
proba
This series uses a much simpler approach than the previous versions:
- The APIC ID calculation code is now inside cpu.c
- It doesn't require touching the PC CPU creation code at all
- It simply uses a static variable to enable the compat behavior on pc-1.3
and older
- I considered making
On Wed, 2013-01-09 at 10:52 -0700, Alex Williamson wrote:
> On Wed, 2013-01-09 at 06:26 +, Pandarathil, Vijaymohan R wrote:
> > - New ioctl which is used to pass the eventfd that is signaled when
> > an error occurs in the vfio_pci_device
> >
> > - Register pci_error_handler
Guests typically enable MSI-X with all of the vectors in the MSI-X
vector table masked. Only when the vector is enabled does the vector
get unmasked, resulting in a vector_use callback. These two points,
enable and unmask, correspond to pci_enable_msix() and request_irq()
for Linux guests. Some
VFIO_PCI_NUM_REGIONS and VFIO_PCI_NUM_IRQS should never have been
used in this manner as it locks a specific kernel implementation.
Future features may introduce new regions or interrupt entries
(VGA may add legacy ranges, AER might add an IRQ for error
signalling). Fix this before it gets us into
Anthony,
The following changes since commit 560c30b1db1d40fe45c5104185367c4de43399d3:
Merge remote-tracking branch 'kraxel/usb.75' into staging (2013-01-08
10:36:20 -0600)
are available in the git repository at:
git://github.com/awilliam/qemu-vfio.git tags/qemu-1.4-vfio-20130109.0
for yo
On 01/09/2013 10:48:47 AM, Alexander Graf wrote:
On 09.01.2013, at 17:26, Christoffer Dall wrote:
> Renames the KVM_SET_DEVICE_ADDRESS to KVM_ARM_SET_DEVICE_ADDR
> to make it obvious that this is ARM specific in lack of a better
generic
> interface.
>
> Once we agree on a better interface th
On 09.01.2013, at 20:50, Scott Wood wrote:
> On 01/09/2013 10:48:47 AM, Alexander Graf wrote:
>> On 09.01.2013, at 17:26, Christoffer Dall wrote:
>> > Renames the KVM_SET_DEVICE_ADDRESS to KVM_ARM_SET_DEVICE_ADDR
>> > to make it obvious that this is ARM specific in lack of a better generic
>> > i
Hello,
'am running into an issue with the latest bits. [ Pl. see below. The
vhost thread seems to be getting
stuck while trying to memcopy...perhaps a bad address?. ] Wondering if
this is a known issue or
some recent regression ?
'am using the latest qemu (from qemu.git) and the latest kvm.
On 01/09/2013 02:12:16 PM, Alexander Graf wrote:
On 09.01.2013, at 20:50, Scott Wood wrote:
> On 01/09/2013 10:48:47 AM, Alexander Graf wrote:
>> On 09.01.2013, at 17:26, Christoffer Dall wrote:
>> > Renames the KVM_SET_DEVICE_ADDRESS to KVM_ARM_SET_DEVICE_ADDR
>> > to make it obvious that this
On Wed, Jan 9, 2013 at 6:26 AM, Pandarathil, Vijaymohan R
wrote:
> - Create eventfd per vfio device assigned to a guest and register an
> event handler
>
> - This fd is passed to the vfio_pci driver through a new ioctl
>
> - When the device encounters an error, th
Am 09.01.2013 um 22:15 schrieb Scott Wood :
> On 01/09/2013 02:12:16 PM, Alexander Graf wrote:
>> On 09.01.2013, at 20:50, Scott Wood wrote:
>> > On 01/09/2013 10:48:47 AM, Alexander Graf wrote:
>> >> On 09.01.2013, at 17:26, Christoffer Dall wrote:
>> >> > Renames the KVM_SET_DEVICE_ADDRESS to
On 01/09/2013 03:37:20 PM, Alexander Graf wrote:
Am 09.01.2013 um 22:15 schrieb Scott Wood :
> I get that there's a tradeoff between getting something in now,
versus waiting until the API is more refined. Tagging it with a
particular ISA seems like an odd way of saying "soon to be
depre
On Wed, Jan 9, 2013 at 5:10 PM, Scott Wood wrote:
> On 01/09/2013 03:37:20 PM, Alexander Graf wrote:
>>
>>
>>
>> Am 09.01.2013 um 22:15 schrieb Scott Wood :
>>
>> > I get that there's a tradeoff between getting something in now, versus
>> > waiting until the API is more refined. Tagging it with a
On 09.01.2013, at 23:10, Scott Wood wrote:
> On 01/09/2013 03:37:20 PM, Alexander Graf wrote:
>> Am 09.01.2013 um 22:15 schrieb Scott Wood :
>> > I get that there's a tradeoff between getting something in now, versus
>> > waiting until the API is more refined. Tagging it with a particular ISA
On 09.01.2013, at 23:26, Christoffer Dall wrote:
> On Wed, Jan 9, 2013 at 5:10 PM, Scott Wood wrote:
>> On 01/09/2013 03:37:20 PM, Alexander Graf wrote:
>>>
>>>
>>>
>>> Am 09.01.2013 um 22:15 schrieb Scott Wood :
>>>
I get that there's a tradeoff between getting something in now, versus
Marcelo Tosatti wrote on 2013-01-09:
> On Wed, Jan 09, 2013 at 08:07:31AM +, Zhang, Yang Z wrote:
if(check_request(KVM_REQ_, )) {
ioapic_lock(); (*)
update local EOI exit bitmap from IOAPIC
>> In my patch, it traverses IOAPIC entry once and o
On 01/10/2013 04:25 AM, Chegu Vinod wrote:
>
> Hello,
>
> 'am running into an issue with the latest bits. [ Pl. see below. The
> vhost thread seems to be getting
> stuck while trying to memcopy...perhaps a bad address?. ] Wondering
> if this is a known issue or
> some recent regression ?
Hi:
Loo
On Sat, Dec 15, 2012 at 01:06:13PM +1100, Benjamin Herrenschmidt wrote:
> On Sat, 2012-12-15 at 01:46 +0100, Alexander Graf wrote:
> > On 05.11.2012, at 04:18, Paul Mackerras wrote:
> >
> > > This series implements in-kernel emulation of the XICS interrupt
> > > controller specified in the PAPR sp
On 1/9/2013 8:35 PM, Jason Wang wrote:
On 01/10/2013 04:25 AM, Chegu Vinod wrote:
Hello,
'am running into an issue with the latest bits. [ Pl. see below. The
vhost thread seems to be getting
stuck while trying to memcopy...perhaps a bad address?. ] Wondering
if this is a known issue or
some re
> -Original Message-
> From: Gleb Natapov [mailto:g...@redhat.com]
> Sent: Monday, January 07, 2013 5:21 PM
> To: Ren, Yongjie
> Cc: Stefan Pietsch; kvm@vger.kernel.org
> Subject: Re: Installation of Windows 8 hangs with KVM
>
> On Mon, Jan 07, 2013 at 09:13:37AM +, Ren, Yongjie wrote:
On Wednesday, January 09, 2013 11:26:33 PM Jason Wang wrote:
> On 01/09/2013 06:01 PM, Wanlong Gao wrote:
> > On 01/09/2013 05:30 PM, Jason Wang wrote:
> >> On 01/09/2013 04:23 PM, Wanlong Gao wrote:
> >>> On 01/08/2013 06:14 PM, Jason Wang wrote:
> On 01/08/2013 06:00 PM, Wanlong Gao wrote:
>
On 01/10/2013 02:43 PM, Jason Wang wrote:
> On Wednesday, January 09, 2013 11:26:33 PM Jason Wang wrote:
>> On 01/09/2013 06:01 PM, Wanlong Gao wrote:
>>> On 01/09/2013 05:30 PM, Jason Wang wrote:
On 01/09/2013 04:23 PM, Wanlong Gao wrote:
> On 01/08/2013 06:14 PM, Jason Wang wrote:
>>
Stefan Hajnoczi writes:
> On Wed, Jan 09, 2013 at 03:55:23PM +0800, ak...@redhat.com wrote:
>> From: Amos Kong
>>
>> VIRTIO_NET_F_VTRL_VQ -> VIRTIO_NET_F_CTRL_VQ
>> VIRTIO_NET_CTRL_MQ is defined to 4 in kernel code
>>
>> Signed-off-by: Amos Kong
>> ---
>> virtio-spec.lyx | 4 ++--
>> 1 file
On Thursday, January 10, 2013 02:49:14 PM Wanlong Gao wrote:
> On 01/10/2013 02:43 PM, Jason Wang wrote:
> > On Wednesday, January 09, 2013 11:26:33 PM Jason Wang wrote:
> >> On 01/09/2013 06:01 PM, Wanlong Gao wrote:
> >>> On 01/09/2013 05:30 PM, Jason Wang wrote:
> On 01/09/2013 04:23 PM, Wa
From: Yang Zhang
APIC virtualization is a new feature which can eliminate most of VM exit
when vcpu handle a interrupt:
APIC register virtualization:
APIC read access doesn't cause APIC-access VM exits.
APIC write becomes trap-like.
Virtual interrupt delivery:
Virtual in
- APIC read doesn't cause VM-Exit
- APIC write becomes trap-like
Signed-off-by: Kevin Tian
Signed-off-by: Yang Zhang
---
arch/x86/include/asm/vmx.h |2 ++
arch/x86/kvm/lapic.c | 15 +++
arch/x86/kvm/lapic.h |2 ++
arch/x86/kvm/vmx.c | 33 +
From: Yang Zhang
Virtual interrupt delivery avoids KVM to inject vAPIC interrupts
manually, which is fully taken care of by the hardware. This needs
some special awareness into existing interrupr injection path:
- for pending interrupt, instead of direct injection, we may need
update architect
From: Yang Zhang
basically to benefit from apicv, we need to enable virtualized x2apic mode.
Currently, we only enable it when guest is really using x2apic.
Also, clear MSR bitmap for corresponding x2apic MSRs when guest enabled x2apic:
0x800 - 0x8ff: no read intercept for apicv register vir
On Thu, Jan 10, 2013 at 03:26:07PM +0800, Yang Zhang wrote:
> From: Yang Zhang
>
> basically to benefit from apicv, we need to enable virtualized x2apic mode.
> Currently, we only enable it when guest is really using x2apic.
>
> Also, clear MSR bitmap for corresponding x2apic MSRs when guest ena
89 matches
Mail list logo
