On 23 January 2014 18:14, Christoffer Dall wrote:
> On Thu, Jan 23, 2014 at 04:50:18PM -0800, Victor Kamensky wrote:
>> On 23 January 2014 12:45, Christoffer Dall
>> wrote:
>> > On Thu, Jan 23, 2014 at 08:25:35AM -0800, Victor Kamensky wrote:
>> >> On 23 January 2014 07:33, Peter Maydell wrote:
https://bugzilla.kernel.org/show_bug.cgi?id=69361
--- Comment #3 from Zhou, Chao ---
Created attachment 123261
--> https://bugzilla.kernel.org/attachment.cgi?id=123261&action=edit
host-cmdline
--
You are receiving this mail because:
You are watching the assignee of the bug.
--
To unsubscribe
https://bugzilla.kernel.org/show_bug.cgi?id=69361
--- Comment #2 from Zhou, Chao ---
Created attachment 123251
--> https://bugzilla.kernel.org/attachment.cgi?id=123251&action=edit
host-serial
--
You are receiving this mail because:
You are watching the assignee of the bug.
--
To unsubscribe f
https://bugzilla.kernel.org/show_bug.cgi?id=69361
--- Comment #1 from Zhou, Chao ---
Created attachment 123241
--> https://bugzilla.kernel.org/attachment.cgi?id=123241&action=edit
host-dmesg
--
You are receiving this mail because:
You are watching the assignee of the bug.
--
To unsubscribe fr
https://bugzilla.kernel.org/show_bug.cgi?id=69361
Bug ID: 69361
Summary: Host call trace and guest hang after create guest.
Product: Virtualization
Version: unspecified
Kernel Version: 3.13.0
Hardware: All
OS: Linux
On Thu, Jan 23, 2014 at 04:50:18PM -0800, Victor Kamensky wrote:
> On 23 January 2014 12:45, Christoffer Dall
> wrote:
> > On Thu, Jan 23, 2014 at 08:25:35AM -0800, Victor Kamensky wrote:
> >> On 23 January 2014 07:33, Peter Maydell wrote:
> >> > On 23 January 2014 15:06, Victor Kamensky
> >>
On 23 January 2014 12:45, Christoffer Dall wrote:
> On Thu, Jan 23, 2014 at 08:25:35AM -0800, Victor Kamensky wrote:
>> On 23 January 2014 07:33, Peter Maydell wrote:
>> > On 23 January 2014 15:06, Victor Kamensky
>> > wrote:
>> >> In [1] I wrote
>> >>
>> >> "I don't see why you so attached to
On 23 January 2014 08:25, Victor Kamensky wrote:
> On 23 January 2014 07:33, Peter Maydell wrote:
>> On 23 January 2014 15:06, Victor Kamensky wrote:
>>> In [1] I wrote
>>>
>>> "I don't see why you so attached to desire to describe
>>> data part of memory transaction as just one of int
>>> types
On 23 January 2014 23:46, Christoffer Dall wrote:
> The KVM API documentation is not clear about the semantics of the data
> field on the mmio struct on the kvm_run struct.
>
> This has become problematic when supporting ARM guests on big-endian
> host systems with guests of both endianness types,
The KVM API documentation is not clear about the semantics of the data
field on the mmio struct on the kvm_run struct.
This has become problematic when supporting ARM guests on big-endian
host systems with guests of both endianness types, because it is unclear
how the data should be exported to us
On Wed, Jan 22, 2014 at 02:27:29PM +0530, Anup Patel wrote:
[...]
>
> Thanks for the info on QEMU side handling of MMIO data.
>
> I was not aware that we would be only have "target endian = LE"
> for ARM/ARM64 in QEMU. I think Marc Z had mentioned similar
> thing about MMIO this in our previous
On Thu, Jan 23, 2014 at 08:25:35AM -0800, Victor Kamensky wrote:
> On 23 January 2014 07:33, Peter Maydell wrote:
> > On 23 January 2014 15:06, Victor Kamensky
> > wrote:
> >> In [1] I wrote
> >>
> >> "I don't see why you so attached to desire to describe
> >> data part of memory transaction as
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 01/23/2014 08:33 PM, Dave Hansen wrote:
> On 01/23/2014 10:55 AM, Dave Hansen wrote:
>> On 01/21/2014 08:38 AM, Toralf Förster wrote:
>>> Jan 21 17:18:57 n22 kernel: INFO: rcu_sched self-detected stall on CPU { 2}
>>> (t=60001 jiffies g=18494 c=
Jason, Stefan ... thank you so much.
At a glance, disabling Nagle algorithm made the hundred thousands
"20ms" delays to dissapear suddenly, tomorrow we are gonna made a
"whole day" test again, and test client connectivity against "NginX
and Memcached" to see if, because of the traffic we have (hund
On 01/23/2014 10:55 AM, Dave Hansen wrote:
> On 01/21/2014 08:38 AM, Toralf Förster wrote:
>> Jan 21 17:18:57 n22 kernel: INFO: rcu_sched self-detected stall on CPU { 2}
>> (t=60001 jiffies g=18494 c=18493 q=183951)
>> Jan 21 17:18:57 n22 kernel: sending NMI to all CPUs:
>> Jan 21 17:18:57 n22 ke
On 01/21/2014 08:38 AM, Toralf Förster wrote:
> Jan 21 17:18:57 n22 kernel: INFO: rcu_sched self-detected stall on CPU { 2}
> (t=60001 jiffies g=18494 c=18493 q=183951)
> Jan 21 17:18:57 n22 kernel: sending NMI to all CPUs:
> Jan 21 17:18:57 n22 kernel: NMI backtrace for cpu 2
> Jan 21 17:18:57 n
On 2014-01-23 17:34, Jonas Pfoh wrote:
> Hello,
>
> I am currently working on a project involving KVM and have been making use
> Jan's kvm-kmod repository. I receive the below error when I attempt to
> compile with the most recent version. My question is simply if this is
> something anyone i
Il 23/01/2014 18:08, Marcelo Tosatti ha scritto:
On Thu, Jan 23, 2014 at 06:12:51PM +1100, Vadim Rozenfeld wrote:
Vadim Rozenfeld (2):
mark hyper-v hypercall page as dirty
mark hyper-v vapic assist page as dirty
arch/x86/kvm/x86.c | 7 +--
1 file changed, 5 insertions(+), 2 deletions(-
Hi Linus,
The following changes since commit 319e2e3f63c348a9b66db4667efa73178e18b17d:
Linux 3.13-rc4 (2013-12-15 12:31:33 -0800)
are available in the git repository at:
git://github.com/awilliam/linux-vfio.git tags/vfio-v3.14-rc1
for you to fetch changes up to 3be3a074cf5ba641529d8fdae0e0
On Thu, Jan 23, 2014 at 06:12:51PM +1100, Vadim Rozenfeld wrote:
> Vadim Rozenfeld (2):
> mark hyper-v hypercall page as dirty
> mark hyper-v vapic assist page as dirty
>
> arch/x86/kvm/x86.c | 7 +--
> 1 file changed, 5 insertions(+), 2 deletions(-)
>
> --
> 1.8.1.4
Reviewed-by: Marc
Hello,
I am currently working on a project involving KVM and have been making use
Jan's kvm-kmod repository. I receive the below error when I attempt to compile
with the most recent version. My question is simply if this is something
anyone is aware of or has any suggestions for before I go p
On 23 January 2014 07:33, Peter Maydell wrote:
> On 23 January 2014 15:06, Victor Kamensky wrote:
>> In [1] I wrote
>>
>> "I don't see why you so attached to desire to describe
>> data part of memory transaction as just one of int
>> types. If we are talking about bunch of hypothetical
>> cases i
On 23 January 2014 15:06, Victor Kamensky wrote:
> In [1] I wrote
>
> "I don't see why you so attached to desire to describe
> data part of memory transaction as just one of int
> types. If we are talking about bunch of hypothetical
> cases imagine such bus that allow transaction with
> size of 6
On 23 January 2014 02:23, Peter Maydell wrote:
> On 23 January 2014 00:22, Victor Kamensky wrote:
>> Peter, could I please ask you a favor. Could you please
>> stop deleting pieces of your and my previous responses
>> when you reply.
>
> No, sorry. It produces excessively long and totally unreada
On Wed, 22 Jan 2014 20:25:05 -0800
Victor Kamensky wrote:
> Hi Alex,
>
> Sorry, for delayed reply, I was focusing on discussion
> with Peter. Hope you and other folks may get something
> out of it :).
>
> Please see responses inline
>
> On 22 January 2014 02:52, Alexander Graf wrote:
> >
> >
Il 17/01/2014 14:44, Christian Borntraeger ha scritto:
Paolo,
the following changes since commit 26a865f4aa8e66a6d94958de7656f7f1b03c6c56:
KVM: VMX: fix use after free of vmx->loaded_vmcs (2014-01-08 19:14:08 -0200)
are available in the git repository at:
git://git.kernel.org/pub/scm/linu
On 23.01.2014, at 05:25, Victor Kamensky wrote:
> Hi Alex,
>
> Sorry, for delayed reply, I was focusing on discussion
> with Peter. Hope you and other folks may get something
> out of it :).
>
> Please see responses inline
>
> On 22 January 2014 02:52, Alexander Graf wrote:
>>
>> On 22.01.2
On 23 January 2014 00:22, Victor Kamensky wrote:
> Peter, could I please ask you a favor. Could you please
> stop deleting pieces of your and my previous responses
> when you reply.
No, sorry. It produces excessively long and totally unreadable
emails for everybody else if people don't trim for c
On 2014-01-22 17:29, Paolo Bonzini wrote:
> After KVM commit 8a3caa6d74597c2a083f7c87f866891a0b12540b, kvm-kmod
> is broken in weird ways (for me it breaks every other time kvm is
> loaded, but only with ept=0...).
>
> The reason is that, after this commit, empty_zero_page is expected
> to be page
29 matches
Mail list logo
