Re: [PATCH 04/11] tpm_crb: use a single read-as-mem/write-as-mmio mapping

[Stefan Berger]

On 7/13/23 13:07, Peter Maydell wrote:
> On Thu, 13 Jul 2023 at 17:54, Stefan Berger <stefanb@linux.ibm.com> wrote:
> > On 7/13/23 11:55, Peter Maydell wrote:
> > > On Thu, 13 Jul 2023 at 16:46, Stefan Berger <stefanb@linux.ibm.com> wrote:
> > > > On 7/13/23 11:34, Peter Maydell wrote:
> > > > > On Thu, 13 Jul 2023 at 16:28, Stefan Berger <stefanb@linux.ibm.com> wrote:
> > > > > > On 7/13/23 10:50, Peter Maydell wrote:
> > > > > > > I'm not a super-fan of hacking around the fact that LDP
> > > > > > > to hardware registers isn't supported in specific device
> > > > > > > models, though...
> > > > > >
> > > > > > What does this mean for this effort here?
> > > > >
> > > > > Usually we say "fix the guest to not try to access hardware
> > > > > registers with silly load/store instruction types". The other
> > > > > option would be "put in a large amount of effort to support
> > > > > emulating those instructions in QEMU userspace when KVM/HVF/etc
> > > > > trap and punt them to us". For the last decade or so we have
> > > > > taken the first of these approaches :-)
> > > >
> > > > Is Microsoft likely to react to use telling them "fix the guest"?
> > >
> > > They have on occasion in the past, yes.
> > >
> > > The other outstanding question here is if this TPM device
> > > should be a sysbus one at all (i.e. not i2c), which might
> > > render this part moot.
> >
> > Does the aarch64 virt VM support an i2c bus? Would it support the aspeed i2c 
> > bus? Does Windows then accept this i2c bus? Maybe the faster answer comes via 
> > this device that Joelle presumably has working on AARCH64 Windows.
>
> The aim is not "get Windows booting as fast as possible", though.
> It's to end up with a QEMU virt board that (a) is maintainable
> (b) is reasonably congruent with what real hardware does
> (c) works in a way that will also work with what other
> guest OSes are expecting.
>
> I don't want to accept changes to the virt board that are
> hard to live with in future, because changing virt in
> non-backward compatible ways is painful.

I guess the first point would be to decide whether to support an i2c bus on the 
virt board and then whether we can use the aspeed bus that we know that the 
tpm_tis_i2c device model works with but we don't know how Windows may react to 
it.

It seems sysbus is already supported there so ... we may have a 'match'?

    dev = qdev_new("arm-gicv2m");
    sysbus_mmio_map(SYS_BUS_DEVICE(dev), 0, vms->memmap[VIRT_GIC_V2M].base);
    qdev_prop_set_uint32(dev, "base-spi", irq);
    qdev_prop_set_uint32(dev, "num-spi", NUM_GICV2M_SPIS);
    sysbus_realize_and_unref(SYS_BUS_DEVICE(dev), &error_fatal);


   Stefan

> thanks
> -- PMM