On Sat, May 21, 2011 at 01:23:27AM -0300, Lucas Meneghel Rodrigues wrote:
> This patch adds some helpers to assist virt test to setup the bridge or
> macvtap based guest networking.
>
> Changes from v1:
> * Fixed undefined variable errors on the exception class definitions
>
> Signed-off-by: Jas
On 05/21/2011 02:59 AM, Lucas Meneghel Rodrigues wrote:
On Thu, 2011-05-19 at 18:24 +0800, fy...@redhat.com wrote:
From: Feng Yang
Current working folder for
unattended_install_config = UnattendedInstallConfig(test, params)
unattended_install_config.setup()
must be kvm folder.
This i
On Sun, 22 May 2011 15:10:08 +0300, "Michael S. Tsirkin"
wrote:
> On Sat, May 21, 2011 at 11:49:59AM +0930, Rusty Russell wrote:
> > On Fri, 20 May 2011 02:11:56 +0300, "Michael S. Tsirkin"
> > wrote:
> > > Current code might introduce a lot of latency variation
> > > if there are many pending
On Thu, May 12, 2011, Gleb Natapov wrote about "Re: [PATCH 0/30] nVMX: Nested
VMX, v9":
> > But if my interpretation of the code is correct, SVM isn't much closer
> > than VMX to the goal of moving this logic to x86.c. When some logic is
> > moved there, both SVM and VMX code will need to change -
Hi, this is my first try to get a working full virtualized KVM guest with one
real PCI device. I have the Asrock 890FX Deluxe3 with a Phenom II X4 945 which
both shold have IOMMU support. I did the steps described on
http://www.linux-kvm.org/page/How_to_assign_devices_with_VT-d_in_KVM but it
seems
On Thu, May 19, 2011 at 05:00:17PM +0930, Rusty Russell wrote:
> On Thu, 19 May 2011 01:01:25 +0300, "Michael S. Tsirkin"
> wrote:
> > The patch virtio_net: limit xmit polling
> > got the logic reversed: it polled while we had
> > capacity not while ring was empty.
> >
> > Fix it up and clean u
On 05/22/2011 06:44 PM, Anthony Liguori wrote:
At any rate, I'm fairly sure it doesn't belong in the MemoryRegion
structure.
Since it isn't a global property, where does it belong?
The chipset should have an intercept in the dispatch path that
enforces this (this assumes hierarchical di
On 05/22/2011 06:46 PM, Anthony Liguori wrote:
MemoryRegion *is* the dispatch path. Only done declaratively so we can
flatten it whenever it changes.
We don't want dispatch to be 100% declarative. That's what will cause
the API to get horrendously ugly.
An example is PCI-bus level endianne
On 05/22/2011 01:39 AM, Avi Kivity wrote:
On 05/20/2011 05:46 PM, Anthony Liguori wrote:
On 05/20/2011 09:40 AM, Richard Henderson wrote:
On 05/20/2011 07:31 AM, Anthony Liguori wrote:
But is this a characteristic of devices or is this a characteristic
of the chipset/CPU?
Chipset.
So if th
On 05/22/2011 01:38 AM, Avi Kivity wrote:
On 05/20/2011 05:31 PM, Anthony Liguori wrote:
Several alpha system chips MCE when accessed with incorrect sizes.
E.g. only 64-bit accesses are allowed.
But is this a characteristic of devices or is this a characteristic of
the chipset/CPU?
The chip
On 05/22/2011 06:32 PM, Blue Swirl wrote:
>
> Can you suggest an alternative naming for the API?
How about
memory_region_container_init()
memory_region_add()
I'm neutral. If someone seconds this, I'll make it so.
--
I have a truly marvellous patch that fixes the bug which this
signature is
qemu-kvm-0.14.1 is now available. This release is based on the upstream
qemu 0.14.1, plus kvm-specific enhancements. Please see the original
qemu 0.14.1 release announcement for details.
This release can be used with the kvm kernel modules provided by your
distribution kernel, or by the modules
On Sun, May 22, 2011 at 3:18 PM, Avi Kivity wrote:
> On 05/22/2011 03:06 PM, Blue Swirl wrote:
>>
>> On Sun, May 22, 2011 at 2:36 PM, Avi Kivity wrote:
>> > On 05/22/2011 12:32 PM, Blue Swirl wrote:
>> >>
>> >> >> > +void memory_region_add_coalescing(MemoryRegion *mr,
>> >> >> >
On 05/21/2011 07:06 AM, Takuya Yoshikawa wrote:
From: Takuya Yoshikawa
A trivial typo was found in the following commit:
commit 7753ed6043bfce55dc0c407490896632014b677e
KVM: x86 emulator: drop vcpu argument from segment/gdt/idt callbacks
When the table indicator flag is set, when the sele
On 05/22/2011 03:06 PM, Blue Swirl wrote:
On Sun, May 22, 2011 at 2:36 PM, Avi Kivity wrote:
> On 05/22/2011 12:32 PM, Blue Swirl wrote:
>>
>> >>> +void memory_region_add_coalescing(MemoryRegion *mr,
>> >>> + target_phys_addr_t offset,
>> >>
On Sat, May 21, 2011 at 11:49:59AM +0930, Rusty Russell wrote:
> On Fri, 20 May 2011 02:11:56 +0300, "Michael S. Tsirkin"
> wrote:
> > Current code might introduce a lot of latency variation
> > if there are many pending bufs at the time we
> > attempt to transmit a new one. This is bad for
> > r
On Sun, May 22, 2011 at 2:36 PM, Avi Kivity wrote:
> On 05/22/2011 12:32 PM, Blue Swirl wrote:
>>
>> >> > +void memory_region_add_coalescing(MemoryRegion *mr,
>> >> > + target_phys_addr_t offset,
>> >> > + target_phys_ad
On 05/22/2011 12:32 PM, Blue Swirl wrote:
>> >+void memory_region_add_coalescing(MemoryRegion *mr,
>> >+ target_phys_addr_t offset,
>> >+ target_phys_addr_t size);
>> >+/* Disable MMIO coalescing for the region.
On 05/22/2011 03:00 PM, Ingo Molnar wrote:
>
> * Ingo Molnar wrote:
>
>>
>> * tip-bot for Cyrill Gorcunov wrote:
>>
>>> diff --git a/tools/perf/feature-tests.mak
>>> b/tools/kvm/config/feature-tests.mak
>>> similarity index 83%
>>> copy from tools/perf/feature-tests.mak
>>> copy to tools/kvm/c
On 05/22/2011 02:58 PM, Ingo Molnar wrote:
>
> * tip-bot for Cyrill Gorcunov wrote:
>
>> diff --git a/tools/perf/feature-tests.mak
>> b/tools/kvm/config/feature-tests.mak
>> similarity index 83%
>> copy from tools/perf/feature-tests.mak
>> copy to tools/kvm/config/feature-tests.mak
>
> Btw, no
* Ingo Molnar wrote:
>
> * tip-bot for Cyrill Gorcunov wrote:
>
> > diff --git a/tools/perf/feature-tests.mak
> > b/tools/kvm/config/feature-tests.mak
> > similarity index 83%
> > copy from tools/perf/feature-tests.mak
> > copy to tools/kvm/config/feature-tests.mak
>
> Btw, now that we have
* tip-bot for Cyrill Gorcunov wrote:
> diff --git a/tools/perf/feature-tests.mak b/tools/kvm/config/feature-tests.mak
> similarity index 83%
> copy from tools/perf/feature-tests.mak
> copy to tools/kvm/config/feature-tests.mak
Btw, now that we have feature-tests.mak it would be nice to populate
On 2011-05-20 19:17, Christoph Hellwig wrote:
> On Fri, May 20, 2011 at 07:12:39PM +0200, Jan Kiszka wrote:
>> Upstream's and qemu-kvm's kvm_cpu_exec are not logically equivalent so
>
> s/not/now/?
Oops, of course.
If there is no other need to repost, this should be fixed on merge.
Thanks,
Jan
On Sun, May 22, 2011 at 9:45 AM, Avi Kivity wrote:
> On 05/20/2011 08:59 PM, Blue Swirl wrote:
>>
>> On Thu, May 19, 2011 at 5:12 PM, Avi Kivity wrote:
>> > The memory API separates the attributes of a memory region (its size,
>> > how
>> > reads or writes are handled, dirty logging, and coales
On Wed, May 18, 2011, Marcelo Tosatti wrote about "Re: [PATCH 08/31] nVMX: Fix
local_vcpus_link handling":
> Humpf, right. OK, you can handle the x86.c usage with
>
> diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
>...
Hi Avi and Marcelo, here is a the new first patch to the nvmx patch set
Hi,
On Fri, May 20, 2011, Tian, Kevin wrote about "RE: [PATCH 07/31] nVMX:
Introduce vmcs02: VMCS used to run L2":
> Possibly we can maintain the vmcs02 pool along with L1 VMCLEAR ops, which
> is similar to the hardware behavior regarding to cleared and launched state.
If you set VMCS02_POOL_SIZ
On 05/22/2011 11:08 AM, Yang, Wei Y wrote:
> This patch matches with "[PATCH v2] Enable CPU SMEP feature support for
QEMU-KVM", no changes since v1.
>
> Enable newly documented SMEP (Supervisor Mode Execution Protection) CPU
feature in KVM module.
>
> Intel new CPU supports SMEP (Supervisor
> This patch matches with "[PATCH v2] Enable CPU SMEP feature support for
> QEMU-KVM", no changes since v1.
>
> Enable newly documented SMEP (Supervisor Mode Execution Protection) CPU
> feature in KVM module.
>
> Intel new CPU supports SMEP (Supervisor Mode Execution Protection). SMEP
> prevents
Hi,
On Sun, May 22, 2011, Tian, Kevin wrote about "RE: [PATCH 07/31] nVMX:
Introduce vmcs02: VMCS used to run L2":
> Here the vmcs02 being overridden may have been run on another processor before
> but is not vmclear-ed yet. When you resume this vmcs02 with new content on a
> separate processor,
On 05/20/2011 08:59 PM, Blue Swirl wrote:
On Thu, May 19, 2011 at 5:12 PM, Avi Kivity wrote:
> The memory API separates the attributes of a memory region (its size, how
> reads or writes are handled, dirty logging, and coalescing) from where it
> is mapped and whether it is enabled. This all
On 05/20/2011 05:06 PM, Richard Henderson wrote:
Is this structure honestly any better than 4 function pointers?
I can't see that it is, myself.
That was requested by Anthony. And in fact we have two bits of
information per access size, one is whether the access is allowed or
not, the other
31 matches
Mail list logo
