Re: [RFC PATCH v2 05/22] xen-platform-pci: allow its creation with XEN_EMULATE mode

[David Woodhouse]

On Mon, 2022-12-12 at 13:24 +0000, Paul Durrant wrote:
> On 09/12/2022 09:55, David Woodhouse wrote:
> > --- a/hw/i386/xen/xen_platform.c
> > +++ b/hw/i386/xen/xen_platform.c
> > @@ -271,7 +271,10 @@ static void platform_fixed_ioport_writeb(void *opaque, 
> > uint32_t addr, uint32_t v
> >        case 0: /* Platform flags */ {
> >            hvmmem_type_t mem_type = (val & PFFLAG_ROM_LOCK) ?
> >                HVMMEM_ram_ro : HVMMEM_ram_rw;
> > -        if (xen_set_mem_type(xen_domid, mem_type, 0xc0, 0x40)) {
> > +        if (xen_mode == XEN_EMULATE) {
> > +            /* XXX */
> > +            s->flags = val & PFFLAG_ROM_LOCK;
> > +        } else if (xen_set_mem_type(xen_domid, mem_type, 0xc0, 0x40)) {
> >                DPRINTF("unable to change ro/rw state of ROM memory 
> > area!\n");
> >            } else {
> >                s->flags = val & PFFLAG_ROM_LOCK;
> 
> 
> 
> Surely this would cleaner as:
> 
> 
> 
> if (xen_mode != XEN_EMULATE && xen_set_mem_type(xen_domid, mem_type, 0xc0, 
> 0x40))
>      DPRINTF("unable to change ro/rw state of ROM memory area!\n");
> else
>      s->flags = val & PFFLAG_ROM_LOCK;

Or maybe it should actually call into the PIIX code for frobbing the
read-only state of the UMBs? Do we even implement that in qemu? But
again, this part is just the necessary evil to make the thing testable
with -M xenfv for now.

I'm going to take a closer look at Paolo's suggestion which should
reduce the amount of such noise before we get to the real parts.

smime.p7s
Description: S/MIME cryptographic signature