* Paolo Bonzini wrote:
> > Paolo, how stable, non-rebasing are the KVM tree commits?
>
> Whatever ends in linux-next is stable. I have a separate rebasing branch,
> but it's not part of linux-next by design.
Ok, that's nice!
> > Or should we keep Andy's KVM patches together with the GDT patc
> Paolo, how stable, non-rebasing are the KVM tree commits?
Whatever ends in linux-next is stable. I have a separate rebasing branch,
but it's not part of linux-next by design.
> Or should we keep Andy's KVM patches together with the GDT patches? Either
> workflow works for me - it's your call
* Thomas Garnier wrote:
> > Okay, I guess I will have to wait for it to be integrated to
> > linux-next then. Or would you rather to it after this patch set is
> > added?
>
> Read your summary for the patchset of KVM cleanup, I will wait for it to
> reach
> linux-next to rebase and send the n
On Mon, Feb 20, 2017 at 9:28 AM, Thomas Garnier wrote:
> On Mon, Feb 20, 2017 at 8:56 AM, Andy Lutomirski wrote:
>> On Fri, Feb 17, 2017 at 2:01 PM, Thomas Garnier wrote:
>>> On Fri, Feb 17, 2017 at 1:00 PM, Jim Mattson wrote:
On Fri, Feb 17, 2017 at 12:11 PM, Thomas Garnier
wrote:
On Mon, Feb 20, 2017 at 8:56 AM, Andy Lutomirski wrote:
> On Fri, Feb 17, 2017 at 2:01 PM, Thomas Garnier wrote:
>> On Fri, Feb 17, 2017 at 1:00 PM, Jim Mattson wrote:
>>> On Fri, Feb 17, 2017 at 12:11 PM, Thomas Garnier
>>> wrote:
On Fri, Feb 17, 2017 at 9:49 AM, Jim Mattson wrote:
On Fri, Feb 17, 2017 at 2:01 PM, Thomas Garnier wrote:
> On Fri, Feb 17, 2017 at 1:00 PM, Jim Mattson wrote:
>> On Fri, Feb 17, 2017 at 12:11 PM, Thomas Garnier wrote:
>>> On Fri, Feb 17, 2017 at 9:49 AM, Jim Mattson wrote:
Can we use the read-only GDT here? When expanding the virtual
On Fri, Feb 17, 2017 at 12:11 PM, Thomas Garnier wrote:
> On Fri, Feb 17, 2017 at 9:49 AM, Jim Mattson wrote:
>>
>> Can we use the read-only GDT here? When expanding the virtual address
>> for 64-bit system descriptors, isn't it sufficient to check (d->s == 0
>> && d->type != 0)?
>
> We can use t
Can we use the read-only GDT here? When expanding the virtual address
for 64-bit system descriptors, isn't it sufficient to check (d->s == 0
&& d->type != 0)?
On Tue, Feb 14, 2017 at 11:42 AM, Thomas Garnier wrote:
> The KVM segment_base function is confusing. This patch replaces integers
> with
On Fri, Feb 17, 2017 at 1:00 PM, Jim Mattson wrote:
> On Fri, Feb 17, 2017 at 12:11 PM, Thomas Garnier wrote:
>> On Fri, Feb 17, 2017 at 9:49 AM, Jim Mattson wrote:
>>>
>>> Can we use the read-only GDT here? When expanding the virtual address
>>> for 64-bit system descriptors, isn't it sufficien
On Fri, Feb 17, 2017 at 9:49 AM, Jim Mattson wrote:
>
> Can we use the read-only GDT here? When expanding the virtual address
> for 64-bit system descriptors, isn't it sufficient to check (d->s == 0
> && d->type != 0)?
We can use the readonly GDT but I think doesn't matter one or the
other here.
On Tue, Feb 14, 2017 at 7:57 PM, Andy Lutomirski wrote:
> On Tue, Feb 14, 2017 at 11:42 AM, Thomas Garnier wrote:
>> The KVM segment_base function is confusing. This patch replaces integers
>> with appropriate flags, simplify constructs and add comments.
>
> It could pay to put this first in the
On Tue, Feb 14, 2017 at 11:42 AM, Thomas Garnier wrote:
> The KVM segment_base function is confusing. This patch replaces integers
> with appropriate flags, simplify constructs and add comments.
It could pay to put this first in the series, but last is probably fine, too.
>
> Signed-off-by: Thom
The KVM segment_base function is confusing. This patch replaces integers
with appropriate flags, simplify constructs and add comments.
Signed-off-by: Thomas Garnier
---
Based on next-20170213
---
arch/x86/kvm/vmx.c | 26 ++
1 file changed, 18 insertions(+), 8 deletions(-)
13 matches
Mail list logo
