On 07/05/2016 04:44 PM, Jan Beulich wrote:
On 05.07.16 at 17:34, wrote:
>> On Thu, Jun 30, 2016 at 03:10:11AM -0600, Jan Beulich wrote:
>> On 29.06.16 at 18:27, wrote:
On 29/06/16 17:19, Vitaly Kuznetsov wrote:
> To explain better what I'm trying to suggest here please take a lo
>>> On 05.07.16 at 17:34, wrote:
> On Thu, Jun 30, 2016 at 03:10:11AM -0600, Jan Beulich wrote:
>> >>> On 29.06.16 at 18:27, wrote:
>> > On 29/06/16 17:19, Vitaly Kuznetsov wrote:
>> >> To explain better what I'm trying to suggest here please take a look at
>> >> the attached patch. If we can gua
On Thu, Jun 30, 2016 at 03:10:11AM -0600, Jan Beulich wrote:
> >>> On 29.06.16 at 18:27, wrote:
> > On 29/06/16 17:19, Vitaly Kuznetsov wrote:
> >> To explain better what I'm trying to suggest here please take a look at
> >> the attached patch. If we can guarantee long term that ACPI id always
> >
>>> On 01.07.16 at 14:06, wrote:
> "Jan Beulich" writes:
>
> On 29.06.16 at 18:27, wrote:
>>> On 29/06/16 17:19, Vitaly Kuznetsov wrote:
To explain better what I'm trying to suggest here please take a look at
the attached patch. If we can guarantee long term that ACPI id always
>>
"Jan Beulich" writes:
On 29.06.16 at 18:27, wrote:
>> On 29/06/16 17:19, Vitaly Kuznetsov wrote:
>>> To explain better what I'm trying to suggest here please take a look at
>>> the attached patch. If we can guarantee long term that ACPI id always
>>> equals to Xen's idea of vCPU id this is
>>> On 29.06.16 at 18:27, wrote:
> On 29/06/16 17:19, Vitaly Kuznetsov wrote:
>> To explain better what I'm trying to suggest here please take a look at
>> the attached patch. If we can guarantee long term that ACPI id always
>> equals to Xen's idea of vCPU id this is probably the easiest way.
>>
On 29/06/16 17:19, Vitaly Kuznetsov wrote:
> Vitaly Kuznetsov writes:
>
>> > Andrew Cooper writes:
>> >
>>> >> On 29/06/16 13:16, Vitaly Kuznetsov wrote:
>>> Andrew Cooper writes:
>>>
> On 28/06/16 17:47, Vitaly Kuznetsov wrote:
>> > @@ -1808,6 +1822,8 @@ static int xe
Vitaly Kuznetsov writes:
> Andrew Cooper writes:
>
>> On 29/06/16 13:16, Vitaly Kuznetsov wrote:
>>> Andrew Cooper writes:
>>>
On 28/06/16 17:47, Vitaly Kuznetsov wrote:
> @@ -1808,6 +1822,8 @@ static int xen_hvm_cpu_notify(struct notifier_block
> *self, unsigned long action,
Andrew Cooper writes:
> On 29/06/16 13:16, Vitaly Kuznetsov wrote:
>> Andrew Cooper writes:
>>
>>> On 28/06/16 17:47, Vitaly Kuznetsov wrote:
@@ -1808,6 +1822,8 @@ static int xen_hvm_cpu_notify(struct notifier_block
*self, unsigned long action,
int cpu = (long)hcpu;
sw
On 29/06/16 13:16, Vitaly Kuznetsov wrote:
> Andrew Cooper writes:
>
>> On 28/06/16 17:47, Vitaly Kuznetsov wrote:
>>> @@ -1808,6 +1822,8 @@ static int xen_hvm_cpu_notify(struct notifier_block
>>> *self, unsigned long action,
>>> int cpu = (long)hcpu;
>>> switch (action) {
>>> case CP
Andrew Cooper writes:
> On 28/06/16 17:47, Vitaly Kuznetsov wrote:
>> @@ -1808,6 +1822,8 @@ static int xen_hvm_cpu_notify(struct notifier_block
>> *self, unsigned long action,
>> int cpu = (long)hcpu;
>> switch (action) {
>> case CPU_UP_PREPARE:
>> +/* vLAPIC_ID == Xen
On 28/06/16 17:47, Vitaly Kuznetsov wrote:
> @@ -1808,6 +1822,8 @@ static int xen_hvm_cpu_notify(struct notifier_block
> *self, unsigned long action,
> int cpu = (long)hcpu;
> switch (action) {
> case CPU_UP_PREPARE:
> + /* vLAPIC_ID == Xen's vCPU_ID * 2 for HVM guest
It may happen that Xen's and Linux's ideas of vCPU id diverge. In
particular, when we crash on a secondary vCPU we may want to do kdump
and unlike plain kexec where we do migrate_to_reboot_cpu() we try booting
on the vCPU which crashed. This doesn't work very well for PVHVM guests as
we have a numb
13 matches
Mail list logo
