qemu-ppc
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH v7 0/8] Pegasos2 emulation


From: BALATON Zoltan
Subject: Re: [PATCH v7 0/8] Pegasos2 emulation
Date: Tue, 16 Mar 2021 15:17:50 +0100 (CET)

On Tue, 16 Mar 2021, Philippe Mathieu-Daudé wrote:
On 3/16/21 10:01 AM, Laurent Vivier wrote:
Le 15/03/2021 à 13:33, BALATON Zoltan a écrit :
On Sat, 13 Mar 2021, BALATON Zoltan wrote:
On Wed, 10 Mar 2021, BALATON Zoltan wrote:
Hello,

I've started posting this series well in advance to get it into 6.0 and yet it 
seems like it may
be missing it due to organisational issues (no real complaints were found with 
patches but
Philippe seems to like more review that does not seem to happen as nobody is 
interested). Looks
like David is waiting for an ack from Philippe but will be away next week so if 
this is not
resolved now it may be too late on Monday. To avoid that:

David, could you please send an ack before you leave for the last two patches 
so it could get
committed via some other tree while you're away?

Philippe, if you can't ack the vt82c686 patches now are you OK with taking the 
whole series via
your tree before the freeze? That would give you some more days to review and 
it could always be
reverted during the freeze but if it's not merged now I'll have to wait until 
the summer to get it
in again which would be another long delay. I don't think this will get more 
reviews unless it's
in master and people can start using and testing it better.

Hello,

Since David seems to be away for this week before seeing my mail asking for an 
ack from him, now
this can only get in by Philippe or Peter. (David said before he'd be OK with 
the series if Philippe
acked it so I think that can count as an implicit ack and it could always be 
reverted before the
releease.)

Philippe, do you have anything against this to get merged now? If not please 
send a pull or ack it
so it has a chance to be in 6.0 or tell if you still intend to do anything 
about it before the
freeze. This series was on the list since January and the remaining parts you 
did not take are here
since February 22nd and the version after your first review since two weeks so 
it would be nice to
sort this out and not block it any further without a good reason.

Pegasos looks like a New World PowerMac, so perhaps Mark can help?

The PPC part is mostly reviewed. The problem is the first patch:
"vt82c686: Implement control of serial port io ranges via config regs".

I don't understand it. Zoltan said Paolo isn't acking it because
he doesn't mind. I prefer to be cautious and think than Paolo is
rather too busy.

Can you just send a pull request then and Paolo could nack it or comment on that. If he does not, then this should be OK as it does not touch anything else than vt82c686 so it also should not break anything else.

Basically what the patch does is have a via-superio class that inherits from TYPE_ISA_SUPERIO that creates the ISA devices, among others isa-serial ports. Then the device grabs the memory regions for these serial devices to be able to change their state and address on config register writes. It only does that for serial devices not for parallel and floppy because those have more than one memory region and would not be easy to handle so those are not configurable but left at their default address. We need configurability for serial port because on pegasos2 there's only one serial port and it's set to a non-standard address by the firmware. Fuloong2e used to put these at default address and the firmware did not touch it, we now more properly emulate the chip and allow changing the address which the firmware leaves at the default but on pegasos that would not work.

The resulting model is not so bad as we only access memory region owned by child device (via-superio sets memory region of isa-serial that's created by its superclass isa superio and this is only needed because there's no other interface and one cannot be easily added without possibly breaking something due to other ISA devices that have multiple memory regions). So I think this is the simplest and least invasive solution that shoul be enough for now until ISA device emulation is QOM'ified which is a task I don't want to take up as it's way more work I'd put in and has a possibility to break stuff I don't have a way or time to test so unless somebody does that there's no other easy way to solve this problem.

Regards,
BALATON Zoltan

reply via email to

[Prev in Thread] Current Thread [Next in Thread]