On 01/13/2017 06:02 AM, Ladi Prosek wrote:
> The AHCI emulation code supports 64-bit addressing and should advertise this
> fact in the Host Capabilities register. Both Linux and Windows drivers test
> this bit to decide if the upper 32 bits of various registers may be written
> to, and at least some versions of Windows have a bug where DMA is attempted
> with an address above 4GB but, in the absence of HOST_CAP_64, the upper 32
> bits are left unititialized which leads to a memory corruption.
> Signed-off-by: Ladi Prosek <lpro...@redhat.com>
> hw/ide/ahci.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
> diff --git a/hw/ide/ahci.c b/hw/ide/ahci.c
> index 3c19bda..6a17acf 100644
> --- a/hw/ide/ahci.c
> +++ b/hw/ide/ahci.c
> @@ -488,7 +488,7 @@ static void ahci_reg_init(AHCIState *s)
> s->control_regs.cap = (s->ports - 1) |
> (AHCI_NUM_COMMAND_SLOTS << 8) |
> (AHCI_SUPPORTED_SPEED_GEN1 <<
> AHCI_SUPPORTED_SPEED) |
> - HOST_CAP_NCQ | HOST_CAP_AHCI;
> + HOST_CAP_NCQ | HOST_CAP_AHCI | HOST_CAP_64;
> s->control_regs.impl = (1 << s->ports) - 1;
Was this tested? What was the use case that prompted this patch, and do
you have a public bugzilla to point to?
It looks correct via the spec, thank you for finding this oversight. It
looks like everywhere this bit would make a difference we already do the
correct thing for having this bit set.
>From what I can gather from the spec, it looks as if even 32bit guests
must ensure that the upper 32bit registers are cleared, so I think we're
all set here.
Reviewed-by: John Snow <js...@redhat.com>