On 11/03/2014 05:23 PM, Michael S. Tsirkin wrote:
On Wed, Oct 29, 2014 at 09:38:41AM +0100, Cédric Le Goater wrote:
This patchset adds a VHOST_VRING_F_BYTESWAP flag to inform the host
to byteswap data of the vring when the guest and the host have a
different endian order. The flag is stored
On 11/03/2014 01:37 PM, Zhang Haoyu wrote:
Hi, all
I used base image A to clone so many vm,
after running for months, each vm has its own private applications and data,
which maybe different from each other.
Now, I want to install some applications for all of the clones,
what should I do?
Am 04.10.2014 um 00:16 schrieb Paolo Bonzini:
Il 03/10/2014 21:39, Eduardo Habkost ha scritto:
Changes v2 - v3:
* None. This is just a rebase against latest qemu.git master (commit
b00a0dd)
Changes v1 - v2:
* Commit message and comment changes.
* Update compat code to change pc-*-2.1,
Extending the context we have:
if (vcpus_matched gtod-clock.vclock_mode == VCLOCK_TSC)
if (!ka-use_master_clock)
do_request = 1;
- if (!vcpus_matched ka-use_master_clock)
+ if (ka-use_master_clock)
do_request = 1;
On 28/10/2014 03:14, Tiejun Chen wrote:
Instead of vmx_init(), actually it would make reasonable sense to do
anything specific to vmx hardware setting in vmx_x86_ops-hardware_setup().
Signed-off-by: Tiejun Chen tiejun.c...@intel.com
Applied, thanks. This makes vmx_init and svm_init more
On 31/10/2014 07:45, Tiejun Chen wrote:
Return value should be as bool type as this function declaration,
static inline bool vmcs12_read_any().
Actually, bool return values are in general a bad idea if you mean
success/fail, especially if you can use POSIX error codes such as in
this case
Return a negative error code instead, and WARN() when we should be covering
the entire 2-bit space of vmcs_field_type's return value. For increased
robustness, add a BUILD_BUG_ON checking the range of vmcs_field_to_offset.
Suggested-by: Tiejun Chen tiejun.c...@intel.com
Signed-off-by: Paolo
On 11/03/2014 12:17 PM, Radim Krčmář wrote:
2014-10-31 12:05-0400, Wei Huang:
This patch implemented vPMU for AMD platform. The design piggybacks
on the existing Intel structs (kvm_pmu and kvm_pmc), but only uses
the parts of generic counters. The kvm_pmu_ops interface is also
initialized in
On 11/03/2014 12:36 PM, Radim Krčmář wrote:
2014-10-31 12:05-0400, Wei Huang:
This patch converts existing pmu.c into Intel specific code and hooks
up with the PMU interface using the following steps:
- Convert pmu.c to pmu_intel.c; All public PMU functions are renamed
and hooked up with
On 03/11/2014 12:29, Cornelia Huck wrote:
From: Sebastian Ott seb...@linux.vnet.ibm.com
Fix this warning:
drivers/s390/kvm/virtio_ccw.c: In function ‘virtio_ccw_int_handler’:
drivers/s390/kvm/virtio_ccw.c:891:24: warning: unused variable ‘drv’
[-Wunused-variable]
struct virtio_driver
On Tue, Nov 04, 2014 at 06:10:34PM +0100, Paolo Bonzini wrote:
Extending the context we have:
if (vcpus_matched gtod-clock.vclock_mode == VCLOCK_TSC)
if (!ka-use_master_clock)
do_request = 1;
- if (!vcpus_matched ka-use_master_clock)
+
When the guest writes to the TSC, the masterclock TSC copy must be
updated as well along with the TSC_OFFSET update, otherwise a negative
tsc_timestamp is calculated at kvm_guest_time_update.
Signed-off-by: Marcelo Tosatti mtosa...@redhat.com
diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
On Mon, Nov 03, 2014 at 04:57:18PM -0800, Owen Hofmann wrote:
kvm updates the version number for the guest paravirt clock structure by
incrementing the version of its private copy. It does not read the guest
version, so will write version = 2 in the first update for every new VM,
including
From: Aneesh Kumar K.V aneesh.ku...@linux.vnet.ibm.com
In kvm_test_clear_dirty(), if we find an invalid HPTE we move on to the
next HPTE without unlocking the invalid one. In fact we should never
find an invalid and unlocked HPTE in the rmap chain, but for robustness
we should unlock it. This
On 2014/11/5 1:33, Paolo Bonzini wrote:
Return a negative error code instead, and WARN() when we should be covering
the entire 2-bit space of vmcs_field_type's return value. For increased
robustness, add a BUILD_BUG_ON checking the range of vmcs_field_to_offset.
Suggested-by: Tiejun Chen
On 2014/11/5 9:43, Chen, Tiejun wrote:
On 2014/11/5 1:33, Paolo Bonzini wrote:
Return a negative error code instead, and WARN() when we should be
covering
the entire 2-bit space of vmcs_field_type's return value. For increased
robustness, add a BUILD_BUG_ON checking the range of
On 2014/11/5 1:34, Paolo Bonzini wrote:
On 31/10/2014 07:45, Tiejun Chen wrote:
Return value should be as bool type as this function declaration,
static inline bool vmcs12_read_any().
Actually, bool return values are in general a bad idea if you mean
success/fail, especially if you can use
A bug was reported as follows: when running Windows 7 32-bit guests on qemu-kvm,
sometimes the guests run into blue screen during reboot. The problem was that a
guest's RVI was not cleared when it rebooted. This patch has fixed the problem.
Signed-off-by: Wei Wang wei.w.w...@intel.com
On 2014/11/5 10:53, Wei Wang wrote:
A bug was reported as follows: when running Windows 7 32-bit guests on qemu-kvm,
sometimes the guests run into blue screen during reboot. The problem was that a
guest's RVI was not cleared when it rebooted. This patch has fixed the problem.
Signed-off-by: Wei
On 05/11/2014 2:14, Tiejun Chen wrote:
A bug was reported as follows: when running Windows 7 32-bit guests on
qemu-kvm, sometimes the guests run into blue screen during reboot. The
problem was that a guest's RVI was not cleared when it rebooted. This
patch has fixed the problem.
On 11/03/2014 05:23 PM, Michael S. Tsirkin wrote:
On Wed, Oct 29, 2014 at 09:38:41AM +0100, Cédric Le Goater wrote:
This patchset adds a VHOST_VRING_F_BYTESWAP flag to inform the host
to byteswap data of the vring when the guest and the host have a
different endian order. The flag is stored
From: Aneesh Kumar K.V aneesh.ku...@linux.vnet.ibm.com
In kvm_test_clear_dirty(), if we find an invalid HPTE we move on to the
next HPTE without unlocking the invalid one. In fact we should never
find an invalid and unlocked HPTE in the rmap chain, but for robustness
we should unlock it. This
22 matches
Mail list logo
