On Mon, Nov 12, 2018 at 4:00 PM, Liran Alon wrote:
>
>
>> On 12 Nov 2018, at 18:54, Daniel P. Berrangé wrote:
>>
>> On Mon, Nov 12, 2018 at 04:50:54PM +, Dr. David Alan Gilbert wrote:
>>> * Daniel P. Berrangé (berra...@redhat.com) wrote:
On Sun, Nov 04, 2018 at 11:19:57PM +0100, Paolo Bo
On Wed, Nov 7, 2018 at 4:13 PM, Liran Alon wrote:
> Ping on my last reply.
> I would like to reach to an agreement on how v3 should look like before just
> implementing what I think is right.
>
> Thanks,
> -Liran
I have no attachments to the current design. I had used a data[] blob,
because I di
On Fri, Nov 2, 2018 at 9:58 AM, Daniel P. Berrangé wrote:
> On Fri, Nov 02, 2018 at 09:44:54AM -0700, Jim Mattson via Qemu-devel wrote:
>> On Fri, Nov 2, 2018 at 5:59 AM, Liran Alon wrote:
>> >
>>
>> >>> Therefore, I don't think that we want this vers
On Fri, Nov 2, 2018 at 5:59 AM, Liran Alon wrote:
>
>>> Therefore, I don't think that we want this versioning to be based on
>>> KVM_CAP at all.
>>> It seems that we would want the process to behave as follows:
>>> 1) Mgmt-layer at dest queries dest host max supported nested_state size.
>>> (W
On Thu, Nov 1, 2018 at 8:46 PM, Liran Alon wrote:
> Hmm this makes sense.
>
> This means though that the patch I have submitted here isn't good enough.
> My patch currently assumes that when it attempts to get nested state from KVM,
> QEMU should always set nested_state->size to max size supporte
On Thu, Nov 1, 2018 at 12:07 PM, Dr. David Alan Gilbert
wrote:
> OK; the tricky thing is when you upgrade one host in a small cluster as
> you start doing an upgrade, and then once it's got it's first VM you
> can't migrate away from it until others are updated; that gets messy.
One must always
On Thu, Nov 1, 2018 at 8:56 AM, Dr. David Alan Gilbert
wrote:
> So if I have matching host kernels it should always work?
> What happens if I upgrade the source kernel to increase it's maximum
> nested size, can I force it to keep things small for some VMs?
Any change to the format of the nested
On Wed, Apr 12, 2017 at 7:54 AM, Alexander Graf wrote:
>
>
> On 12.04.17 16:34, Jim Mattson wrote:
>>
>> Actually, we have rejected commit 87c00572ba05aa8c ("kvm: x86: emulate
>> monitor and mwait instructions as nop"), so when we intercept
>> MONITOR/MWAIT, we synthesize #UD. Perhaps it is this d
Actually, we have rejected commit 87c00572ba05aa8c ("kvm: x86: emulate
monitor and mwait instructions as nop"), so when we intercept
MONITOR/MWAIT, we synthesize #UD. Perhaps it is this difference from
vanilla kvm that motivates the following idea...
Since we're still not going to report MONITOR s
This might be more useful if it could be dynamically toggled on and
off, depending on system load.
On Tue, Apr 11, 2017 at 4:45 AM, Alexander Graf wrote:
> From: "Michael S. Tsirkin"
>
> Guests that are heavy on futexes end up IPI'ing each other a lot. That
> can lead to significant slowdowns an
10 matches
Mail list logo
