* Liran Alon (liran.a...@oracle.com) wrote:
>
> > On 6 Jun 2019, at 16:31, Dr. David Alan Gilbert wrote:
> >
> >>>
> >>> So we still need to tie subsections to machine types; that way
> >>> you don't send them to old qemu's and there for you don't have the
> >>> problem of the qemu receiving
> On 6 Jun 2019, at 16:31, Dr. David Alan Gilbert wrote:
>
>>>
>>> So we still need to tie subsections to machine types; that way
>>> you don't send them to old qemu's and there for you don't have the
>>> problem of the qemu receiving something it doesn't know.
>>
>> I agree that if there is
* Liran Alon (liran.a...@oracle.com) wrote:
>
>
> > On 6 Jun 2019, at 14:07, Dr. David Alan Gilbert wrote:
> > It's tricky; for distro-based users, hitting 'update' and getting both
> > makes a lot of sense; but as you say you ened to let them do stuff
> > individually if they want to, so
On Thu, Jun 06, 2019 at 01:09:56PM +0300, Liran Alon wrote:
> First, machine-type express the set of vHW behaviour and properties that is
> exposed to guest.
> Therefore, machine-type shouldn’t change for a given guest lifetime
> (including Live-Migrations).
> Otherwise, guest will experience
> On 6 Jun 2019, at 14:07, Dr. David Alan Gilbert wrote:
>
> * Liran Alon (liran.a...@oracle.com) wrote:
>>
>>
>>> On 6 Jun 2019, at 13:39, Dr. David Alan Gilbert wrote:
>>>
>>> * Liran Alon (liran.a...@oracle.com) wrote:
> On 6 Jun 2019, at 12:23, Dr. David Alan Gilbert
* Liran Alon (liran.a...@oracle.com) wrote:
>
>
> > On 6 Jun 2019, at 13:39, Dr. David Alan Gilbert wrote:
> >
> > * Liran Alon (liran.a...@oracle.com) wrote:
> >>
> >>
> >>> On 6 Jun 2019, at 12:23, Dr. David Alan Gilbert
> >>> wrote:
> >>>
> >>> * Liran Alon (liran.a...@oracle.com)
> On 6 Jun 2019, at 13:39, Dr. David Alan Gilbert wrote:
>
> * Liran Alon (liran.a...@oracle.com) wrote:
>>
>>
>>> On 6 Jun 2019, at 12:23, Dr. David Alan Gilbert wrote:
>>>
>>> * Liran Alon (liran.a...@oracle.com) wrote:
> On 6 Jun 2019, at 11:42, Dr. David Alan Gilbert
* Liran Alon (liran.a...@oracle.com) wrote:
>
>
> > On 6 Jun 2019, at 12:23, Dr. David Alan Gilbert wrote:
> >
> > * Liran Alon (liran.a...@oracle.com) wrote:
> >>
> >>
> >>> On 6 Jun 2019, at 11:42, Dr. David Alan Gilbert
> >>> wrote:
> >>>
> >>> * Liran Alon (liran.a...@oracle.com)
> On 6 Jun 2019, at 12:23, Dr. David Alan Gilbert wrote:
>
> * Liran Alon (liran.a...@oracle.com) wrote:
>>
>>
>>> On 6 Jun 2019, at 11:42, Dr. David Alan Gilbert wrote:
>>>
>>> * Liran Alon (liran.a...@oracle.com) wrote:
Hi,
Looking at QEMU source code, I am puzzled
* Liran Alon (liran.a...@oracle.com) wrote:
>
>
> > On 6 Jun 2019, at 11:42, Dr. David Alan Gilbert wrote:
> >
> > * Liran Alon (liran.a...@oracle.com) wrote:
> >> Hi,
> >>
> >> Looking at QEMU source code, I am puzzled regarding how migration
> >> backwards compatibility is preserved
> On 6 Jun 2019, at 11:42, Dr. David Alan Gilbert wrote:
>
> * Liran Alon (liran.a...@oracle.com) wrote:
>> Hi,
>>
>> Looking at QEMU source code, I am puzzled regarding how migration backwards
>> compatibility is preserved regarding X86CPU.
>>
>> As I understand it, fields that are based
* Liran Alon (liran.a...@oracle.com) wrote:
> Hi,
>
> Looking at QEMU source code, I am puzzled regarding how migration backwards
> compatibility is preserved regarding X86CPU.
>
> As I understand it, fields that are based on KVM capabilities and guest
> runtime usage are defined in VMState
Hi,
Looking at QEMU source code, I am puzzled regarding how migration backwards
compatibility is preserved regarding X86CPU.
As I understand it, fields that are based on KVM capabilities and guest runtime
usage are defined in VMState subsections in order to not send them if not
necessary.
13 matches
Mail list logo
