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 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
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
Signed-off-by: Yang Zhang
Teste
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 POS
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
vmcs_field_to_o
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
Signe
From: "Aneesh Kumar K.V"
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 adds the missing unlock.
Repor
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
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_mast
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
diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
index 0033df3..50b6
On 03/11/2014 12:29, Cornelia Huck wrote:
> From: Sebastian Ott
>
> 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 *drv;
>
> Signed-o
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 hook
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
>> initial
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
Signed-off-by: Paolo Bonzini
---
arch/x86/kvm
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 ENOE
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
Applied, thanks. This makes vmx_init and svm_init more similar, which
is ni
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)
> d
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 c
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,
>>
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 s
20 matches
Mail list logo
