> On 13 Nov 2018, at 2:07, Jim Mattson wrote:
>
> 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é
> On 12 Nov 2018, at 18:50, Dr. David Alan Gilbert wrote:
>
> * Daniel P. Berrangé (berra...@redhat.com) wrote:
>> On Sun, Nov 04, 2018 at 11:19:57PM +0100, Paolo Bonzini wrote:
>>> On 02/11/2018 17:54, Daniel P. Berrangé wrote:
We have usually followed a rule that new machine types must
> 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 Bonzini wrote:
On 02/11/2018 17:54, Daniel P.
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
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 Bonzini wrote:
> > > On 02/11/2018 17:54, Daniel P. Berrangé wrote:
> > > > We have usually followed a rule that new
On 12/11/2018 17:50, Dr. David Alan Gilbert wrote:
>> Migration has always been busted historically, so those people using
>> nested VMX already won't be hurt by not having ability to live migrate
>> their VM, but could otherwise continue using them without being forced
>> to upgrade their kernel
* Daniel P. Berrangé (berra...@redhat.com) wrote:
> On Sun, Nov 04, 2018 at 11:19:57PM +0100, Paolo Bonzini wrote:
> > On 02/11/2018 17:54, Daniel P. Berrangé wrote:
> > > We have usually followed a rule that new machine types must not
> > > affect runability of a VM on a host. IOW new machine
On Sun, Nov 04, 2018 at 11:19:57PM +0100, Paolo Bonzini wrote:
> On 02/11/2018 17:54, Daniel P. Berrangé wrote:
> > We have usually followed a rule that new machine types must not
> > affect runability of a VM on a host. IOW new machine types should
> > not introduce dependancies on specific
* Liran Alon (liran.a...@oracle.com) wrote:
>
>
> > On 8 Nov 2018, at 19:02, Paolo Bonzini wrote:
> >
> > On 08/11/2018 10:57, Liran Alon wrote:
> >>
> >>
> >>> On 8 Nov 2018, at 11:50, Paolo Bonzini wrote:
> >>>
> >>> On 08/11/2018 01:45, Jim Mattson wrote:
> I have no attachments to
On 08/11/2018 19:41, Liran Alon wrote:
> So what I plan to do is indeed to define first 4K of data as vmcs12 and next
> 4K as shadow_vmcs12.
> I will also define each of them in a separate VMState subsection that each
> will have it’s own .needed()
> method that will decide if it’s relevant to
> On 8 Nov 2018, at 19:02, Paolo Bonzini wrote:
>
> On 08/11/2018 10:57, Liran Alon wrote:
>>
>>
>>> On 8 Nov 2018, at 11:50, Paolo Bonzini wrote:
>>>
>>> On 08/11/2018 01:45, Jim Mattson wrote:
I have no attachments to the current design. I had used a data[] blob,
because I
On 08/11/2018 10:57, Liran Alon wrote:
>
>
>> On 8 Nov 2018, at 11:50, Paolo Bonzini wrote:
>>
>> On 08/11/2018 01:45, Jim Mattson wrote:
>>> I have no attachments to the current design. I had used a data[] blob,
>>> because I didn't think userspace would have any need to know what was
>>> in
> On 8 Nov 2018, at 11:50, Paolo Bonzini wrote:
>
> On 08/11/2018 01:45, Jim Mattson wrote:
>> I have no attachments to the current design. I had used a data[] blob,
>> because I didn't think userspace would have any need to know what was
>> in there. However, I am now seeing the error of my
On 08/11/2018 01:45, Jim Mattson wrote:
> I have no attachments to the current design. I had used a data[] blob,
> because I didn't think userspace would have any need to know what was
> in there. However, I am now seeing the error of my ways. For example,
> the userspace instruction emulator
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
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
> On 3 Nov 2018, at 4:02, Liran Alon wrote:
>
>
>
>> On 2 Nov 2018, at 18:39, Jim Mattson wrote:
>>
>> On Thu, Nov 1, 2018 at 8:46 PM,
On 02/11/2018 13:35, Dr. David Alan Gilbert wrote:
>>
>> Personally, I would like to say that, starting from QEMU 3.2, enabling
>> nested VMX requires a 4.20 kernel. It's a bit bold, but I think it's a
>> good way to keep some sanity. Any opinions on that?
> That seems a bit mean; there's a lot
On 02/11/2018 17:54, Daniel P. Berrangé wrote:
> We have usually followed a rule that new machine types must not
> affect runability of a VM on a host. IOW new machine types should
> not introduce dependancies on specific kernels, or hardware features
> such as CPU flags.
> Anything that requires
> On 2 Nov 2018, at 18:39, Jim Mattson wrote:
>
> 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
>>
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 versioning to be based on
>> >>> KVM_CAP at all.
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 versioning to be based on
> >>> KVM_CAP at all.
> >>> It seems that we would want the process to behave as
* Daniel P. Berrangé (berra...@redhat.com) wrote:
> On Fri, Nov 02, 2018 at 10:40:35AM +0100, Paolo Bonzini wrote:
> > On 02/11/2018 04:46, Liran Alon wrote:
> > >> On Thu, Nov1, 2018 at 09:45 AM, Jim Mattson wrote:
> > >
> > >>> On Thu, Nov 1, 2018 at 8:56 AM, Dr. David Alan Gilbert
> > >>>
On Fri, Nov 02, 2018 at 10:40:35AM +0100, Paolo Bonzini wrote:
> On 02/11/2018 04:46, Liran Alon wrote:
> >> On Thu, Nov1, 2018 at 09:45 AM, Jim Mattson wrote:
> >
> >>> On Thu, Nov 1, 2018 at 8:56 AM, Dr. David Alan Gilbert
> >>> wrote:
> >
> >>> So if I have matching host kernels it should
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.
>>>
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
> On 2 Nov 2018, at 11:40, Paolo Bonzini wrote:
>
> On 02/11/2018 04:46, Liran Alon wrote:
>>> On Thu, Nov1, 2018 at 09:45 AM, Jim Mattson wrote:
>>
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?
On Fri, Nov 02, 2018 at 12:35:05PM +, Dr. David Alan Gilbert wrote:
> * Paolo Bonzini (pbonz...@redhat.com) wrote:
> > On 02/11/2018 04:46, Liran Alon wrote:
> > >> On Thu, Nov1, 2018 at 09:45 AM, Jim Mattson wrote:
> > >
> > >>> On Thu, Nov 1, 2018 at 8:56 AM, Dr. David Alan Gilbert
> >
* Paolo Bonzini (pbonz...@redhat.com) wrote:
> On 02/11/2018 04:46, Liran Alon wrote:
> >> On Thu, Nov1, 2018 at 09:45 AM, Jim Mattson wrote:
> >
> >>> 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?
> >>>
On 02/11/2018 04:46, Liran Alon wrote:
>> On Thu, Nov1, 2018 at 09:45 AM, Jim Mattson wrote:
>
>>> 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
> On Thu, Nov1, 2018 at 09:45 AM, Jim Mattson wrote:
>> 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
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
* Liran Alon (liran.a...@oracle.com) wrote:
>
>
> > On 1 Nov 2018, at 17:56, Dr. David Alan Gilbert wrote:
> >
> > * Liran Alon (liran.a...@oracle.com) wrote:
> >>
> >>
> >>> On 1 Nov 2018, at 15:10, Dr. David Alan Gilbert
> >>> wrote:
> >>>
> >>> * Liran Alon (liran.a...@oracle.com)
> On 1 Nov 2018, at 17:56, Dr. David Alan Gilbert wrote:
>
> * Liran Alon (liran.a...@oracle.com) wrote:
>>
>>
>>> On 1 Nov 2018, at 15:10, Dr. David Alan Gilbert wrote:
>>>
>>> * Liran Alon (liran.a...@oracle.com) wrote:
> On 31 Oct 2018, at 20:59, Dr. David Alan Gilbert
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
* Liran Alon (liran.a...@oracle.com) wrote:
>
>
> > On 1 Nov 2018, at 15:10, Dr. David Alan Gilbert wrote:
> >
> > * Liran Alon (liran.a...@oracle.com) wrote:
> >>
> >>
> >>> On 31 Oct 2018, at 20:59, Dr. David Alan Gilbert
> >>> wrote:
> >>>
> >>> * Liran Alon (liran.a...@oracle.com)
> On 1 Nov 2018, at 15:10, Dr. David Alan Gilbert wrote:
>
> * Liran Alon (liran.a...@oracle.com) wrote:
>>
>>
>>> On 31 Oct 2018, at 20:59, Dr. David Alan Gilbert
>>> wrote:
>>>
>>> * Liran Alon (liran.a...@oracle.com) wrote:
> On 31 Oct 2018, at 20:19, Paolo Bonzini
* Liran Alon (liran.a...@oracle.com) wrote:
>
>
> > On 31 Oct 2018, at 20:59, Dr. David Alan Gilbert
> > wrote:
> >
> > * Liran Alon (liran.a...@oracle.com) wrote:
> >>
> >>
> >>> On 31 Oct 2018, at 20:19, Paolo Bonzini wrote:
> >>>
> >>> On 31/10/2018 19:17, Eduardo Habkost wrote:
>
> On 31 Oct 2018, at 20:59, Dr. David Alan Gilbert wrote:
>
> * Liran Alon (liran.a...@oracle.com) wrote:
>>
>>
>>> On 31 Oct 2018, at 20:19, Paolo Bonzini wrote:
>>>
>>> On 31/10/2018 19:17, Eduardo Habkost wrote:
On Wed, Oct 31, 2018 at 03:03:34AM +0200, Liran Alon wrote:
>
* Liran Alon (liran.a...@oracle.com) wrote:
>
>
> > On 31 Oct 2018, at 20:19, Paolo Bonzini wrote:
> >
> > On 31/10/2018 19:17, Eduardo Habkost wrote:
> >> On Wed, Oct 31, 2018 at 03:03:34AM +0200, Liran Alon wrote:
> >>> Ping.
> >>> Patch was submitted almost two months ago and I haven’t seen
> On 31 Oct 2018, at 20:19, Paolo Bonzini wrote:
>
> On 31/10/2018 19:17, Eduardo Habkost wrote:
>> On Wed, Oct 31, 2018 at 03:03:34AM +0200, Liran Alon wrote:
>>> Ping.
>>> Patch was submitted almost two months ago and I haven’t seen any respond
>>> for the v2 of this series.
>> Sorry for
On 31/10/2018 19:17, Eduardo Habkost wrote:
> On Wed, Oct 31, 2018 at 03:03:34AM +0200, Liran Alon wrote:
>> Ping.
>> Patch was submitted almost two months ago and I haven’t seen any respond for
>> the v2 of this series.
> Sorry for the long delay. This was on my queue of patches to be
>
On Wed, Oct 31, 2018 at 03:03:34AM +0200, Liran Alon wrote:
> Ping.
> Patch was submitted almost two months ago and I haven’t seen any respond for
> the v2 of this series.
Sorry for the long delay. This was on my queue of patches to be
reviewed, but I'm failing to keep up to the rate of
Ping.
Patch was submitted almost two months ago and I haven’t seen any respond for
the v2 of this series.
Thanks,
-Liran
> On 15 Oct 2018, at 21:10, Liran Alon wrote:
>
> Another gentle ping on v2 of this series?
> Patch was submitted a month ago.
>
> Thanks,
> -Liran
>
>> On 8 Oct 2018, at
Another gentle ping on v2 of this series?
Patch was submitted a month ago.
Thanks,
-Liran
> On 8 Oct 2018, at 20:21, Liran Alon wrote:
>
> Gentle ping on v2 of this series.
> (I noticed 1st patch of series was already applied)
>
> Thanks,
> -Liran
>
>> On 16 Sep 2018, at 15:46, Liran Alon
Gentle ping on v2 of this series.
(I noticed 1st patch of series was already applied)
Thanks,
-Liran
> On 16 Sep 2018, at 15:46, Liran Alon wrote:
>
> Hi,
>
> This series aims to add support for QEMU to be able to migrate VMs that
> are running nested hypervisors. In order to do so, it
Hi,
This series aims to add support for QEMU to be able to migrate VMs that
are running nested hypervisors. In order to do so, it utilizes the new
IOCTLs introduced in KVM commit 8fcc4b5923af ("kvm: nVMX: Introduce
KVM_CAP_NESTED_STATE") which were created for this purpose.
1st patch is not
46 matches
Mail list logo
