On 12/12/18 8:41 AM, Cornelia Huck wrote:
> On Wed, 12 Dec 2018 12:20:08 +0100
> David Hildenbrand wrote:
>
>> On 11.12.18 22:12, Collin Walling wrote:
>>> On 12/11/18 11:47 AM, Collin Walling wrote:
>>>> On 12/7/18 7:08 AM, Cornelia Huck wrote:
>
On 12/11/18 11:47 AM, Collin Walling wrote:
> On 12/7/18 7:08 AM, Cornelia Huck wrote:
>> On Thu, 6 Dec 2018 17:24:17 -0500
>> Collin Walling wrote:
>>
>>> Diagnose 318 is a new z14.2 CPU feature. Since we are able to emulate
>>> it entirely via KVM, we c
On 12/7/18 7:08 AM, Cornelia Huck wrote:
> On Thu, 6 Dec 2018 17:24:17 -0500
> Collin Walling wrote:
>
>> Diagnose 318 is a new z14.2 CPU feature. Since we are able to emulate
>> it entirely via KVM, we can add guest support for earlier models. A
>> new CPU feature
info byte (let's call it byte 134) to
detect the availability of diag318. Because of this, we have room for
one less VCPU and thus limit the max VPUs supported in a configuration
to 247 (down from 248).
Signed-off-by: Collin Walling .
---
hw/s390x/sclp.c | 2 ++
include/hw/s390x
reset
- tiny cleanups
Collin Walling (3):
s390: linux header sync for diag318
s390: cpu feature for diagnose 318 andlimit max VCPUs to 247
s390: migration and reset support for diagnose 318
hw/s390x/ipl.c | 3 +++
hw/s390x/s390-virtio-ccw.c | 3 +++
hw/s390x/
for the diagnose 318 related data so
we can clear it during a machine reset.
Signed-off-by: Collin Walling
---
hw/s390x/ipl.c | 3 +++
hw/s390x/s390-virtio-ccw.c | 3 +++
target/s390x/diag.c| 52 ++
target/s390x/internal.h| 4 +++-
target
Introduce VM group, attribute, and CPU feat defines for
diagnose 318.
Signed-off-by: Collin Walling
---
linux-headers/asm-s390/kvm.h | 5 +
1 file changed, 5 insertions(+)
diff --git a/linux-headers/asm-s390/kvm.h b/linux-headers/asm-s390/kvm.h
index 0265482..4b655e3 100644
--- a/linux
On 12/5/18 10:22 AM, Cornelia Huck wrote:
> On Wed, 5 Dec 2018 09:59:54 -0500
> Collin Walling wrote:
>
>> On 12/5/18 3:29 AM, Christian Borntraeger wrote:
>>> You should clearly review your email list.
>>>
>>> Adding the "new" Conny, r
On 12/5/18 3:29 AM, Christian Borntraeger wrote:
> You should clearly review your email list.
>
> Adding the "new" Conny, removing Carsten.
>
Thanks for taking care of that. I'll be more careful when using the
addresses at the top of the files.
>
> On 04.1
On 12/5/18 6:57 AM, David Hildenbrand wrote:
> On 05.12.18 12:54, Cornelia Huck wrote:
>> On Wed, 5 Dec 2018 09:27:44 +0100
>> Christian Borntraeger wrote:
>>
>>> On 05.12.2018 09:26, David Hildenbrand wrote:
>>>> On 04.12.18 23:18, Collin Walling wrot
On 12/5/18 6:07 AM, Cornelia Huck wrote:
> On Tue, 4 Dec 2018 17:26:36 -0500
> Collin Walling wrote:
>
>> I screen-scraped the @ibm address again (Conny was the victim this time)
>>
>> Reply to this thread to avoid any delivery failures.
>>
>> On 12/4/18
I screen-scraped the @ibm address again (Conny was the victim this time)
Reply to this thread to avoid any delivery failures.
On 12/4/18 5:18 PM, Collin Walling wrote:
> Add migration and reset support for diagnose 318. This is a new z14 GA2
> hardware feature, but we can provide guest s
list
and must limit the maximum VCPUs to 247 (down from 248).
Signed-off-by: Collin Walling
---
Changelog
RFC -> v1
- introduced kvm stubs for set/get cpc
- s/fac134/byte_134
- moved diag318 vmstate description to diag.c
- reduced S390_VCPU_MAX to 247
>>
>>> Looking up a variable that is directly passed as an argument doesn't
>>> look clean to me.
>>
>> I think there was a reason for this caching, namely that qom resolution can
>> be quite expensive. For the hotplug case this obviously does not matter but
>> for all the other cases it might. So do we really want to have different
>> places use different methods?
>>
>
> Caching resolution is fine (as that is expensive), caching a downcast is
> as far as I remember not necessary. Especially, as you said, for hotplug
> handlers.
>
> Anyhow, if there are strong feelings to this change, I can drop this
> patch. There are certainly more important things to do in zPCI hotplug code.
>
>
Truthfully, I'm not in favor of one over the other. As long as the device
handlers
are consistent, I think either is fine.
However, it would be nice if at some point during plug we cache the PHB
somewhere.
That would be some sort of best-of-both-worlds approach.
--
Respectfully,
- Collin Walling
void s390_pcihost_plug(HotplugHandler
> *hotplug_dev, DeviceState *dev,
>
> pbdev = s390_pci_find_dev_by_target(s, dev->id);
> if (!pbdev) {
> -pbdev = s390_pci_device_new(s, dev->id);
> + pbdev = s390_pci_device_new(s, dev->id, errp);
> if (!pbdev) {
> -error_setg(errp, "create zpci device failed");
> return;
> }
> }
>
LGTM
Reviewed-by: Collin Walling
--
Respectfully,
- Collin Walling
in the cover letter, part of another series
> (also CC'ed to qemu-s3...@nongnu.org, so maybe easier to find for you).
Ah, I see that now. Thanks for pointing that out (again).
--
Respectfully,
- Collin Walling
allocated idx is actually getting used */
>> +s->next_idx = (pbdev->idx + 1) & FH_MASK_INDEX;
>> pbdev->fh = pbdev->idx;
>> QTAILQ_INSERT_TAIL(>zpci_devs, pbdev, link);
>> g_hash_table_insert(s->zpci_table, >idx, pbdev);
>> @@ -1030,6 +1038,7 @@ static void s390_pcihost_class_init(ObjectClass
>> *klass, void *data)
>>
>> dc->reset = s390_pcihost_reset;
>> dc->realize = s390_pcihost_realize;
>> +hc->pre_plug = s390_pcihost_pre_plug;
>> hc->plug = s390_pcihost_plug;
>> hc->unplug = s390_pcihost_unplug;
>> msi_nonbroken = true;
>>
When did these function names drop the *_hot_plug postfix? Latest master does
not reflect this change for me.
Just figured I'd mention it now in case merging becomes a pain later ;)
>
>
The above concerns do not relate to any functionality of the code, so with them
addressed, then:
Reviewed-by: Collin Walling
--
Respectfully,
- Collin Walling
the future?
>
@Conny
Currently, the plan would be to stick with a hard requirement for MSIX unless
someone
strongly supports the legacy alternatives. I'm certainly open to discuss that.
Maybe it
would make sense to fallback to MSI for devices that don't support MSIX?
@David
Thanks for the cleanup.
Reviewed-by: Collin Walling
--
Respectfully,
- Collin Walling
On 10/29/2018 11:42 AM, Christian Borntraeger wrote:
> Collin will take over the maintainership from Yi Min. Let us add a
> separate s390 pci section.
>
> Signed-off-by: Christian Borntraeger
Acked-by: Collin Walling
> ---
> MAINTAINERS | 6 ++
> 1 file changed, 6 in
On 09/25/2018 06:40 AM, Dr. David Alan Gilbert wrote:
> * Collin Walling (wall...@linux.ibm.com) wrote:
>> When typing 'help' followed by an unknown command, QEMU will
>> not print anything to the command line to let the user know
>> they typed a bad command. Let's fix this
On 09/06/2018 03:28 PM, Dr. David Alan Gilbert wrote:
> * Collin Walling (wall...@linux.ibm.com) wrote:
>> On 08/08/2018 03:00 PM, Dr. David Alan Gilbert wrote:
>>> * Collin Walling (wall...@linux.ibm.com) wrote:
>>>> When typing 'help' followed by an unknown com
On 08/08/2018 03:00 PM, Dr. David Alan Gilbert wrote:
> * Collin Walling (wall...@linux.ibm.com) wrote:
>> When typing 'help' followed by an unknown command, QEMU will
>> not print anything to the command line to let the user know
>> they typed a bad command. Let's fix this
-by: Stefan Zimmermann
Signed-off-by: Collin Walling
---
monitor.c | 9 -
1 file changed, 8 insertions(+), 1 deletion(-)
diff --git a/monitor.c b/monitor.c
index 7af1f18..deeb41c 100644
--- a/monitor.c
+++ b/monitor.c
@@ -1013,6 +1013,7 @@ static void help_cmd_dump(Monitor *mon, const mon_cmd_t
On 07/20/2018 12:40 PM, Eric Blake wrote:
> On 07/19/2018 11:39 AM, Collin Walling wrote:
>> On 07/19/2018 12:31 PM, Markus Armbruster wrote:
>>> You neglected to cc: maintainers. Cc'ing them increases the odds your
>>> patch will be noticed and picked u
On 07/19/2018 03:18 PM, Dr. David Alan Gilbert wrote:
> * Collin Walling (wall...@linux.ibm.com) wrote:
>> When typing 'help' followed by an unknown command, QEMU will
>> not print anything to the command line to let the user know
>> they typed a bad command. Let's fix this
ticed anyway.
>
> David, this is yours :)
Very true. Was a minor fix that I thought I'd just toss it out there and
let anyone view it if they had the time. Will be more aware of who to CC
next time around.
Thanks :)
>
> Collin Walling writes:
>
>> When typing 'help' fol
-by: Stefan Zimmermann
Signed-off-by: Collin Walling
---
monitor.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/monitor.c b/monitor.c
index 7af1f18..7942f9f 100644
--- a/monitor.c
+++ b/monitor.c
@@ -1034,9 +1034,12 @@ static void help_cmd_dump(Monitor *mon, const mon_cmd_t
On 06/21/2018 07:19 AM, Dr. David Alan Gilbert wrote:
> * Collin Walling (wall...@linux.ibm.com) wrote:
>> When a user incorrectly provides an hmp command, an error response will be
>> printed that prompts the user to try "help ". However, when
>> the command con
Loadparm is defined by the s390 architecture to be 8 bytes
in length. Let's define this size in the s390-ccw bios.
Suggested-by: Laszlo Ersek
Signed-off-by: Collin Walling
---
pc-bios/s390-ccw/iplb.h | 4 +++-
pc-bios/s390-ccw/main.c | 8
pc-bios/s390-ccw/sclp.c | 2 +-
pc-bios/s390
nt to repeat
>> my comments on the upstream list too:
>>
>> On 05/04/18 09:25, Cornelia Huck wrote:
>>> From: Collin Walling <wall...@linux.ibm.com>
>>>
>>> Rename the loadparm char array in main.c to loadparm_str and
>>> increased the siz
On 05/07/2018 12:44 PM, Eric Blake wrote:
> On 05/07/2018 09:30 AM, Collin Walling wrote:
>> When a user incorrectly provides an hmp command, an error response will be
>> printed that prompts the user to try "help ". However, when
>> the command contains multiple p
uot;info" will
be dropped and the message will read "Try "help uuid" for more information",
which is incorrect).
Let's correct this by capturing the entirety of the command from the command
line -- excluding any extraneous characters.
Reported-by: Mikhail Fokin <
On 05/04/2018 02:19 PM, Eric Blake wrote:
> On 05/04/2018 01:02 PM, Collin Walling wrote:
>
>>> So rather than trying to reconstruct a string, you could reuse what you
>>> already have. This is a shorter patch that I think accomplishes the same
>>> goal:
On 05/04/2018 11:19 AM, Eric Blake wrote:
> On 05/04/2018 09:49 AM, Collin Walling wrote:
>> When a user incorrectly provides an hmp command, an error response will be
>> printed that prompts the user to try "help ". However, when
>> the command contains multipl
ot;info" will
be dropped and the message will read "Try "help skeys" for more information",
which is incorrect).
Let's correct this by capturing the full name of the command as we recurse
through the function monitor_parse_command.
Reported-by: Mikhail Fokin <
for menu.c in a later patch.
Signed-off-by: Collin Walling <wall...@linux.ibm.com>
Reviewed-by: Thomas Huth <th...@redhat.com>
Reviewed-by: Janosch Frank <fran...@linux.ibm.com>
---
pc-bios/s390-ccw/bootmap.c | 6 +++---
pc-bios/s390-ccw/bootmap.h | 2 --
pc-bios/s390-ccw/s3
-off-by: Collin Walling <wall...@linux.ibm.com>
Reported-by: Vasily Gorbik <g...@linux.ibm.com>
Reviewed-by: Thomas Huth <th...@redhat.com>
Reviewed-by: Janosch Frank <fran...@linux.ibm.com>
---
hw/s390x/ipl.c | 4
pc-bios/s390-ccw/main.c | 14 +++
] default
[1]
[2]
[7]
[8]
[9]
[11]
[12]
Please choose:
Signed-off-by: Collin Walling <wall...@linux.ibm.com>
Reported-by: Vasily Gorbik <g...@linux.ibm.com>
Reviewed-by: Thomas Huth <th...@redhat.com>
Reviewed-by: Janosch Frank <fran...@linux.ibm.com&g
zIPL boot menu entries can be non-sequential. Let's account
for this issue for the s390 zIPL boot menu. Since this boot
menu is actually an imitation and is not completely capable
of everything the real zIPL menu can do, let's also print a
different banner to the user.
Signed-off-by: Collin
in main.c can end up being not null terminated when
converted to an integer via atoui.
- A loadparm set to an empty string does not allow a boot menu.
Collin Walling (4):
pc-bios/s390-ccw: rename MAX_TABLE_ENTRIES to MAX_BOOT_ENTRIES
pc-bios/s390-ccw: fix loadparm initialization
On 04/16/2018 08:27 AM, Thomas Huth wrote:
> On 14.04.2018 00:08, Collin Walling wrote:
>> Rename the loadparm char array in main.c to loadparm_str and
>> increased the size by one byte to account for a null termination
>> when converting the loadparm string to an int via at
+typedef unsigned long size_t;
> typedef intbool;
> typedef unsigned char uint8_t;
> typedef unsigned short uint16_t;
>
Reviewed-by: Collin Walling <wall...@linux.ibm.com>
--
Respectfully,
- Collin Walling
] default
[1]
[2]
[7]
[8]
[9]
[11]
[12]
Please choose:
Signed-off-by: Collin Walling <wall...@linux.ibm.com>
Reported-by: Vasily Gorbik <g...@linux.ibm.com>
Reviewed-by: Thomas Huth <th...@redhat.com>
---
pc-bios/s390-ccw/bootmap.c | 12 +++-
pc-bi
zIPL boot menu entries can be non-sequential. Let's account
for this issue for the s390 zIPL boot menu. Since this boot
menu is actually an imitation and is not completely capable
of everything the real zIPL menu can do, let's also print a
different banner to the user.
Signed-off-by: Collin
to an integer via atoui.
- A loadparm set to an empty string does not allow a boot menu.
Collin Walling (4):
pc-bios/s390-ccw: rename MAX_TABLE_ENTRIES to MAX_BOOT_ENTRIES
pc-bios/s390-ccw: fix loadparm initialization and int conversion
pc-bios/s390-ccw: fix non-sequential boot entries
-off-by: Collin Walling <wall...@linux.ibm.com>
Reported-by: Vasily Gorbik <g...@linux.ibm.com>
Reviewed-by: Thomas Huth <th...@redhat.com>
---
hw/s390x/ipl.c | 2 ++
pc-bios/s390-ccw/main.c | 14 +++---
2 files changed, 9 insertions(+), 7 deletions(-)
diff --git
for menu.c in a later patch.
Signed-off-by: Collin Walling <wall...@linux.ibm.com>
Reviewed-by: Thomas Huth <th...@redhat.com>
---
pc-bios/s390-ccw/bootmap.c | 6 +++---
pc-bios/s390-ccw/bootmap.h | 2 --
pc-bios/s390-ccw/s390-ccw.h | 2 ++
3 files changed, 5 insertions(+), 5 deleti
ssize_t (until we really need it) is a better
>> course of action. I think uitoa can be easily rewritten so it does not
>> need the ssize_t.
>>
>> How about that?
>
> This seems clever indeed.
>
This whole issue stems from my misuse of size_t in the first place. If it makes
things easier, let's just make num_idx of type "signed long".
After reading this discussion, I think it makes sense to drop ssize_t. No need
to make it available for just one function unless there are strong claims to
also use this type elsewhere in the pc-bios (I can't find any).
--
Respectfully,
- Collin Walling
On 04/13/2018 02:14 AM, Thomas Huth wrote:
> On 10.04.2018 17:01, Collin Walling wrote:
>> zIPL boot menu entries can be non-sequential. Let's account
>> for this issue for the s390 zIPL boot menu. Since this boot
>> menu is actually an imitation and is not completely cap
H
>
> -typedef long size_t;
> +typedef unsigned long size_t;
> +typedef signed longssize_t;
> typedef intbool;
> typedef unsigned char uint8_t;
> typedef unsigned short uint16_t;
>
Looks good to me as well.
If another r-b is even necessary:
Reviewed-by: Collin Walling <wall...@linux.ibm.com>
--
Respectfully,
- Collin Walling
On 04/12/2018 02:57 PM, Thomas Huth wrote:
> On 10.04.2018 17:01, Collin Walling wrote:
>> Rename the loadparm char array in main.c to loadparm_str and
>> increase the size by one byte to account for a null termination
>> when converting the loadparm string to an int via
] default
[1]
[2]
[7]
[8]
[9]
[11]
[12]
Please choose:
Signed-off-by: Collin Walling <wall...@linux.ibm.com>
Reported-by: Vasily Gorbik <g...@linux.ibm.com>
---
pc-bios/s390-ccw/bootmap.c | 12 +++-
pc-bios/s390-ccw/menu.c | 29 -
for menu.c in a later patch.
Signed-off-by: Collin Walling <wall...@linux.ibm.com>
---
pc-bios/s390-ccw/bootmap.c | 6 +++---
pc-bios/s390-ccw/bootmap.h | 2 --
pc-bios/s390-ccw/s390-ccw.h | 2 ++
3 files changed, 5 insertions(+), 5 deletions(-)
diff --git a/pc-bios/s390-ccw/bootmap.c b/p
-by: Collin Walling <wall...@linux.ibm.com>
Reported-by: Vasily Gorbik <g...@linux.ibm.com>
---
hw/s390x/ipl.c | 2 ++
pc-bios/s390-ccw/main.c | 14 +++---
2 files changed, 9 insertions(+), 7 deletions(-)
diff --git a/hw/s390x/ipl.c b/hw/s390x/ipl.c
index fdeaec3..23
banner to reflect this.
- The loadparm array in main.c can end up being not null terminated when
converted to an integer via atoui.
- A loadparm set to an empty string does not allow a boot menu.
Collin Walling (4):
pc-bios/s390-ccw: rename MAX_TABLE_ENTRIES to MAX_BOOT_ENTRIES
pc
zIPL boot menu entries can be non-sequential. Let's account
for this issue for the s390 zIPL boot menu. Since this boot
menu is actually an imitation and is not completely capable
of everything the real zIPL menu can do, let's also print a
different banner to the user.
Signed-off-by: Collin
201 - 256 of 256 matches
Mail list logo
