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
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
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
>>>
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
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
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
>>>
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.
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
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
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
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
>>> 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
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
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:
>
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,
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 -
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;
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.
>>>
>>>
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
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
>>
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
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.
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
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 information (also known
as the "Control Program Code" or
32 matches
Mail list logo
