On Tue, 2 Jul 2024 at 19:15, Zheyu Ma <zheyum...@gmail.com> wrote: > > Hi Mark, > > On Mon, Jul 1, 2024 at 10:49 PM Mark Cave-Ayland > <mark.cave-ayl...@ilande.co.uk> wrote: >> >> On 30/06/2024 14:04, Zheyu Ma wrote: >> What would happen if the source data plus length goes beyond the end of the >> framebuffer but the destination lies completely within it? Presumably the >> length of >> the data copy should be restricted to the length of the source data rather >> than the >> entire copy being ignored? >> > > Thanks for your useful tips! However, I'm unfamiliar with the tcx device and > cannot find a specification/datasheet. I apologize for not proposing a proper > fix.
Yeah, I couldn't find a datasheet for this device either. In the absence of any clear information, I think what we usually do in QEMU is take a plausible guess at what it might do and/or implement something that's straightforward for us to implement. Chances are good that real guest code never exercises the weird corners of the device behaviour anyway. Possible options include: * just ignore the blit attempt entirely * clamp source and destination addr/length and do the parts that do fall within the vram * treat address calculations as always wrapping around within the vram (so if you address off the top of it you end up reading from the bottom of it) I would suggest we just pick one, implement it (with a comment saying we don't have a spec so we're guessing about the behaviour in this case), and then test that whatever guest code we have (e.g. the bios, linux, some BSD) doesn't misbehave with the patch applied. By the way, doesn't this problem also affect the other TCX accelerator functions? Most obviously, tcg_rblit_writel() is basically the same structure for computing address and length; but also e.g. tcx_stip_writel() and tcx_rstip_writel() don't do bounds checking before accessing s->vram[addr + i]. thanks -- PMM
