On 5/14/19 5:04 AM, Christian Borntraeger wrote:
On 14.05.19 11:00, David Hildenbrand wrote:
On 14.05.19 10:56, Christian Borntraeger wrote:
On 14.05.19 10:50, David Hildenbrand wrote:
On 14.05.19 10:37, Christian Borntraeger wrote:
On 14.05.19 09:28, David Hildenbrand wrote:
But that
On 14.05.19 11:20, David Hildenbrand wrote:
> On 14.05.19 11:10, Christian Borntraeger wrote:
>>
>>
>> On 14.05.19 10:59, David Hildenbrand wrote:
>>> On 14.05.19 10:49, Cornelia Huck wrote:
On Tue, 14 May 2019 10:37:32 +0200
Christian Borntraeger wrote:
> On 14.05.19 09:28,
On 14.05.19 11:10, Christian Borntraeger wrote:
>
>
> On 14.05.19 10:59, David Hildenbrand wrote:
>> On 14.05.19 10:49, Cornelia Huck wrote:
>>> On Tue, 14 May 2019 10:37:32 +0200
>>> Christian Borntraeger wrote:
>>>
On 14.05.19 09:28, David Hildenbrand wrote:
But that can be teste
On Tue, 14 May 2019 11:07:41 +0200
Christian Borntraeger wrote:
> On 14.05.19 10:59, David Hildenbrand wrote:
> > We can
> >
> > 1. Fail to start with #cpus > 240 when diag318=on
> > 2. Remove the error once we support more than one SCLP response page
> >
> > Or
> >
> > 1. Allow to start with
On 14.05.19 10:59, David Hildenbrand wrote:
> On 14.05.19 10:49, Cornelia Huck wrote:
>> On Tue, 14 May 2019 10:37:32 +0200
>> Christian Borntraeger wrote:
>>
>>> On 14.05.19 09:28, David Hildenbrand wrote:
>>> But that can be tested using the runability information if I am not
>>> wro
On 14.05.19 11:03, David Hildenbrand wrote:
> On 14.05.19 11:00, Cornelia Huck wrote:
>> On Tue, 14 May 2019 10:56:43 +0200
>> Christian Borntraeger wrote:
>>
>>> On 14.05.19 10:50, David Hildenbrand wrote:
>>
Another idea for temporary handling: Simply only indicate 240 CPUs to
the gues
On 14.05.19 11:00, Cornelia Huck wrote:
> On Tue, 14 May 2019 10:56:43 +0200
> Christian Borntraeger wrote:
>
>> On 14.05.19 10:50, David Hildenbrand wrote:
>
>>> Another idea for temporary handling: Simply only indicate 240 CPUs to
>>> the guest if the response does not fit into a page. Once we
On 14.05.19 10:59, David Hildenbrand wrote:
> On 14.05.19 10:49, Cornelia Huck wrote:
>> On Tue, 14 May 2019 10:37:32 +0200
>> Christian Borntraeger wrote:
>>
>>> On 14.05.19 09:28, David Hildenbrand wrote:
>>> But that can be tested using the runability information if I am not
>>> wro
On 14.05.19 11:00, David Hildenbrand wrote:
> On 14.05.19 10:56, Christian Borntraeger wrote:
>>
>>
>> On 14.05.19 10:50, David Hildenbrand wrote:
>>> On 14.05.19 10:37, Christian Borntraeger wrote:
On 14.05.19 09:28, David Hildenbrand wrote:
But that can be tested using
On 14.05.19 10:56, Christian Borntraeger wrote:
>
>
> On 14.05.19 10:50, David Hildenbrand wrote:
>> On 14.05.19 10:37, Christian Borntraeger wrote:
>>>
>>>
>>> On 14.05.19 09:28, David Hildenbrand wrote:
>>> But that can be tested using the runability information if I am not
>>> wrong.
On 14.05.19 10:49, Cornelia Huck wrote:
> On Tue, 14 May 2019 10:37:32 +0200
> Christian Borntraeger wrote:
>
>> On 14.05.19 09:28, David Hildenbrand wrote:
>> But that can be tested using the runability information if I am not
>> wrong.
>
> You mean the cpu level information,
On Tue, 14 May 2019 10:56:43 +0200
Christian Borntraeger wrote:
> On 14.05.19 10:50, David Hildenbrand wrote:
> > Another idea for temporary handling: Simply only indicate 240 CPUs to
> > the guest if the response does not fit into a page. Once we have that
> > SCLP thingy, this will be fixed. G
On 14.05.19 10:50, David Hildenbrand wrote:
> On 14.05.19 10:37, Christian Borntraeger wrote:
>>
>>
>> On 14.05.19 09:28, David Hildenbrand wrote:
>> But that can be tested using the runability information if I am not
>> wrong.
>
> You mean the cpu level information, right?
>>>
On 14.05.19 10:49, Cornelia Huck wrote:
> On Tue, 14 May 2019 10:37:32 +0200
> Christian Borntraeger wrote:
>
>> On 14.05.19 09:28, David Hildenbrand wrote:
>> But that can be tested using the runability information if I am not
>> wrong.
>
> You mean the cpu level informatio
On 14.05.19 10:37, Christian Borntraeger wrote:
>
>
> On 14.05.19 09:28, David Hildenbrand wrote:
> But that can be tested using the runability information if I am not wrong.
You mean the cpu level information, right?
>>
>> Yes, query-cpu-definition includes for each model runabilit
On Tue, 14 May 2019 10:37:32 +0200
Christian Borntraeger wrote:
> On 14.05.19 09:28, David Hildenbrand wrote:
> But that can be tested using the runability information if I am not
> wrong.
> >>>
> >>> You mean the cpu level information, right?
> >
> > Yes, query-cpu-definition inc
On 14.05.19 09:28, David Hildenbrand wrote:
But that can be tested using the runability information if I am not wrong.
>>>
>>> You mean the cpu level information, right?
>
> Yes, query-cpu-definition includes for each model runability information
> via "unavailable-features" (valid under t
>>> But that can be tested using the runability information if I am not wrong.
>>
>> You mean the cpu level information, right?
Yes, query-cpu-definition includes for each model runability information
via "unavailable-features" (valid under the started QEMU machine).
>>
>>>
and others that w
On 13.05.19 13:46, Cornelia Huck wrote:
> On Mon, 13 May 2019 13:34:35 +0200
> David Hildenbrand wrote:
>
>> On 13.05.19 12:55, Christian Borntraeger wrote:
>>>
>>>
>>> On 13.05.19 11:57, David Hildenbrand wrote:
On 13.05.19 11:51, Christian Borntraeger wrote:
>
>
> On 13.
On Mon, 13 May 2019 13:34:35 +0200
David Hildenbrand wrote:
> On 13.05.19 12:55, Christian Borntraeger wrote:
> >
> >
> > On 13.05.19 11:57, David Hildenbrand wrote:
> >> On 13.05.19 11:51, Christian Borntraeger wrote:
> >>>
> >>>
> >>> On 13.05.19 11:40, David Hildenbrand wrote:
> O
On 13.05.19 12:55, Christian Borntraeger wrote:
>
>
> On 13.05.19 11:57, David Hildenbrand wrote:
>> On 13.05.19 11:51, Christian Borntraeger wrote:
>>>
>>>
>>> On 13.05.19 11:40, David Hildenbrand wrote:
On 13.05.19 11:34, Christian Borntraeger wrote:
>
>
> On 13.05.19 10:03, Da
On 13.05.19 11:57, David Hildenbrand wrote:
> On 13.05.19 11:51, Christian Borntraeger wrote:
>>
>>
>> On 13.05.19 11:40, David Hildenbrand wrote:
>>> On 13.05.19 11:34, Christian Borntraeger wrote:
On 13.05.19 10:03, David Hildenbrand wrote:
>>> +if ((SCCB_SIZE - sizeof(R
On 13.05.19 11:51, Christian Borntraeger wrote:
>
>
> On 13.05.19 11:40, David Hildenbrand wrote:
>> On 13.05.19 11:34, Christian Borntraeger wrote:
>>>
>>>
>>> On 13.05.19 10:03, David Hildenbrand wrote:
>> +if ((SCCB_SIZE - sizeof(ReadInfo)) / sizeof(CPUEntry) <
>> S390_MAX_CPUS)
>
On 13.05.19 11:40, David Hildenbrand wrote:
> On 13.05.19 11:34, Christian Borntraeger wrote:
>>
>>
>> On 13.05.19 10:03, David Hildenbrand wrote:
> +if ((SCCB_SIZE - sizeof(ReadInfo)) / sizeof(CPUEntry) <
> S390_MAX_CPUS)
> +mc->max_cpus = S390_MAX_CPUS - 8;
T
On 13.05.19 11:34, Christian Borntraeger wrote:
>
>
> On 13.05.19 10:03, David Hildenbrand wrote:
+if ((SCCB_SIZE - sizeof(ReadInfo)) / sizeof(CPUEntry) < S390_MAX_CPUS)
+mc->max_cpus = S390_MAX_CPUS - 8;
>>>
>>> This is too complicated, just set it always to 240.
>>>
>>> Ho
On 13.05.19 10:03, David Hildenbrand wrote:
>>> +if ((SCCB_SIZE - sizeof(ReadInfo)) / sizeof(CPUEntry) < S390_MAX_CPUS)
>>> +mc->max_cpus = S390_MAX_CPUS - 8;
>>
>> This is too complicated, just set it always to 240.
>>
>> However, I am still not sure how to best handle this scenario
On 13.05.19 09:46, David Hildenbrand wrote:
> On 02.05.19 00:31, Collin Walling wrote:
>> DIAGNOSE 0x318 (diag318) is a privileged s390x instruction that must
>> be intercepted by SIE and handled via KVM. Let's introduce some
>> functions to communicate between QEMU and KVM via ioctls. These
>> wil
On 02.05.19 00:31, Collin Walling wrote:
> DIAGNOSE 0x318 (diag318) is a privileged s390x instruction that must
> be intercepted by SIE and handled via KVM. Let's introduce some
> functions to communicate between QEMU and KVM via ioctls. These
> will be used to get/set the diag318 related informati
On 5/9/19 5:58 AM, Christian Borntraeger wrote:
On 02.05.19 00:31, Collin Walling wrote:
DIAGNOSE 0x318 (diag318) is a privileged s390x instruction that must
be intercepted by SIE and handled via KVM. Let's introduce some
functions to communicate between QEMU and KVM via ioctls. These
will be
On 09.05.19 11:58, Christian Borntraeger wrote:
>
>
> On 02.05.19 00:31, Collin Walling wrote:
>> DIAGNOSE 0x318 (diag318) is a privileged s390x instruction that must
>> be intercepted by SIE and handled via KVM. Let's introduce some
>> functions to communicate between QEMU and KVM via ioctls. Th
On 02.05.19 00:31, Collin Walling wrote:
> DIAGNOSE 0x318 (diag318) is a privileged s390x instruction that must
> be intercepted by SIE and handled via KVM. Let's introduce some
> functions to communicate between QEMU and KVM via ioctls. These
> will be used to get/set the diag318 related inform
31 matches
Mail list logo
