date:20200614

The git-submodule.sh script is called by make and initialize the
submodules listed in the GIT_SUBMODULES variable generated by
./configure.

Add SLOF when we build the ppc64-softmmu target for the pSeries
machines (which use SLOF). This fixes:

  $ ( cd ${SRC_DIR} ; git submodule update --init roms/SLOF )
  Submodule 'roms/SLOF' (https://git.qemu.org/git/SLOF.git) registered for path 
'roms/SLOF'
  Cloning into '/home/travis/build/user/qemu/roms/SLOF'...
  fatal: unable to access 'https://git.qemu.org/git/SLOF.git/': Could not 
resolve host: git.qemu.org
  fatal: clone of 'https://git.qemu.org/git/SLOF.git' into submodule path 
'/home/travis/build/user/qemu/roms/SLOF' failed
  Failed to clone 'roms/SLOF'. Retry scheduled
  Cloning into '/home/travis/build/user/qemu/roms/SLOF'...
  fatal: unable to access 'https://git.qemu.org/git/SLOF.git/': Could not 
resolve host: git.qemu.org
  fatal: clone of 'https://git.qemu.org/git/SLOF.git' into submodule path 
'/home/travis/build/user/qemu/roms/SLOF' failed
  Failed to clone 'roms/SLOF' a second time, aborting
  The command "( cd ${SRC_DIR} ; git submodule update --init roms/SLOF )" 
exited with 1.

Reported-by: Mark Cave-Ayland 
Signed-off-by: Philippe Mathieu-Daudé 
---
CI: https://travis-ci.org/github/philmd/qemu/jobs/698406512#L1596
---
 configure   | 12 
 .travis.yml |  1 -
 2 files changed, 12 insertions(+), 1 deletion(-)

diff --git a/configure b/configure
index 7c2adf36e5..f297a4b68f 100755
--- a/configure
+++ b/configure
@@ -2248,6 +2248,18 @@ if test "$edk2_blobs" = "yes" && ! has bzip2; then
   error_exit "The bzip2 program is required for building QEMU"
 fi
 
+###
+# SLOF is mandatory for the pSeries
+for target in $target_list; do
+  case $target in
+ppc64-softmmu)
+  if test -e "${source_path}/.git" ; then
+  git_submodules="${git_submodules} roms/SLOF"
+  fi
+;;
+  esac
+done
+
 feature_not_found() {
   feature=$1
   remedy=$2
diff --git a/.travis.yml b/.travis.yml
index ec6367af1f..220855c1f0 100644
--- a/.travis.yml
+++ b/.travis.yml
@@ -496,7 +496,6 @@ jobs:
 - CONFIG="--disable-containers 
--target-list=${MAIN_SOFTMMU_TARGETS},s390x-linux-user"
 - UNRELIABLE=true
   script:
-- ( cd ${SRC_DIR} ; git submodule update --init roms/SLOF )
 - BUILD_RC=0 && make -j${JOBS} || BUILD_RC=$?
 - |
   if [ "$BUILD_RC" -eq 0 ] ; then
-- 
2.21.3

Re: [PATCH v4 5/6] i386: Hyper-V VMBus ACPI DSDT entry

2020-06-14 Thread Maciej S. Szmigiero

On 15.06.2020 04:40, Jon Doron wrote:
> On 14/06/2020, Maciej S. Szmigiero wrote:
>> Hi Jon,
>>
>> On 14.06.2020 16:11, Jon Doron wrote:
>>> On 28/05/2020, Jon Doron wrote:
 On 28/05/2020, Igor Mammedov wrote:
> On Thu, 28 May 2020 08:26:42 +0300
> Jon Doron  wrote:
>
>> On 22/05/2020, Igor Mammedow wrote:
>>> On Thu, 21 May 2020 18:02:07 +0200
>>> Paolo Bonzini  wrote:
>>>
 On 13/05/20 17:34, Igor Mammedov wrote:
 > I'd rather avoid using random IRQ numbers (considering we are
 > dealing with black-box here). So if it's really necessary to have
 > IRQ described here, I'd suggest to implement them in device model
 > so they would be reserved and QEMU would error out in a sane way if
 > IRQ conflict is detected.

 We don't generally detect ISA IRQ conflicts though, do we?
>>>
>>> that I don't know that's why I'm not suggesting how to do it.
>>> The point is hard-coding in AML random IRQs is not right thing to do,
>>> (especially with the lack of 'any' spec), as minimum AML should pull
>>> it from device model and that probably should be configurable and set
>>> by board.
>>>
>>> Other thing is:
>>> I haven't looked at VMBus device model in detail, but DSDT part aren't
>>> matching device though (device model is not ISA device hence AML part
>>> shouldn't be on in ISA scope), where to put it is open question.
>>> There were other issues with AML code, I've commented on, so I was
>>> waiting on respin with comments addressed.
>>> I don't think that this patch is good enough for merging.
>>>
>>>
>>
>> But it seems like the current patch does match what's Microsoft HyperV
>> is publishing in it's APCI tables.
>>
>> I dont think it's correct for us to "fix" Microsoft emulation even if
>> it's wrong, since that's what Windows probably expects to see...
>>
>> I tried looking where Microsoft uses the ACPI tables to identify the
>> VMBus but without much luck in order to understand how flexible a change
>> would be for the OS to still detect the VMBus device, but in general
>> I think "correcting" something that is emulated 1:1 because there is no
>> spec is the right way.
>
> I'd agree, if removing nonsense would break VMBus detection (does it?).
> if something is that doesn't make sense but has to stay because it is need
> to make windows happy, that's fine , just add annotate is with comment,
> so it won't confuse anyone why that code exists there later on.
>
> I suggest to:
> 1. try dropping _PS* & _STA as it doesn't actually does anything and _PS3 
> is plain wrong
> 2. drop one IRQ, newer hyper-v seems to be doing fine with only one
> 3. it's not ISA device, I'd suggest to move into _SB scope
> 4. I don't know much about IRQs but
>  git grep DEFINE_PROP_ | grep -i iqr
>   yields nothing so I'm not sure if it's acceptable. Typically it's board 
> that assigns
>   IRQ and not device, for Sysbus devices (see: 
> sysbus_init_irq/sysbus_connect_irq).
>   So I'd leave it upto Paolo or someone else to decide/comment on.
>

 Sounds like a plan, I'll try to come up with the test results
 (at least for Windows 10 guest which is  what I have setup) and update
 this thread with the results.

 -- Jon.

>>

 Paolo

>>>
>>
>
>>> Hi guys,
>>>
>>> Sorry for the delay...
>>>
>>> So first ill clarify what was the test, the test was to see the device
>>> "Microsoft Hyper-V Virtual Machine Bus" in Windows Device Manager under
>>> "System devices" with a state of "working properly".
>>>
>>> It seems like it's ok to drop all the _PS* and _STA.
>>>
>>> It seems to be functioning with single IRQ as well, it is worth noting that 
>>> even when i dropped the entire _CRS (so no IRQs resources are required, the 
>>> device was still showing that it's functioning, but I suspect this might 
>>> affect the child devices like hv-net and hv-scsi).
>>
>> I guess you tested a single Windows version, correct?
>> It may be that requirements differ between Windows versions, just as you
>> say below about the required enlightenments.
>>
> 
> Yes I have tested only a single version, but from the looks of it there is 
> only a single IRQ in the HyperV APCI table that I have looked at, and I 
> believe the one you have pasted as well in the past, so that change sounds 
> reasonable to me.

I meant also other changes, like dropping of some ACPI methods.

> As for the enlightenments dont you prefer to have all those as mandatory for 
> VMBus in order not to run into the issue I have encountered?

Well, if somebody wants to run only older guests they will be content with
just a limited set of enlightenments, right?

But I don't know what's the QEMU project policy is here.

>>> With that said I did run into

Re: [PATCH for-5.1 V4 3/4] hw/mips: Add Loongson-3 machine support (with KVM)

пон, 15. јун 2020. у 08:29 Huacai Chen  је написао/ла:
>
> Hi, Aleksandar,
>
> On Mon, Jun 15, 2020 at 2:04 PM Aleksandar Markovic
>  wrote:
> >
> > пон, 15. јун 2020. у 07:36 Huacai Chen  је написао/ла:
> > >
> > > Hi, Aleksandar,
> > >
> > > On Mon, Jun 15, 2020 at 12:50 PM Aleksandar Markovic
> > >  wrote:
> > > >
> > > > пон, 15. јун 2020. у 02:55 Huacai Chen  је 
> > > > написао/ла:
> > > > >
> > > > > Hi, Aleksandar,
> > > > >
> > > > > On Sun, Jun 14, 2020 at 3:51 PM Aleksandar Markovic
> > > > >  wrote:
> > > > > >
> > > > > > Hi, Huacai, this is another round of comments, that should be 
> > > > > > addressed in v5.
> > > > > >
> > > > > > уто, 2. јун 2020. у 04:40 Huacai Chen  је 
> > > > > > написао/ла:
> > > > > > >
> > > > > > > Add Loongson-3 based machine support, it use i8259 as the 
> > > > > > > interrupt
> > > > > > > controler and use GPEX as the pci controller. Currently it can 
> > > > > > > only
> > > > > > > work with KVM, but we will add TCG support in future.
> > > > > > >
> > > > > >
> > > > > > Add this paragraph at this place in the commit message:
> > > > > >
> > > > > > "As the machine model is not based on any exiting physical hardware,
> > > > > > the name of the machine is "loongson3-virt". It may be superseded in
> > > > > > future by a real machine model. If this happens, a regular 
> > > > > > deprecation
> > > > > > procedure shall occur for "loongson3-virt" machine."
> > > > > >
> > > > > OK, this will be added, and I will rename to "loongson3-virt-1.0",
> > > > > which can be updated in future.
> > > > > But I think rename the name string is enough, file names and function
> > > > > names can keep their old names.
> > > Why ARM can use version name?
> > > virt-2.10 QEMU 2.10 ARM Virtual Machine
> > > virt-2.11 QEMU 2.11 ARM Virtual Machine
> > > virt-2.12 QEMU 2.12 ARM Virtual Machine
> > > virt-2.6 QEMU 2.6 ARM Virtual Machine
> > > virt-2.7 QEMU 2.7 ARM Virtual Machine
> > > virt-2.8 QEMU 2.8 ARM Virtual Machine
> > > virt-2.9 QEMU 2.9 ARM Virtual Machine
> > > virt-3.0 QEMU 3.0 ARM Virtual Machine
> > > virt-3.1 QEMU 3.1 ARM Virtual Machine
> > > virt-4.0 QEMU 4.0 ARM Virtual Machine
> > > virt-4.1 QEMU 4.1 ARM Virtual Machine
> > > virt-4.2 QEMU 4.2 ARM Virtual Machine
> > > virt QEMU 5.0 ARM Virtual Machine (alias of virt-5.0)
> > >
> > > In future will will replace i8259 with an advanced PIC, that will be
> > > loongson3-virt-2.0.
> > >
> i8259 is not the best choice, but it is simple. Replacing i8259 with
> an advanced PIC is our future plan (loongson3-virt-2.0 will not
> replace loongson3-virt-1.0, but co-exist with it), but it need lots of
> effort. If we can't use a version number for a machine type, what is
> the best method?
>

Huacai,

The best method is that you focus on your current proposal, without
planing multiple Longson3 virtual machines, that I already discouraged
you from implementing altogether. And, for future, focus on
implementing emulation of a real Loongson3 machine, and at that moment
we should be able to deprecate Loongson3 virtual machine, altogether
with loongson3-virt.c file.

Yours,
Aleksandar

> > > > >
> > > >
> > > > Loongson3 is instruction set name, not a machine name, and treating
> > > > such name as machine name is incorrect. Renaming as I outlined in my
> > > > comments must occur.
> > > In future, both real machine and virtual machine models will be
> > > implement in the same file, so I think loongson3.c is better than
> > > loongson3-virt.c
> > >
> >
> > I don't see any significant advantage of departing of existing
> > one-main-source-file-per-machine principle.
> In my opinion, if two machine models share more than 90% of the code,
> they can be implemented in the same file. In hw/i386/pc.c there are
> many machine models (GlobalProperty). Maybe it is another bad example?
>
> I'm not insisting on my bad practice, but I need some "correct style"
> to achieve my goal.
>
> Huacai
> >
> > Regards,
> > Aleksandar
> >
> > > >
> > > > Yours,
> > > > Aleksandar
> > > >
> > > > > Huacai
> > > > > > > We already have a full functional Linux kernel (based on 
> > > > > > > Linux-5.4.x LTS
> > > > > > > but not upstream yet) here:
> > > > > > >
> > > > > > > https://github.com/chenhuacai/linux
> > > > > > >
> > > > > > > How to use QEMU/Loongson-3?
> > > > > > > 1, Download kernel source from the above URL;
> > > > > > > 2, Build a kernel with 
> > > > > > > arch/mips/configs/loongson3_{def,hpc}config;
> > > > > > > 3, Boot the a Loongson-3A4000 host with this kernel;
> > > > > > > 4, Build QEMU-5.0.0 with this patchset;
> > > > > > > 5, modprobe kvm;
> > > > > > > 6, Use QEMU with TCG (available in future):
> > > > > > >qemu-system-mips64el -M loongson3,accel=tcg -cpu 
> > > > > > > Loongson-3A1000 -kernel  -append ...
> > > > > >
> > > > > > Machine should be named loongson3-virt.
> > > > > >
> > > > > > >Use QEMU with KVM (available at present):
> > > > > > >qemu-system-mips64el -M loongson3,accel=kvm -cpu 
>

Re: [PATCH v3 2/4] error: auto propagated local_err

2020-06-14 Thread Greg Kurz

On Sat, 13 Jun 2020 17:12:59 +1000
David Gibson  wrote:

> On Thu, Jun 11, 2020 at 03:40:18PM +0200, Greg Kurz wrote:
> > From: Vladimir Sementsov-Ogievskiy 
> > 
> > Introduce a new ERRP_AUTO_PROPAGATE macro, to be used at start of
> > functions with an errp OUT parameter.
> > 
> > It has three goals:
> > 
> > 1. Fix issue with error_fatal and error_prepend/error_append_hint: user
> > can't see this additional information, because exit() happens in
> > error_setg earlier than information is added. [Reported by Greg Kurz]
> > 
> > 2. Fix issue with error_abort and error_propagate: when we wrap
> > error_abort by local_err+error_propagate, the resulting coredump will
> > refer to error_propagate and not to the place where error happened.
> > (the macro itself doesn't fix the issue, but it allows us to [3.] drop
> > the local_err+error_propagate pattern, which will definitely fix the
> > issue) [Reported by Kevin Wolf]
> > 
> > 3. Drop local_err+error_propagate pattern, which is used to workaround
> > void functions with errp parameter, when caller wants to know resulting
> > status. (Note: actually these functions could be merely updated to
> > return int error code).
> > 
> > To achieve these goals, later patches will add invocations
> > of this macro at the start of functions with either use
> > error_prepend/error_append_hint (solving 1) or which use
> > local_err+error_propagate to check errors, switching those
> > functions to use *errp instead (solving 2 and 3).
> > 
> > Signed-off-by: Vladimir Sementsov-Ogievskiy 
> > Reviewed-by: Paul Durrant 
> > Reviewed-by: Greg Kurz 
> > Reviewed-by: Eric Blake 
> > Signed-off-by: Greg Kurz 
> > Reviewed-by: Laurent Vivier 
> 
> I don't feel terribly qualified to comment on this generic change to
> the errors mechanism.  I can take it through my tree if necessary, but
> I'd want an ack from Markus.
> 

Markus answered in another mail that there's still some more work to do
before we start using the ERRP_AUTO_PROPAGATE macro. A suivre...

> > ---
> >  include/qapi/error.h |  205 
> > ++
> >  1 file changed, 173 insertions(+), 32 deletions(-)
> > 
> > diff --git a/include/qapi/error.h b/include/qapi/error.h
> > index ad5b6e896ded..30140d9bfea9 100644
> > --- a/include/qapi/error.h
> > +++ b/include/qapi/error.h
> > @@ -15,6 +15,8 @@
> >  /*
> >   * Error reporting system loosely patterned after Glib's GError.
> >   *
> > + * = Deal with Error object =
> > + *
> >   * Create an error:
> >   * error_setg(&err, "situation normal, all fouled up");
> >   *
> > @@ -47,28 +49,91 @@
> >   * reporting it (primarily useful in testsuites):
> >   * error_free_or_abort(&err);
> >   *
> > - * Pass an existing error to the caller:
> > - * error_propagate(errp, err);
> > - * where Error **errp is a parameter, by convention the last one.
> > + * = Deal with Error ** function parameter =
> >   *
> > - * Pass an existing error to the caller with the message modified:
> > - * error_propagate_prepend(errp, err);
> > + * A function may use the error system to return errors. In this case, the
> > + * function defines an Error **errp parameter, by convention the last one 
> > (with
> > + * exceptions for functions using ... or va_list).
> >   *
> > - * Avoid
> > - * error_propagate(errp, err);
> > - * error_prepend(errp, "Could not frobnicate '%s': ", name);
> > - * because this fails to prepend when @errp is &error_fatal.
> > + * The caller may then pass in the following errp values:
> >   *
> > - * Create a new error and pass it to the caller:
> > + * 1. &error_abort
> > + *Any error will result in abort().
> > + * 2. &error_fatal
> > + *Any error will result in exit() with a non-zero status.
> > + * 3. NULL
> > + *No error reporting through errp parameter.
> > + * 4. The address of a NULL-initialized Error *err
> > + *Any error will populate errp with an error object.
> > + *
> > + * The following rules then implement the correct semantics desired by the
> > + * caller.
> > + *
> > + * Create a new error to pass to the caller:
> >   * error_setg(errp, "situation normal, all fouled up");
> >   *
> > - * Call a function and receive an error from it:
> > + * Calling another errp-based function:
> > + * f(..., errp);
> > + *
> > + * == Checking success of subcall ==
> > + *
> > + * If a function returns a value indicating an error in addition to setting
> > + * errp (which is recommended), then you don't need any additional code, 
> > just
> > + * do:
> > + *
> > + * int ret = f(..., errp);
> > + * if (ret < 0) {
> > + * ... handle error ...
> > + * return ret;
> > + * }
> > + *
> > + * If a function returns nothing (not recommended for new code), the only 
> > way
> > + * to check success is by consulting errp; doing this safely requires the 
> > use
> > + * of the ERRP_AUTO_PROPAGATE macro, like this:
> > + *
> > + * int our_func(..., Error **errp) {
> > + *

Re: [PATCH v10 1/9] error: auto propagated local_err

2020-06-14 Thread Greg Kurz

On Mon, 15 Jun 2020 07:21:03 +0200
Markus Armbruster  wrote:

> Greg Kurz  writes:
> 
> > On Tue, 17 Mar 2020 18:16:17 +0300
> > Vladimir Sementsov-Ogievskiy  wrote:
> >
> >> Introduce a new ERRP_AUTO_PROPAGATE macro, to be used at start of
> >> functions with an errp OUT parameter.
> >> 
> >> It has three goals:
> >> 
> >> 1. Fix issue with error_fatal and error_prepend/error_append_hint: user
> >> can't see this additional information, because exit() happens in
> >> error_setg earlier than information is added. [Reported by Greg Kurz]
> >> 
> >
> > I have more of these coming and I'd really like to use ERRP_AUTO_PROPAGATE.
> >
> > It seems we have a consensus on the macro itself but this series is gated
> > by the conversion of the existing code base.
> >
> > What about merging this patch separately so that people can start using
> > it at least ?
> 
> Please give me a few more days to finish the work I feel should go in
> before the conversion.  With any luck, Vladimir can then rebase /
> recreate the conversion easily, and you can finally use the macro for
> your own work.
> 

Sure. Thanks.

Re: [PATCH] .travis.yml: Use travis_retry() in case of network issues

On 6/15/20 7:12 AM, Thomas Huth wrote:
> On 14/06/2020 11.48, Mark Cave-Ayland wrote:
>> On 13/06/2020 14:06, Philippe Mathieu-Daudé wrote:
>>
>>> Use travis_retry() when cloning SLOF (see 31c8cc4f94e) in the
>>> s390x container job, to avoid build failures:
>>>
>>>   $ ( cd ${SRC_DIR} ; git submodule update --init roms/SLOF )
>>>   Submodule 'roms/SLOF' (https://git.qemu.org/git/SLOF.git) registered for 
>>> path 'roms/SLOF'
>>>   Cloning into '/home/travis/build/user/qemu/roms/SLOF'...
>>>   fatal: unable to access 'https://git.qemu.org/git/SLOF.git/': Could not 
>>> resolve host: git.qemu.org
>>>   fatal: clone of 'https://git.qemu.org/git/SLOF.git' into submodule path 
>>> '/home/travis/build/user/qemu/roms/SLOF' failed
>>>   Failed to clone 'roms/SLOF'. Retry scheduled
>>>   Cloning into '/home/travis/build/user/qemu/roms/SLOF'...
>>>   fatal: unable to access 'https://git.qemu.org/git/SLOF.git/': Could not 
>>> resolve host: git.qemu.org
>>>   fatal: clone of 'https://git.qemu.org/git/SLOF.git' into submodule path 
>>> '/home/travis/build/user/qemu/roms/SLOF' failed
>>>   Failed to clone 'roms/SLOF' a second time, aborting
>>>   The command "( cd ${SRC_DIR} ; git submodule update --init roms/SLOF )" 
>>> exited with 1.
>>>
>>> Reported-by: Mark Cave-Ayland 
>>> Signed-off-by: Philippe Mathieu-Daudé 
>>> ---
>>>  .travis.yml | 2 +-
>>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>>
>>> diff --git a/.travis.yml b/.travis.yml
>>> index ec6367af1f..19a1b55aab 100644
>>> --- a/.travis.yml
>>> +++ b/.travis.yml
>>> @@ -496,7 +496,7 @@ jobs:
>>>  - CONFIG="--disable-containers 
>>> --target-list=${MAIN_SOFTMMU_TARGETS},s390x-linux-user"
>>>  - UNRELIABLE=true
>>>script:
>>> -- ( cd ${SRC_DIR} ; git submodule update --init roms/SLOF )
>>> +- ( cd ${SRC_DIR} ; travis_retry git submodule update --init 
>>> roms/SLOF )
>>>  - BUILD_RC=0 && make -j${JOBS} || BUILD_RC=$?
>>>  - |
>>>if [ "$BUILD_RC" -eq 0 ] ; then
>>
>> Hi Phil,
>>
>> Thanks for diagnosing and proposing a fix. Is there a reason why SLOF in 
>> particular
>> is failing compared to other repositories that might also need a similar 
>> change?
> 
> That's what I wonder, too. If git.qemu.org could not be resolved for
> SLOF.git, why should it be resolvable for the other submodules that are
> checked out automatically during the build process?

submodules updates are handled by make indeed:

config-host.mak -> git-submodule-update -> ./scripts/git-submodule.sh
using GIT_SUBMODULES generated by ./configure

Will respin.

> 
>  Thomas
>

Re: [PATCH for-5.1 V4 3/4] hw/mips: Add Loongson-3 machine support (with KVM)

Hi, Aleksandar,

On Mon, Jun 15, 2020 at 2:04 PM Aleksandar Markovic
 wrote:
>
> пон, 15. јун 2020. у 07:36 Huacai Chen  је написао/ла:
> >
> > Hi, Aleksandar,
> >
> > On Mon, Jun 15, 2020 at 12:50 PM Aleksandar Markovic
> >  wrote:
> > >
> > > пон, 15. јун 2020. у 02:55 Huacai Chen  је 
> > > написао/ла:
> > > >
> > > > Hi, Aleksandar,
> > > >
> > > > On Sun, Jun 14, 2020 at 3:51 PM Aleksandar Markovic
> > > >  wrote:
> > > > >
> > > > > Hi, Huacai, this is another round of comments, that should be 
> > > > > addressed in v5.
> > > > >
> > > > > уто, 2. јун 2020. у 04:40 Huacai Chen  је 
> > > > > написао/ла:
> > > > > >
> > > > > > Add Loongson-3 based machine support, it use i8259 as the interrupt
> > > > > > controler and use GPEX as the pci controller. Currently it can only
> > > > > > work with KVM, but we will add TCG support in future.
> > > > > >
> > > > >
> > > > > Add this paragraph at this place in the commit message:
> > > > >
> > > > > "As the machine model is not based on any exiting physical hardware,
> > > > > the name of the machine is "loongson3-virt". It may be superseded in
> > > > > future by a real machine model. If this happens, a regular deprecation
> > > > > procedure shall occur for "loongson3-virt" machine."
> > > > >
> > > > OK, this will be added, and I will rename to "loongson3-virt-1.0",
> > > > which can be updated in future.
> > > > But I think rename the name string is enough, file names and function
> > > > names can keep their old names.
> > Why ARM can use version name?
> > virt-2.10 QEMU 2.10 ARM Virtual Machine
> > virt-2.11 QEMU 2.11 ARM Virtual Machine
> > virt-2.12 QEMU 2.12 ARM Virtual Machine
> > virt-2.6 QEMU 2.6 ARM Virtual Machine
> > virt-2.7 QEMU 2.7 ARM Virtual Machine
> > virt-2.8 QEMU 2.8 ARM Virtual Machine
> > virt-2.9 QEMU 2.9 ARM Virtual Machine
> > virt-3.0 QEMU 3.0 ARM Virtual Machine
> > virt-3.1 QEMU 3.1 ARM Virtual Machine
> > virt-4.0 QEMU 4.0 ARM Virtual Machine
> > virt-4.1 QEMU 4.1 ARM Virtual Machine
> > virt-4.2 QEMU 4.2 ARM Virtual Machine
> > virt QEMU 5.0 ARM Virtual Machine (alias of virt-5.0)
> >
> > In future will will replace i8259 with an advanced PIC, that will be
> > loongson3-virt-2.0.
> >
i8259 is not the best choice, but it is simple. Replacing i8259 with
an advanced PIC is our future plan (loongson3-virt-2.0 will not
replace loongson3-virt-1.0, but co-exist with it), but it need lots of
effort. If we can't use a version number for a machine type, what is
the best method?

> > > >
> > >
> > > Loongson3 is instruction set name, not a machine name, and treating
> > > such name as machine name is incorrect. Renaming as I outlined in my
> > > comments must occur.
> > In future, both real machine and virtual machine models will be
> > implement in the same file, so I think loongson3.c is better than
> > loongson3-virt.c
> >
>
> I don't see any significant advantage of departing of existing
> one-main-source-file-per-machine principle.
In my opinion, if two machine models share more than 90% of the code,
they can be implemented in the same file. In hw/i386/pc.c there are
many machine models (GlobalProperty). Maybe it is another bad example?

I'm not insisting on my bad practice, but I need some "correct style"
to achieve my goal.

Huacai
>
> Regards,
> Aleksandar
>
> > >
> > > Yours,
> > > Aleksandar
> > >
> > > > Huacai
> > > > > > We already have a full functional Linux kernel (based on 
> > > > > > Linux-5.4.x LTS
> > > > > > but not upstream yet) here:
> > > > > >
> > > > > > https://github.com/chenhuacai/linux
> > > > > >
> > > > > > How to use QEMU/Loongson-3?
> > > > > > 1, Download kernel source from the above URL;
> > > > > > 2, Build a kernel with arch/mips/configs/loongson3_{def,hpc}config;
> > > > > > 3, Boot the a Loongson-3A4000 host with this kernel;
> > > > > > 4, Build QEMU-5.0.0 with this patchset;
> > > > > > 5, modprobe kvm;
> > > > > > 6, Use QEMU with TCG (available in future):
> > > > > >qemu-system-mips64el -M loongson3,accel=tcg -cpu 
> > > > > > Loongson-3A1000 -kernel  -append ...
> > > > >
> > > > > Machine should be named loongson3-virt.
> > > > >
> > > > > >Use QEMU with KVM (available at present):
> > > > > >qemu-system-mips64el -M loongson3,accel=kvm -cpu 
> > > > > > Loongson-3A4000 -kernel  -append ...
> > > > > >
> > > > >
> > > > > Machine should be named loongson3-virt.
> > > > >
> > > > > >The "-cpu" parameter can be omitted here and QEMU will use the 
> > > > > > correct type for TCG/KVM automatically.
> > > > > >
> > > > >
> > > > > This is not a good approach, the cpu parameter should be required,
> > > > > and, if it is not correct for particular circumstance, an error
> > > > > message should be emitted to the user, and the emulation terminated.
> > > > >
> > > > > > Signed-off-by: Huacai Chen 
> > > > > > Co-developed-by: Jiaxun Yang 
> > > > > > ---
> > > > > >  default-configs/mips64el-softmmu.mak |   1 +
> > > > > >  hw/mips/Kconfig  |  10 +
>

Re: [PATCH v2] hmp: Make json format optional for qom-set

David Hildenbrand  writes:

> Commit 7d2ef6dcc1cf ("hmp: Simplify qom-set") switched to the json
> parser, making it possible to specify complex types. However, with this
> change it is no longer possible to specify proper sizes (e.g., 2G, 128M),
> turning the interface harder to use for properties that consume sizes.
>
> Let's switch back to the previous handling and allow to specify passing
> json via the "-j" parameter.

Two issues:

1. Makes qom-get and qom-set inconsistent

   qom-get formats as JSON, always.

   qom-set parses the string visitor's undocumented ad hoc language by
   default.  You can make it parse JSON by passing -j.

   Not a show stopper, but sure ugly.  I feel documentation should point
   it out.

2. Rearms the string visitor death trap

   If you try to qom-set a property whose ->set() uses something the
   string input visitor doesn't support, QEMU crashes.  I'm not aware of
   such a ->set(), but this is a death trap all the same.  Mind, I
   didn't actually *look* for such a ->set().  Details:

Subject: Re: [RFC PATCH] qom: Implement qom-get HMP command
Date: Sat, 02 May 2020 08:02:43 +0200 (6 weeks, 2 days, 4 minutes ago)
Message-ID: <87a72q6fi4@dusky.pond.sub.org>
https://lists.nongnu.org/archive/html/qemu-devel/2020-05/msg00178.html

   Since we've had this death trap in the code for a number of years, I
   can't call its restoration a show stopper.  It does feel like an
   unadvisable risk, though.

Re: [PATCH v8 5/5] crypto/tls-cipher-suites: Produce fw_cfg consumable blob

On 06/09/20 19:07, Philippe Mathieu-Daudé wrote:
> Since our format is consumable by the fw_cfg device,
> we can implement the FW_CFG_DATA_GENERATOR interface.
> 
> Acked-by: Laszlo Ersek 
> Signed-off-by: Philippe Mathieu-Daudé 
> ---
> v8: Add example in qemu-options.hx
> ---
>  crypto/tls-cipher-suites.c | 19 +++
>  qemu-options.hx| 19 +++
>  2 files changed, 38 insertions(+)
> 
> diff --git a/crypto/tls-cipher-suites.c b/crypto/tls-cipher-suites.c
> index f02a041f9a..d6ea0ed190 100644
> --- a/crypto/tls-cipher-suites.c
> +++ b/crypto/tls-cipher-suites.c
> @@ -14,6 +14,7 @@
>  #include "qemu/error-report.h"
>  #include "crypto/tlscreds.h"
>  #include "crypto/tls-cipher-suites.h"
> +#include "hw/nvram/fw_cfg.h"
>  #include "trace.h"
>  
>  static void parse_cipher_suites(QCryptoTLSCipherSuites *s,
> @@ -99,11 +100,28 @@ static void qcrypto_tls_cipher_suites_finalize(Object 
> *obj)
>  g_free(s->cipher_list);
>  }
>  
> +static const void *qcrypto_tls_cipher_suites_get_data(Object *obj)
> +{
> +QCryptoTLSCipherSuites *s = QCRYPTO_TLS_CIPHER_SUITES(obj);
> +
> +return s->cipher_list;
> +}
> +
> +static size_t qcrypto_tls_cipher_suites_get_length(Object *obj)
> +{
> +QCryptoTLSCipherSuites *s = QCRYPTO_TLS_CIPHER_SUITES(obj);
> +
> +return s->cipher_count * sizeof(IANA_TLS_CIPHER);
> +}
> +
>  static void qcrypto_tls_cipher_suites_class_init(ObjectClass *oc, void *data)
>  {
>  UserCreatableClass *ucc = USER_CREATABLE_CLASS(oc);
> +FWCfgDataGeneratorClass *fwgc = FW_CFG_DATA_GENERATOR_CLASS(oc);
>  
>  ucc->complete = qcrypto_tls_cipher_suites_complete;
> +fwgc->get_data = qcrypto_tls_cipher_suites_get_data;
> +fwgc->get_length = qcrypto_tls_cipher_suites_get_length;
>  }
>  
>  static const TypeInfo qcrypto_tls_cipher_suites_info = {
> @@ -115,6 +133,7 @@ static const TypeInfo qcrypto_tls_cipher_suites_info = {
>  .class_init = qcrypto_tls_cipher_suites_class_init,
>  .interfaces = (InterfaceInfo[]) {
>  { TYPE_USER_CREATABLE },
> +{ TYPE_FW_CFG_DATA_GENERATOR_INTERFACE },
>  { }
>  }
>  };
> diff --git a/qemu-options.hx b/qemu-options.hx
> index c74366d7cc..b12cc910e3 100644
> --- a/qemu-options.hx
> +++ b/qemu-options.hx
> @@ -4585,6 +4585,25 @@ SRST
>  string as described at
>  https://gnutls.org/manual/html_node/Priority-Strings.html.
>  
> +An example of use of this object is to enable the UEFI HTTPS Boot.

(1) s/enable the/control/

(yes, please drop the "the")

> +The tls-cipher-suites object exposes the ordered list of permitted
> +TLS cipher suites from the host side to the firmware, via

(2) s/firmware/guest firmware/

> +fw_cfg. The list is represented as an array of IANA_TLS_CIPHER
> +objects. The firmware uses the IANA_TLS_CIPHER array for configuring
> +guest-side TLS.
> +
> +In the following example, the priority at which the host-side policy
> +is retrieved is given by the ``priority`` property of the new object
> +type. ``priority=@SYSTEM`` may be used to refer to

(3) s/ of the new object type//

Acked-by: Laszlo Ersek 

Thanks
Laszlo

> +/etc/crypto-policies/back-ends/gnutls.config (given that QEMU uses
> +GNUTLS).
> +
> +.. parsed-literal::
> +
> + # |qemu_system| \
> + -object tls-cipher-suites,id=mysuite0,priority=@SYSTEM \
> + -fw_cfg name=etc/edk2/https/ciphers,gen_id=mysuite0
> +
>  ``-object 
> filter-buffer,id=id,netdev=netdevid,interval=t[,queue=all|rx|tx][,status=on|off][,position=head|tail|id=][,insert=behind|before]``
>  Interval t can't be 0, this filter batches the packet delivery:
>  all packets arriving in a given interval on netdev netdevid are
>

Re: [PATCH v3 09/24] macio: Fix to realize "mos6522-cuda" and "mos6522-pmu" devices

On 6/15/20 7:26 AM, Markus Armbruster wrote:
> Peter, forgot to cc: you.  May I have your blessings for this version?

This file is maintained by Mark:

./scripts/get_maintainer.pl -f hw/misc/macio/cuda.c
Mark Cave-Ayland  (odd fixer:Old World
(g3beige))
David Gibson  (reviewer:Old World (g3beige))
qemu-...@nongnu.org (open list:Old World (g3beige))

Mark only check qemu-devel during week-end. Too bad you forgot
to Cc him, has he did a review pass over the last WE.

> 
> Markus Armbruster  writes:
> 
>> cuda_init() creates a "mos6522-cuda" device, but it's never realized.
>> Affects machines mac99 with via=cuda (default) and g3beige.
>>
>> pmu_init() creates a "mos6522-pmu" device, but it's never realized.
>> Affects machine mac99 with via=pmu and via=pmu-adb,
>>
>> In theory, a device becomes real only on realize.  In practice, the
>> transition from unreal to real is a fuzzy one.  The work to make a
>> device real can be spread between realize methods (fine),
>> instance_init methods (wrong), and board code wiring up the device
>> (fine as long as it effectively happens on realize).  Depending on
>> what exactly is done where, a device can work even when we neglect
>> to realize it.
>>
>> These two appear to work.  Nevertheless, it's a clear misuse of the
>> interface.  Even when it works today (more or less by chance), it can
>> break tomorrow.
>>
>> Fix by realizing them in cuda_realize() and pmu_realize(),
>> respectively.
>>
>> Fixes: 6dca62af95e0b7020aa00d0ca9b2c421f341
>> Cc: Laurent Vivier 
>> Signed-off-by: Markus Armbruster 

Reviewed-by: Philippe Mathieu-Daudé 

>> ---
>>  hw/misc/macio/cuda.c | 15 ++-
>>  hw/misc/macio/pmu.c  | 15 ++-
>>  2 files changed, 20 insertions(+), 10 deletions(-)
>>
>> diff --git a/hw/misc/macio/cuda.c b/hw/misc/macio/cuda.c
>> index e0cc0aac5d..3cb10c743c 100644
>> --- a/hw/misc/macio/cuda.c
>> +++ b/hw/misc/macio/cuda.c
>> @@ -33,6 +33,7 @@
>>  #include "hw/misc/macio/cuda.h"
>>  #include "qemu/timer.h"
>>  #include "sysemu/runstate.h"
>> +#include "qapi/error.h"
>>  #include "qemu/cutils.h"
>>  #include "qemu/log.h"
>>  #include "qemu/module.h"
>> @@ -522,16 +523,20 @@ static void cuda_reset(DeviceState *dev)
>>  static void cuda_realize(DeviceState *dev, Error **errp)
>>  {
>>  CUDAState *s = CUDA(dev);
>> +Error *err = NULL;
>>  SysBusDevice *sbd;
>> -MOS6522State *ms;
>> -DeviceState *d;
>>  struct tm tm;
>>  
>> +object_property_set_bool(OBJECT(&s->mos6522_cuda), true, "realized",
>> + &err);
>> +if (err) {
>> +error_propagate(errp, err);
>> +return;
>> +}
>> +
>>  /* Pass IRQ from 6522 */
>> -d = DEVICE(&s->mos6522_cuda);
>> -ms = MOS6522(d);
>>  sbd = SYS_BUS_DEVICE(s);
>> -sysbus_pass_irq(sbd, SYS_BUS_DEVICE(ms));
>> +sysbus_pass_irq(sbd, SYS_BUS_DEVICE(&s->mos6522_cuda));
>>  
>>  qemu_get_timedate(&tm, 0);
>>  s->tick_offset = (uint32_t)mktimegm(&tm) + RTC_OFFSET;
>> diff --git a/hw/misc/macio/pmu.c b/hw/misc/macio/pmu.c
>> index 9a9cd427e1..0895b78b59 100644
>> --- a/hw/misc/macio/pmu.c
>> +++ b/hw/misc/macio/pmu.c
>> @@ -40,6 +40,7 @@
>>  #include "hw/misc/macio/pmu.h"
>>  #include "qemu/timer.h"
>>  #include "sysemu/runstate.h"
>> +#include "qapi/error.h"
>>  #include "qemu/cutils.h"
>>  #include "qemu/log.h"
>>  #include "qemu/module.h"
>> @@ -739,16 +740,20 @@ static void pmu_reset(DeviceState *dev)
>>  static void pmu_realize(DeviceState *dev, Error **errp)
>>  {
>>  PMUState *s = VIA_PMU(dev);
>> +Error *err = NULL;
>>  SysBusDevice *sbd;
>> -MOS6522State *ms;
>> -DeviceState *d;
>>  struct tm tm;
>>  
>> +object_property_set_bool(OBJECT(&s->mos6522_pmu), true, "realized",
>> + &err);
>> +if (err) {
>> +error_propagate(errp, err);
>> +return;
>> +}
>> +
>>  /* Pass IRQ from 6522 */
>> -d = DEVICE(&s->mos6522_pmu);
>> -ms = MOS6522(d);
>>  sbd = SYS_BUS_DEVICE(s);
>> -sysbus_pass_irq(sbd, SYS_BUS_DEVICE(ms));
>> +sysbus_pass_irq(sbd, SYS_BUS_DEVICE(&s->mos6522_pmu));
>>  
>>  qemu_get_timedate(&tm, 0);
>>  s->tick_offset = (uint32_t)mktimegm(&tm) + RTC_OFFSET;
> 
>

Re: [PATCH v8 4/5] crypto: Add tls-cipher-suites object

On 06/09/20 19:07, Philippe Mathieu-Daudé wrote:
> On the host OS, various aspects of TLS operation are configurable.
> In particular it is possible for the sysadmin to control the TLS
> cipher/protocol algorithms that applications are permitted to use.
> 
> * Any given crypto library has a built-in default priority list
>   defined by the distro maintainer of the library package (or by
>   upstream).
> 
> * The "crypto-policies" RPM (or equivalent host OS package)
>   provides a config file such as "/etc/crypto-policies/config",
>   where the sysadmin can set a high level (library-independent)
>   policy.
> 
>   The "update-crypto-policies --set" command (or equivalent) is
>   used to translate the global policy to individual library
>   representations, producing files such as
>   "/etc/crypto-policies/back-ends/*.config". The generated files,
>   if present, are loaded by the various crypto libraries to
>   override their own built-in defaults.
> 
>   For example, the GNUTLS library may read
>   "/etc/crypto-policies/back-ends/gnutls.config".
> 
> * A management application (or the QEMU user) may overide the
>   system-wide crypto-policies config via their own config, if
>   they need to diverge from the former.
> 
> Thus the priority order is "QEMU user config" > "crypto-policies
> system config" > "library built-in config".
> 
> Introduce the "tls-cipher-suites" object for exposing the ordered
> list of permitted TLS cipher suites from the host side to the
> guest firmware, via fw_cfg. The list is represented as an array
> of IANA_TLS_CIPHER objects. The firmware uses the IANA_TLS_CIPHER
> array for configuring guest-side TLS, for example in UEFI HTTPS
> Boot.
> 
> The priority at which the host-side policy is retrieved is given
> by the "priority" property of the new object type. For example,
> "priority=@SYSTEM" may be used to refer to
> "/etc/crypto-policies/back-ends/gnutls.config" (given that QEMU
> uses GNUTLS).
> 
> [Description from Daniel P. Berrangé, edited by Laszlo Ersek.]
> 
> Example of use to dump the cipher suites:
> 
>   $ qemu-system-x86_64 -S \
> -object tls-cipher-suites,id=mysuite,priority=@SYSTEM \
> -trace qcrypto\*
>   159066.197123:qcrypto_tls_cipher_suite_priority priority: @SYSTEM
>   159066.197219:qcrypto_tls_cipher_suite_info data=[0x13,0x02] 
> version=TLS1.3 name=TLS_AES_256_GCM_SHA384
>   159066.197228:qcrypto_tls_cipher_suite_info data=[0x13,0x03] 
> version=TLS1.3 name=TLS_CHACHA20_POLY1305_SHA256
>   159066.197233:qcrypto_tls_cipher_suite_info data=[0x13,0x01] 
> version=TLS1.3 name=TLS_AES_128_GCM_SHA256
>   159066.197236:qcrypto_tls_cipher_suite_info data=[0x13,0x04] 
> version=TLS1.3 name=TLS_AES_128_CCM_SHA256
>   159066.197240:qcrypto_tls_cipher_suite_info data=[0xc0,0x30] 
> version=TLS1.2 name=TLS_ECDHE_RSA_AES_256_GCM_SHA384
>   159066.197245:qcrypto_tls_cipher_suite_info data=[0xcc,0xa8] 
> version=TLS1.2 name=TLS_ECDHE_RSA_CHACHA20_POLY1305
>   159066.197250:qcrypto_tls_cipher_suite_info data=[0xc0,0x14] 
> version=TLS1.0 name=TLS_ECDHE_RSA_AES_256_CBC_SHA1
>   159066.197254:qcrypto_tls_cipher_suite_info data=[0xc0,0x2f] 
> version=TLS1.2 name=TLS_ECDHE_RSA_AES_128_GCM_SHA256
>   159066.197258:qcrypto_tls_cipher_suite_info data=[0xc0,0x13] 
> version=TLS1.0 name=TLS_ECDHE_RSA_AES_128_CBC_SHA1
>   159066.197261:qcrypto_tls_cipher_suite_info data=[0xc0,0x2c] 
> version=TLS1.2 name=TLS_ECDHE_ECDSA_AES_256_GCM_SHA384
>   159066.197266:qcrypto_tls_cipher_suite_info data=[0xcc,0xa9] 
> version=TLS1.2 name=TLS_ECDHE_ECDSA_CHACHA20_POLY1305
>   159066.197270:qcrypto_tls_cipher_suite_info data=[0xc0,0xad] 
> version=TLS1.2 name=TLS_ECDHE_ECDSA_AES_256_CCM
>   159066.197274:qcrypto_tls_cipher_suite_info data=[0xc0,0x0a] 
> version=TLS1.0 name=TLS_ECDHE_ECDSA_AES_256_CBC_SHA1
>   159066.197278:qcrypto_tls_cipher_suite_info data=[0xc0,0x2b] 
> version=TLS1.2 name=TLS_ECDHE_ECDSA_AES_128_GCM_SHA256
>   159066.197283:qcrypto_tls_cipher_suite_info data=[0xc0,0xac] 
> version=TLS1.2 name=TLS_ECDHE_ECDSA_AES_128_CCM
>   159066.197287:qcrypto_tls_cipher_suite_info data=[0xc0,0x09] 
> version=TLS1.0 name=TLS_ECDHE_ECDSA_AES_128_CBC_SHA1
>   159066.197291:qcrypto_tls_cipher_suite_info data=[0x00,0x9d] 
> version=TLS1.2 name=TLS_RSA_AES_256_GCM_SHA384
>   159066.197296:qcrypto_tls_cipher_suite_info data=[0xc0,0x9d] 
> version=TLS1.2 name=TLS_RSA_AES_256_CCM
>   159066.197300:qcrypto_tls_cipher_suite_info data=[0x00,0x35] 
> version=TLS1.0 name=TLS_RSA_AES_256_CBC_SHA1
>   159066.197304:qcrypto_tls_cipher_suite_info data=[0x00,0x9c] 
> version=TLS1.2 name=TLS_RSA_AES_128_GCM_SHA256
>   159066.197308:qcrypto_tls_cipher_suite_info data=[0xc0,0x9c] 
> version=TLS1.2 name=TLS_RSA_AES_128_CCM
>   159066.197312:qcrypto_tls_cipher_suite_info data=[0x00,0x2f] 
> version=TLS1.0 name=TLS_RSA_AES_128_CBC_SHA1
>   159066.197316:qcrypto_tls_cipher_suite_info data=[0x00,0x9f] 
> version=TLS

Re: [PATCH] hw/xen_pt: Don't grant opregion permissions

Hi Grzegorz,

On 6/15/20 1:21 AM, Grzegorz Uriasz wrote:
> With the upstreaming of linux based stubdomains to xen, qemu can't
> assume it runs inside dom0 - permission assignment must be moved to
> libxl running in dom0. This xen patch:
> https://lists.xenproject.org/archives/html/xen-devel/2020-06/msg00973.html
> implements granting the required permissions to the stubdomain running
> qemu. This patch removes granting opregion permissions in qemu - this
> should be fine as when qemu is running inside dom0 the memory mapping will
> be successfully created without first explicitly granting the permission.
> 
> Signed-off-by: Grzegorz Uriasz 
> ---
>  hw/xen/xen_pt_graphics.c | 13 -
>  1 file changed, 13 deletions(-)
> 
> diff --git a/hw/xen/xen_pt_graphics.c b/hw/xen/xen_pt_graphics.c
> index 7d46e9c209..303674365b 100644
> --- a/hw/xen/xen_pt_graphics.c
> +++ b/hw/xen/xen_pt_graphics.c
> @@ -283,19 +283,6 @@ void igd_write_opregion(XenPCIPassthroughState *s, 
> uint32_t val)
>  igd_guest_opregion = (unsigned long)(val & ~XEN_PCI_INTEL_OPREGION_MASK)
>  | (igd_host_opregion & 
> XEN_PCI_INTEL_OPREGION_MASK);
>  
> -ret = xc_domain_iomem_permission(xen_xc, xen_domid,
> -(unsigned long)(igd_host_opregion >> XC_PAGE_SHIFT),
> -XEN_PCI_INTEL_OPREGION_PAGES,
> -XEN_PCI_INTEL_OPREGION_ENABLE_ACCESSED);
> -
> -if (ret) {
> -XEN_PT_ERR(&s->dev, "[%d]:Can't enable to access IGD host opregion:"
> -" 0x%lx.\n", ret,
> -(unsigned long)(igd_host_opregion >> XC_PAGE_SHIFT)),
> -igd_guest_opregion = 0;
> -return;
> -}

Shouldn't this be somehow versioned? I.e. if the libxl does not have
the change then keep the current code?

> -
>  ret = xc_domain_memory_mapping(xen_xc, xen_domid,
>  (unsigned long)(igd_guest_opregion >> XC_PAGE_SHIFT),
>  (unsigned long)(igd_host_opregion >> XC_PAGE_SHIFT),
>

Re: [PATCH for-5.1 V4 3/4] hw/mips: Add Loongson-3 machine support (with KVM)

пон, 15. јун 2020. у 07:36 Huacai Chen  је написао/ла:
>
> Hi, Aleksandar,
>
> On Mon, Jun 15, 2020 at 12:50 PM Aleksandar Markovic
>  wrote:
> >
> > пон, 15. јун 2020. у 02:55 Huacai Chen  је написао/ла:
> > >
> > > Hi, Aleksandar,
> > >
> > > On Sun, Jun 14, 2020 at 3:51 PM Aleksandar Markovic
> > >  wrote:
> > > >
> > > > Hi, Huacai, this is another round of comments, that should be addressed 
> > > > in v5.
> > > >
> > > > уто, 2. јун 2020. у 04:40 Huacai Chen  је 
> > > > написао/ла:
> > > > >
> > > > > Add Loongson-3 based machine support, it use i8259 as the interrupt
> > > > > controler and use GPEX as the pci controller. Currently it can only
> > > > > work with KVM, but we will add TCG support in future.
> > > > >
> > > >
> > > > Add this paragraph at this place in the commit message:
> > > >
> > > > "As the machine model is not based on any exiting physical hardware,
> > > > the name of the machine is "loongson3-virt". It may be superseded in
> > > > future by a real machine model. If this happens, a regular deprecation
> > > > procedure shall occur for "loongson3-virt" machine."
> > > >
> > > OK, this will be added, and I will rename to "loongson3-virt-1.0",
> > > which can be updated in future.
> > > But I think rename the name string is enough, file names and function
> > > names can keep their old names.
> Why ARM can use version name?
> virt-2.10 QEMU 2.10 ARM Virtual Machine
> virt-2.11 QEMU 2.11 ARM Virtual Machine
> virt-2.12 QEMU 2.12 ARM Virtual Machine
> virt-2.6 QEMU 2.6 ARM Virtual Machine
> virt-2.7 QEMU 2.7 ARM Virtual Machine
> virt-2.8 QEMU 2.8 ARM Virtual Machine
> virt-2.9 QEMU 2.9 ARM Virtual Machine
> virt-3.0 QEMU 3.0 ARM Virtual Machine
> virt-3.1 QEMU 3.1 ARM Virtual Machine
> virt-4.0 QEMU 4.0 ARM Virtual Machine
> virt-4.1 QEMU 4.1 ARM Virtual Machine
> virt-4.2 QEMU 4.2 ARM Virtual Machine
> virt QEMU 5.0 ARM Virtual Machine (alias of virt-5.0)
>
> In future will will replace i8259 with an advanced PIC, that will be
> loongson3-virt-2.0.
>
> > >
> >
> > Loongson3 is instruction set name, not a machine name, and treating
> > such name as machine name is incorrect. Renaming as I outlined in my
> > comments must occur.
> In future, both real machine and virtual machine models will be
> implement in the same file, so I think loongson3.c is better than
> loongson3-virt.c
>

I don't see any significant advantage of departing of existing
one-main-source-file-per-machine principle.

Regards,
Aleksandar

> >
> > Yours,
> > Aleksandar
> >
> > > Huacai
> > > > > We already have a full functional Linux kernel (based on Linux-5.4.x 
> > > > > LTS
> > > > > but not upstream yet) here:
> > > > >
> > > > > https://github.com/chenhuacai/linux
> > > > >
> > > > > How to use QEMU/Loongson-3?
> > > > > 1, Download kernel source from the above URL;
> > > > > 2, Build a kernel with arch/mips/configs/loongson3_{def,hpc}config;
> > > > > 3, Boot the a Loongson-3A4000 host with this kernel;
> > > > > 4, Build QEMU-5.0.0 with this patchset;
> > > > > 5, modprobe kvm;
> > > > > 6, Use QEMU with TCG (available in future):
> > > > >qemu-system-mips64el -M loongson3,accel=tcg -cpu 
> > > > > Loongson-3A1000 -kernel  -append ...
> > > >
> > > > Machine should be named loongson3-virt.
> > > >
> > > > >Use QEMU with KVM (available at present):
> > > > >qemu-system-mips64el -M loongson3,accel=kvm -cpu 
> > > > > Loongson-3A4000 -kernel  -append ...
> > > > >
> > > >
> > > > Machine should be named loongson3-virt.
> > > >
> > > > >The "-cpu" parameter can be omitted here and QEMU will use the 
> > > > > correct type for TCG/KVM automatically.
> > > > >
> > > >
> > > > This is not a good approach, the cpu parameter should be required,
> > > > and, if it is not correct for particular circumstance, an error
> > > > message should be emitted to the user, and the emulation terminated.
> > > >
> > > > > Signed-off-by: Huacai Chen 
> > > > > Co-developed-by: Jiaxun Yang 
> > > > > ---
> > > > >  default-configs/mips64el-softmmu.mak |   1 +
> > > > >  hw/mips/Kconfig  |  10 +
> > > > >  hw/mips/Makefile.objs|   1 +
> > > > >  hw/mips/loongson3.c  | 901 
> > > > > +++
> > > >
> > > > The name of the file should be loongson3-virt.c
> > > >
> > > > >  4 files changed, 913 insertions(+)
> > > > >  create mode 100644 hw/mips/loongson3.c
> > > > >
> > > > > diff --git a/default-configs/mips64el-softmmu.mak 
> > > > > b/default-configs/mips64el-softmmu.mak
> > > > > index 9f8a3ef..2a2a3fb 100644
> > > > > --- a/default-configs/mips64el-softmmu.mak
> > > > > +++ b/default-configs/mips64el-softmmu.mak
> > > > > @@ -3,6 +3,7 @@
> > > > >  include mips-softmmu-common.mak
> > > > >  CONFIG_IDE_VIA=y
> > > > >  CONFIG_FULOONG=y
> > > > > +CONFIG_LOONGSON3=y
> > > >
> > > > CONFIG_LOONGSON3-VIRT
> > > >
> > > > >  CONFIG_ATI_VGA=y
> > > > >  CONFIG_RTL8139_PCI=y
> > > > >  CONFIG_JAZZ=y
> > > > > diff --git a/hw/mips/K

Re: [RFC PATCH 2/5] hw/misc/led: Add LED_STATUS_CHANGED QAPI event

Philippe Mathieu-Daudé  writes:

> Hi Eric,
>
> On 6/9/20 4:29 PM, Eric Blake wrote:
>> On 6/9/20 7:34 AM, Philippe Mathieu-Daudé wrote:
>>> Allow LED devices to emit STATUS_CHANGED events on a QMP chardev.
>>>
>>> QMP event examples:
>>>
>>> {
>>>  "timestamp": {
>>>  "seconds": 1591704274,
>>>  "microseconds": 520850
>>>  },
>>>  "event": "LED_STATUS_CHANGED",
>>>  "data": {
>>>  "name": "Green LED #0",
>>>  "status": "on"
>>>  }
>>> }
>>> {
>>>  "timestamp": {
>>>  "seconds": 1591704275,
>>>  "microseconds": 530912
>>>  },
>>>  "event": "LED_STATUS_CHANGED",
>>>  "data": {
>>>  "name": "Green LED #0",
>>>  "status": "off"
>>>  }
>>> }
>>>
>>> Signed-off-by: Philippe Mathieu-Daudé 
>>> ---
>> 
>> The QAPI addition looks reasonable, however,
>> 
>>> +++ b/hw/misc/led.c
>>> @@ -7,6 +7,7 @@
>>>    */
>>>   #include "qemu/osdep.h"
>>>   #include "qapi/error.h"
>>> +#include "qapi/qapi-events-led.h"
>>>   #include "hw/qdev-properties.h"
>>>   #include "hw/misc/led.h"
>>>   #include "hw/irq.h"
>>> @@ -19,6 +20,9 @@ static void led_set(void *opaque, int line, int
>>> new_state)
>>>     trace_led_set(s->name, s->current_state, new_state);
>>>   +    /* FIXME QMP rate limite? */
>> 
>> s/limite/limit/
>> 
>> Yes, this is under guest control, so you MUST rate limit to avoid the
>> guest being able to DoS qemu by changing the LED so frequently as to
>> overwhelm the QMP connection with events.
>
> Commits f544d174dfc and 7f1e7b23d5 refers to the qmp-events.txt
> for documentation on rate-limiting QMP events, but I can't find
> it in the codebase. Two files matches 'qmp-events' but don't have
> documentation: qapi/qmp-event.c and include/qapi/qmp-event.h.
>
> Last trace of it is in commit 231aaf3a8217. Apparently it was
> somehow split qapi/event.json, then later c09656f1d392 move it
> to qapi-schema.json, finally eb815e248f50 moved it to qapi/.
>
> Is the referred documentation now in docs/devel/qapi-code-gen.txt?
> There is only one occurence of 'limit' but it is unrelated to
> rate-limit.

Commit 231aaf3a8217 is part of Marc-André's herculean QAPI/QMP doc
reorganization: use only schema doc comments instead of spreading the
knowledge over schema and several other files, with duplicated contents,
confused readers, and annoyed writers.

Before the reorganization, docs/qmp-events.txt listed the QMP events,
and rate-limited events carried a

Note: this event is rate-limited.

The reorganization moved this note into its event's doc comment.
Example:

##
# @WATCHDOG:
#
# Emitted when the watchdog device's timer is expired
#
# @action: action that has been taken
#
# Note: If action is "reset", "shutdown", or "pause" the WATCHDOG event is
#   followed respectively by the RESET, SHUTDOWN, or STOP events
#
--> # Note: This event is rate-limited.
#
[...]
##
{ 'event': 'WATCHDOG',
  'data': { 'action': 'WatchdogAction' } }

The QMP *protocol* is still documented in docs/interop/qmp-spec.txt.
Relevant part:

2.5 Asynchronous events
---

As a result of state changes, the Server may send messages unilaterally
to the Client at any time, when not in the middle of any other
response. They are called "asynchronous events".

The format of asynchronous events is:

{ "event": json-string, "data": json-object,
  "timestamp": { "seconds": json-number, "microseconds": json-number } }

 Where,

- The "event" member contains the event's name
- The "data" member contains event specific data, which is defined in a
  per-event basis, it is optional
- The "timestamp" member contains the exact time of when the event
  occurred in the Server. It is a fixed json-object with time in
  seconds and microseconds relative to the Unix Epoch (1 Jan 1970); if
  there is a failure to retrieve host time, both members of the
  timestamp will be set to -1.

For a listing of supported asynchronous events, please, refer to the
qmp-events.txt file.

Some events are rate-limited to at most one per second.  If additional
"similar" events arrive within one second, all but the last one are
dropped, and the last one is delayed.  "Similar" normally means same
event type.  See qmp-events.txt for details.

The reorganization neglected to update it for the removal of
qmp-events.txt.  Should point to
docs/interop/qemu-qmp-ref.{7,html,info,pdf,txt} now.

Event rate-limiting is defined in monitor_qapi_event_conf[].  To
rate-limit an event, add it to monitor_qapi_event_conf[], and also add
the "Note: This event is rate-limited." to its schema doc comment.

Doc bug: commit e2ae6159de "virtio-serial: report frontend connection
state via monitor" neglected to add the note.

Patches welcome!

Re: [PATCH for-5.1 V4 3/4] hw/mips: Add Loongson-3 machine support (with KVM)

пон, 15. јун 2020. у 07:36 Huacai Chen  је написао/ла:
>
> Hi, Aleksandar,
>
> On Mon, Jun 15, 2020 at 12:50 PM Aleksandar Markovic
>  wrote:
> >
> > пон, 15. јун 2020. у 02:55 Huacai Chen  је написао/ла:
> > >
> > > Hi, Aleksandar,
> > >
> > > On Sun, Jun 14, 2020 at 3:51 PM Aleksandar Markovic
> > >  wrote:
> > > >
> > > > Hi, Huacai, this is another round of comments, that should be addressed 
> > > > in v5.
> > > >
> > > > уто, 2. јун 2020. у 04:40 Huacai Chen  је 
> > > > написао/ла:
> > > > >
> > > > > Add Loongson-3 based machine support, it use i8259 as the interrupt
> > > > > controler and use GPEX as the pci controller. Currently it can only
> > > > > work with KVM, but we will add TCG support in future.
> > > > >
> > > >
> > > > Add this paragraph at this place in the commit message:
> > > >
> > > > "As the machine model is not based on any exiting physical hardware,
> > > > the name of the machine is "loongson3-virt". It may be superseded in
> > > > future by a real machine model. If this happens, a regular deprecation
> > > > procedure shall occur for "loongson3-virt" machine."
> > > >
> > > OK, this will be added, and I will rename to "loongson3-virt-1.0",
> > > which can be updated in future.
> > > But I think rename the name string is enough, file names and function
> > > names can keep their old names.
> Why ARM can use version name?
> virt-2.10 QEMU 2.10 ARM Virtual Machine
> virt-2.11 QEMU 2.11 ARM Virtual Machine
> virt-2.12 QEMU 2.12 ARM Virtual Machine
> virt-2.6 QEMU 2.6 ARM Virtual Machine
> virt-2.7 QEMU 2.7 ARM Virtual Machine
> virt-2.8 QEMU 2.8 ARM Virtual Machine
> virt-2.9 QEMU 2.9 ARM Virtual Machine
> virt-3.0 QEMU 3.0 ARM Virtual Machine
> virt-3.1 QEMU 3.1 ARM Virtual Machine
> virt-4.0 QEMU 4.0 ARM Virtual Machine
> virt-4.1 QEMU 4.1 ARM Virtual Machine
> virt-4.2 QEMU 4.2 ARM Virtual Machine
> virt QEMU 5.0 ARM Virtual Machine (alias of virt-5.0)
>
> In future will will replace i8259 with an advanced PIC, that will be
> loongson3-virt-2.0.

Huacai, you are making a mistake that I see over and over and over
again, most often with new contributors, but in some cases with
experienced contributors too.

QEMU is a complex system, made in various periods of time, its
internal interfaces and implementation approaches and principles also
changing in time. As a consequence, if you see an example in QEMU
code, it does not authomatically mean that you can or should make
something similar to that example.

As I said before, I would advice you to make future Loongson3 machines
reflect the real systems, but if you insist on making two or more
Loongson3 virtual machines, submit that proposal at some point in
future, and we will discuss it. Although I strongly discourage you
from doing that.

Yours,
Aleksandar

> > >
> >
> > Loongson3 is instruction set name, not a machine name, and treating
> > such name as machine name is incorrect. Renaming as I outlined in my
> > comments must occur.
> In future, both real machine and virtual machine models will be
> implement in the same file, so I think loongson3.c is better than
> loongson3-virt.c
>
> >
> > Yours,
> > Aleksandar
> >
> > > Huacai
> > > > > We already have a full functional Linux kernel (based on Linux-5.4.x 
> > > > > LTS
> > > > > but not upstream yet) here:
> > > > >
> > > > > https://github.com/chenhuacai/linux
> > > > >
> > > > > How to use QEMU/Loongson-3?
> > > > > 1, Download kernel source from the above URL;
> > > > > 2, Build a kernel with arch/mips/configs/loongson3_{def,hpc}config;
> > > > > 3, Boot the a Loongson-3A4000 host with this kernel;
> > > > > 4, Build QEMU-5.0.0 with this patchset;
> > > > > 5, modprobe kvm;
> > > > > 6, Use QEMU with TCG (available in future):
> > > > >qemu-system-mips64el -M loongson3,accel=tcg -cpu 
> > > > > Loongson-3A1000 -kernel  -append ...
> > > >
> > > > Machine should be named loongson3-virt.
> > > >
> > > > >Use QEMU with KVM (available at present):
> > > > >qemu-system-mips64el -M loongson3,accel=kvm -cpu 
> > > > > Loongson-3A4000 -kernel  -append ...
> > > > >
> > > >
> > > > Machine should be named loongson3-virt.
> > > >
> > > > >The "-cpu" parameter can be omitted here and QEMU will use the 
> > > > > correct type for TCG/KVM automatically.
> > > > >
> > > >
> > > > This is not a good approach, the cpu parameter should be required,
> > > > and, if it is not correct for particular circumstance, an error
> > > > message should be emitted to the user, and the emulation terminated.
> > > >
> > > > > Signed-off-by: Huacai Chen 
> > > > > Co-developed-by: Jiaxun Yang 
> > > > > ---
> > > > >  default-configs/mips64el-softmmu.mak |   1 +
> > > > >  hw/mips/Kconfig  |  10 +
> > > > >  hw/mips/Makefile.objs|   1 +
> > > > >  hw/mips/loongson3.c  | 901 
> > > > > +++
> > > >
> > > > The name of the file should be loongson3-virt.c
> > > >
> > > > >  4 files changed, 913 insertion

Re: [PATCH v8 3/5] softmmu/vl: Allow -fw_cfg 'gen_id' option to use the 'etc/' namespace

On 06/09/20 19:07, Philippe Mathieu-Daudé wrote:
> Names of user-provided fw_cfg items are supposed to start
> with "opt/". However FW_CFG_DATA_GENERATOR items are generated
> by QEMU, so allow the "etc/" namespace in this specific case.
> 
> Reviewed-by: Laszlo Ersek 
> Signed-off-by: Philippe Mathieu-Daudé 
> ---
> v8: addressed Laszlo's comments
> - reword commit description
> - invert nonempty_str() condition
> - new comment in docs/specs/fw_cfg.txt
> ---
>  docs/specs/fw_cfg.txt | 4 
>  softmmu/vl.c  | 8 +++-
>  2 files changed, 11 insertions(+), 1 deletion(-)

looks good, thanks!

RE: [PATCH 2/2] migration/colo/net: fix typo in the COLO Proxy module

2020-06-14 Thread Zhang, Chen




> -Original Message-
> From: Like Xu 
> Sent: Sunday, June 14, 2020 4:45 PM
> To: qemu-devel@nongnu.org
> Cc: Like Xu ; Zhang, Chen ;
> Li Zhijian 
> Subject: [PATCH 2/2] migration/colo/net: fix typo in the COLO Proxy module
> 
> Cc: Zhang Chen 
> Cc: Li Zhijian 
> Signed-off-by: Like Xu 


Looks good to me.
By the way, add CC qemu-triv...@nongnu.org
Reviewed-by: Zhang Chen 

Thanks
Zhang Chen

> ---
>  docs/colo-proxy.txt | 4 ++--
>  net/colo-compare.c  | 4 ++--
>  2 files changed, 4 insertions(+), 4 deletions(-)
> 
> diff --git a/docs/colo-proxy.txt b/docs/colo-proxy.txt index
> fa1cef0278..0bbd6f720a 100644
> --- a/docs/colo-proxy.txt
> +++ b/docs/colo-proxy.txt
> @@ -21,7 +21,7 @@ and filter-rewriter compose the COLO-proxy.
>  == Architecture ==
> 
>  COLO-Proxy is based on qemu netfilter and it's a plugin for qemu netfilter -
> (except colo-compare). It keep Secondary VM connect normally to
> +(except colo-compare). It keeps Secondary VM connect normally to
>  client and compare packets sent by PVM with sent by SVM.
>  If the packet difference, notify COLO-frame to do checkpoint and send  all
> primary packet has queued. Otherwise just send the queued primary @@ -
> 94,7 +94,7 @@ Redirect Server Filter --> COLO-Compare  COLO-compare
> receive primary guest packet then  waiting secondary redirect packet to
> compare it.
>  If packet same,send queued primary packet and clear -queued secondary
> packet, Otherwise send primary packet
> +queued secondary packet, otherwise send primary packet
>  and do checkpoint.
> 
>  COLO-Compare --> Another Redirector Filter diff --git a/net/colo-compare.c
> b/net/colo-compare.c index c07e7c1c09..3efc61c777 100644
> --- a/net/colo-compare.c
> +++ b/net/colo-compare.c
> @@ -658,7 +658,7 @@ static void colo_compare_packet(CompareState *s,
> Connection *conn,
>  g_queue_remove(&conn->secondary_list, result->data);
>  } else {
>  /*
> - * If one packet arrive late, the secondary_list or
> + * If one packet arrives late, the secondary_list or
>   * primary_list will be empty, so we can't compare it
>   * until next comparison. If the packets in the list are
>   * timeout, it will trigger a checkpoint request.
> @@ -1296,7 +1296,7 @@ static void colo_compare_finalize(Object *obj)
>  }
>  }
> 
> -/* Release all unhandled packets after compare thead exited */
> +/* Release all unhandled packets after compare thread exited */
>  g_queue_foreach(&s->conn_list, colo_flush_packets, s);
> 
>  g_queue_clear(&s->conn_list);
> --
> 2.21.3

Re: [PATCH v8 2/5] softmmu/vl: Let -fw_cfg option take a 'gen_id' argument

On 06/09/20 19:07, Philippe Mathieu-Daudé wrote:
> The 'gen_id' argument refers to a QOM object able to produce
> data consumable by the fw_cfg device. The producer object must
> implement the FW_CFG_DATA_GENERATOR interface.
> 
> Signed-off-by: Philippe Mathieu-Daudé 
> ---
> v8: addressed Laszlo's comments
> - fixed 2-space indent
> - do not return 0 on failure
> ---
>  softmmu/vl.c | 25 +
>  1 file changed, 17 insertions(+), 8 deletions(-)
> 
> diff --git a/softmmu/vl.c b/softmmu/vl.c
> index 05d1a4cb6b..a9bce2a1b1 100644
> --- a/softmmu/vl.c
> +++ b/softmmu/vl.c
> @@ -489,6 +489,11 @@ static QemuOptsList qemu_fw_cfg_opts = {
>  .name = "string",
>  .type = QEMU_OPT_STRING,
>  .help = "Sets content of the blob to be inserted from a string",
> +}, {
> +.name = "gen_id",
> +.type = QEMU_OPT_STRING,
> +.help = "Sets id of the object generating the fw_cfg blob "
> +"to be inserted",
>  },
>  { /* end of list */ }
>  },
> @@ -2020,7 +2025,7 @@ static int parse_fw_cfg(void *opaque, QemuOpts *opts, 
> Error **errp)
>  {
>  gchar *buf;
>  size_t size;
> -const char *name, *file, *str;
> +const char *name, *file, *str, *gen_id;
>  FWCfgState *fw_cfg = (FWCfgState *) opaque;
>  
>  if (fw_cfg == NULL) {
> @@ -2030,14 +2035,13 @@ static int parse_fw_cfg(void *opaque, QemuOpts *opts, 
> Error **errp)
>  name = qemu_opt_get(opts, "name");
>  file = qemu_opt_get(opts, "file");
>  str = qemu_opt_get(opts, "string");
> +gen_id = qemu_opt_get(opts, "gen_id");
>  
> -/* we need name and either a file or the content string */
> -if (!(nonempty_str(name) && (nonempty_str(file) || nonempty_str(str {
> -error_setg(errp, "invalid argument(s)");
> -return -1;
> -}
> -if (nonempty_str(file) && nonempty_str(str)) {
> -error_setg(errp, "file and string are mutually exclusive");
> +/* we need the name, and exactly one of: file, content string, gen_id */
> +if (!nonempty_str(name) ||
> +nonempty_str(file) + nonempty_str(str) + nonempty_str(gen_id) != 1) {
> +error_setg(errp, "name, plus exactly one of file,"
> + " string and gen_id, are needed");
>  return -1;
>  }
>  if (strlen(name) > FW_CFG_MAX_FILE_PATH - 1) {
> @@ -2052,6 +2056,11 @@ static int parse_fw_cfg(void *opaque, QemuOpts *opts, 
> Error **errp)
>  if (nonempty_str(str)) {
>  size = strlen(str); /* NUL terminator NOT included in fw_cfg blob */
>  buf = g_memdup(str, size);
> +} else if (nonempty_str(gen_id)) {
> +size_t fw_cfg_size;
> +
> +fw_cfg_size = fw_cfg_add_from_generator(fw_cfg, name, gen_id, errp);
> +return (fw_cfg_size > 0) ? 0 : -1;
>  } else {
>  GError *err = NULL;
>  if (!g_file_get_contents(file, &buf, &size, &err)) {
> 

Reviewed-by: Laszlo Ersek

Re: [PATCH v8 1/5] hw/nvram/fw_cfg: Add the FW_CFG_DATA_GENERATOR interface

On 06/09/20 19:07, Philippe Mathieu-Daudé wrote:
> The FW_CFG_DATA_GENERATOR allows any object to produce
> blob of data consumable by the fw_cfg device.
> 
> Reviewed-by: Laszlo Ersek 
> Signed-off-by: Philippe Mathieu-Daudé 
> ---
> v8: addressed Laszlo's comments
> - fixed copy/paste typos
> - corrected fmt arguments order
> - do not call fw_cfg_add_file() if get_length() returned 0
> ---
>  docs/specs/fw_cfg.txt |  9 ++-
>  include/hw/nvram/fw_cfg.h | 52 +++
>  hw/nvram/fw_cfg.c | 36 +++
>  3 files changed, 96 insertions(+), 1 deletion(-)

looks good, thanks!

Re: [PATCH] replay: notify the main loop when there are no instructions

2020-06-14 Thread Pavel Dovgalyuk




On 01.06.2020 17:01, Paolo Bonzini wrote:

On 01/06/20 12:35, Pavel Dovgalyuk wrote:

ping

On 22.05.2020 09:47, Pavel Dovgalyuk wrote:

When QEMU is executed in console mode without any external event sources,
main loop may sleep for a very long time. But in case of replay
there is another event source - event log.
This patch adds main loop notification when the vCPU loop has nothing
to do and main loop should process the inputs from the event log.

Signed-off-by: Pavel Dovgalyuk 

It's a long weekend here today but I should get a QEMU pull request
submitted on Wednesday.


Thanks, but this patch and "replay: synchronize on every virtual timer 
callback" were not included.


Replay tests are succeeded only with these patches.




Paolo


   0 files changed

diff --git a/cpus.c b/cpus.c
index 7ce0d569b3..b4d0d9f21b 100644
--- a/cpus.c
+++ b/cpus.c
@@ -1362,6 +1362,13 @@ static int64_t tcg_get_icount_limit(void)
   }
   }
   +static void notify_aio_contexts(void)
+{
+    /* Wake up other AioContexts.  */
+    qemu_clock_notify(QEMU_CLOCK_VIRTUAL);
+    qemu_clock_run_timers(QEMU_CLOCK_VIRTUAL);
+}
+
   static void handle_icount_deadline(void)
   {
   assert(qemu_in_vcpu_thread());
@@ -1370,9 +1377,7 @@ static void handle_icount_deadline(void)

QEMU_TIMER_ATTR_ALL);

     if (deadline == 0) {
-    /* Wake up other AioContexts.  */
-    qemu_clock_notify(QEMU_CLOCK_VIRTUAL);
-    qemu_clock_run_timers(QEMU_CLOCK_VIRTUAL);
+    notify_aio_contexts();
   }
   }
   }
@@ -1395,6 +1400,10 @@ static void prepare_icount_for_run(CPUState *cpu)
   cpu->icount_extra = cpu->icount_budget - insns_left;
     replay_mutex_lock();
+
+    if (cpu->icount_budget == 0 && replay_has_checkpoint()) {
+    notify_aio_contexts();
+    }
   }
   }

Re: [PATCH for-5.1 V4 3/4] hw/mips: Add Loongson-3 machine support (with KVM)

Hi, Aleksandar,

On Mon, Jun 15, 2020 at 12:50 PM Aleksandar Markovic
 wrote:
>
> пон, 15. јун 2020. у 02:55 Huacai Chen  је написао/ла:
> >
> > Hi, Aleksandar,
> >
> > On Sun, Jun 14, 2020 at 3:51 PM Aleksandar Markovic
> >  wrote:
> > >
> > > Hi, Huacai, this is another round of comments, that should be addressed 
> > > in v5.
> > >
> > > уто, 2. јун 2020. у 04:40 Huacai Chen  је 
> > > написао/ла:
> > > >
> > > > Add Loongson-3 based machine support, it use i8259 as the interrupt
> > > > controler and use GPEX as the pci controller. Currently it can only
> > > > work with KVM, but we will add TCG support in future.
> > > >
> > >
> > > Add this paragraph at this place in the commit message:
> > >
> > > "As the machine model is not based on any exiting physical hardware,
> > > the name of the machine is "loongson3-virt". It may be superseded in
> > > future by a real machine model. If this happens, a regular deprecation
> > > procedure shall occur for "loongson3-virt" machine."
> > >
> > OK, this will be added, and I will rename to "loongson3-virt-1.0",
> > which can be updated in future.
> > But I think rename the name string is enough, file names and function
> > names can keep their old names.
Why ARM can use version name?
virt-2.10 QEMU 2.10 ARM Virtual Machine
virt-2.11 QEMU 2.11 ARM Virtual Machine
virt-2.12 QEMU 2.12 ARM Virtual Machine
virt-2.6 QEMU 2.6 ARM Virtual Machine
virt-2.7 QEMU 2.7 ARM Virtual Machine
virt-2.8 QEMU 2.8 ARM Virtual Machine
virt-2.9 QEMU 2.9 ARM Virtual Machine
virt-3.0 QEMU 3.0 ARM Virtual Machine
virt-3.1 QEMU 3.1 ARM Virtual Machine
virt-4.0 QEMU 4.0 ARM Virtual Machine
virt-4.1 QEMU 4.1 ARM Virtual Machine
virt-4.2 QEMU 4.2 ARM Virtual Machine
virt QEMU 5.0 ARM Virtual Machine (alias of virt-5.0)

In future will will replace i8259 with an advanced PIC, that will be
loongson3-virt-2.0.

> >
>
> Loongson3 is instruction set name, not a machine name, and treating
> such name as machine name is incorrect. Renaming as I outlined in my
> comments must occur.
In future, both real machine and virtual machine models will be
implement in the same file, so I think loongson3.c is better than
loongson3-virt.c

>
> Yours,
> Aleksandar
>
> > Huacai
> > > > We already have a full functional Linux kernel (based on Linux-5.4.x LTS
> > > > but not upstream yet) here:
> > > >
> > > > https://github.com/chenhuacai/linux
> > > >
> > > > How to use QEMU/Loongson-3?
> > > > 1, Download kernel source from the above URL;
> > > > 2, Build a kernel with arch/mips/configs/loongson3_{def,hpc}config;
> > > > 3, Boot the a Loongson-3A4000 host with this kernel;
> > > > 4, Build QEMU-5.0.0 with this patchset;
> > > > 5, modprobe kvm;
> > > > 6, Use QEMU with TCG (available in future):
> > > >qemu-system-mips64el -M loongson3,accel=tcg -cpu Loongson-3A1000 
> > > > -kernel  -append ...
> > >
> > > Machine should be named loongson3-virt.
> > >
> > > >Use QEMU with KVM (available at present):
> > > >qemu-system-mips64el -M loongson3,accel=kvm -cpu Loongson-3A4000 
> > > > -kernel  -append ...
> > > >
> > >
> > > Machine should be named loongson3-virt.
> > >
> > > >The "-cpu" parameter can be omitted here and QEMU will use the 
> > > > correct type for TCG/KVM automatically.
> > > >
> > >
> > > This is not a good approach, the cpu parameter should be required,
> > > and, if it is not correct for particular circumstance, an error
> > > message should be emitted to the user, and the emulation terminated.
> > >
> > > > Signed-off-by: Huacai Chen 
> > > > Co-developed-by: Jiaxun Yang 
> > > > ---
> > > >  default-configs/mips64el-softmmu.mak |   1 +
> > > >  hw/mips/Kconfig  |  10 +
> > > >  hw/mips/Makefile.objs|   1 +
> > > >  hw/mips/loongson3.c  | 901 
> > > > +++
> > >
> > > The name of the file should be loongson3-virt.c
> > >
> > > >  4 files changed, 913 insertions(+)
> > > >  create mode 100644 hw/mips/loongson3.c
> > > >
> > > > diff --git a/default-configs/mips64el-softmmu.mak 
> > > > b/default-configs/mips64el-softmmu.mak
> > > > index 9f8a3ef..2a2a3fb 100644
> > > > --- a/default-configs/mips64el-softmmu.mak
> > > > +++ b/default-configs/mips64el-softmmu.mak
> > > > @@ -3,6 +3,7 @@
> > > >  include mips-softmmu-common.mak
> > > >  CONFIG_IDE_VIA=y
> > > >  CONFIG_FULOONG=y
> > > > +CONFIG_LOONGSON3=y
> > >
> > > CONFIG_LOONGSON3-VIRT
> > >
> > > >  CONFIG_ATI_VGA=y
> > > >  CONFIG_RTL8139_PCI=y
> > > >  CONFIG_JAZZ=y
> > > > diff --git a/hw/mips/Kconfig b/hw/mips/Kconfig
> > > > index 67d39c5..42931fd 100644
> > > > --- a/hw/mips/Kconfig
> > > > +++ b/hw/mips/Kconfig
> > > > @@ -45,6 +45,16 @@ config FULOONG
> > > >  bool
> > > >  select PCI_BONITO
> > > >
> > > > +config LOONGSON3
> > >
> > > LOONGSON3-VIRT
> > >
> > > > +bool
> > > > +select PCKBD
> > > > +select SERIAL
> > > > +select ISA_BUS
> > > > +select PCI_EXPRESS_GENERIC_BRIDGE
> > > > +select VIRTI

Re: [PATCH v3 09/24] macio: Fix to realize "mos6522-cuda" and "mos6522-pmu" devices

Peter, forgot to cc: you.  May I have your blessings for this version?

Markus Armbruster  writes:

> cuda_init() creates a "mos6522-cuda" device, but it's never realized.
> Affects machines mac99 with via=cuda (default) and g3beige.
>
> pmu_init() creates a "mos6522-pmu" device, but it's never realized.
> Affects machine mac99 with via=pmu and via=pmu-adb,
>
> In theory, a device becomes real only on realize.  In practice, the
> transition from unreal to real is a fuzzy one.  The work to make a
> device real can be spread between realize methods (fine),
> instance_init methods (wrong), and board code wiring up the device
> (fine as long as it effectively happens on realize).  Depending on
> what exactly is done where, a device can work even when we neglect
> to realize it.
>
> These two appear to work.  Nevertheless, it's a clear misuse of the
> interface.  Even when it works today (more or less by chance), it can
> break tomorrow.
>
> Fix by realizing them in cuda_realize() and pmu_realize(),
> respectively.
>
> Fixes: 6dca62af95e0b7020aa00d0ca9b2c421f341
> Cc: Laurent Vivier 
> Signed-off-by: Markus Armbruster 
> ---
>  hw/misc/macio/cuda.c | 15 ++-
>  hw/misc/macio/pmu.c  | 15 ++-
>  2 files changed, 20 insertions(+), 10 deletions(-)
>
> diff --git a/hw/misc/macio/cuda.c b/hw/misc/macio/cuda.c
> index e0cc0aac5d..3cb10c743c 100644
> --- a/hw/misc/macio/cuda.c
> +++ b/hw/misc/macio/cuda.c
> @@ -33,6 +33,7 @@
>  #include "hw/misc/macio/cuda.h"
>  #include "qemu/timer.h"
>  #include "sysemu/runstate.h"
> +#include "qapi/error.h"
>  #include "qemu/cutils.h"
>  #include "qemu/log.h"
>  #include "qemu/module.h"
> @@ -522,16 +523,20 @@ static void cuda_reset(DeviceState *dev)
>  static void cuda_realize(DeviceState *dev, Error **errp)
>  {
>  CUDAState *s = CUDA(dev);
> +Error *err = NULL;
>  SysBusDevice *sbd;
> -MOS6522State *ms;
> -DeviceState *d;
>  struct tm tm;
>  
> +object_property_set_bool(OBJECT(&s->mos6522_cuda), true, "realized",
> + &err);
> +if (err) {
> +error_propagate(errp, err);
> +return;
> +}
> +
>  /* Pass IRQ from 6522 */
> -d = DEVICE(&s->mos6522_cuda);
> -ms = MOS6522(d);
>  sbd = SYS_BUS_DEVICE(s);
> -sysbus_pass_irq(sbd, SYS_BUS_DEVICE(ms));
> +sysbus_pass_irq(sbd, SYS_BUS_DEVICE(&s->mos6522_cuda));
>  
>  qemu_get_timedate(&tm, 0);
>  s->tick_offset = (uint32_t)mktimegm(&tm) + RTC_OFFSET;
> diff --git a/hw/misc/macio/pmu.c b/hw/misc/macio/pmu.c
> index 9a9cd427e1..0895b78b59 100644
> --- a/hw/misc/macio/pmu.c
> +++ b/hw/misc/macio/pmu.c
> @@ -40,6 +40,7 @@
>  #include "hw/misc/macio/pmu.h"
>  #include "qemu/timer.h"
>  #include "sysemu/runstate.h"
> +#include "qapi/error.h"
>  #include "qemu/cutils.h"
>  #include "qemu/log.h"
>  #include "qemu/module.h"
> @@ -739,16 +740,20 @@ static void pmu_reset(DeviceState *dev)
>  static void pmu_realize(DeviceState *dev, Error **errp)
>  {
>  PMUState *s = VIA_PMU(dev);
> +Error *err = NULL;
>  SysBusDevice *sbd;
> -MOS6522State *ms;
> -DeviceState *d;
>  struct tm tm;
>  
> +object_property_set_bool(OBJECT(&s->mos6522_pmu), true, "realized",
> + &err);
> +if (err) {
> +error_propagate(errp, err);
> +return;
> +}
> +
>  /* Pass IRQ from 6522 */
> -d = DEVICE(&s->mos6522_pmu);
> -ms = MOS6522(d);
>  sbd = SYS_BUS_DEVICE(s);
> -sysbus_pass_irq(sbd, SYS_BUS_DEVICE(ms));
> +sysbus_pass_irq(sbd, SYS_BUS_DEVICE(&s->mos6522_pmu));
>  
>  qemu_get_timedate(&tm, 0);
>  s->tick_offset = (uint32_t)mktimegm(&tm) + RTC_OFFSET;

Re: [PATCH v10 1/9] error: auto propagated local_err

Greg Kurz  writes:

> On Tue, 17 Mar 2020 18:16:17 +0300
> Vladimir Sementsov-Ogievskiy  wrote:
>
>> Introduce a new ERRP_AUTO_PROPAGATE macro, to be used at start of
>> functions with an errp OUT parameter.
>> 
>> It has three goals:
>> 
>> 1. Fix issue with error_fatal and error_prepend/error_append_hint: user
>> can't see this additional information, because exit() happens in
>> error_setg earlier than information is added. [Reported by Greg Kurz]
>> 
>
> I have more of these coming and I'd really like to use ERRP_AUTO_PROPAGATE.
>
> It seems we have a consensus on the macro itself but this series is gated
> by the conversion of the existing code base.
>
> What about merging this patch separately so that people can start using
> it at least ?

Please give me a few more days to finish the work I feel should go in
before the conversion.  With any luck, Vladimir can then rebase /
recreate the conversion easily, and you can finally use the macro for
your own work.

Re: [PATCH v2] Makefile: Remove generated files when doing 'distclean' (and 'clean')

2020-06-14 Thread Thomas Huth

On 13/06/2020 18.28, Aleksandar Markovic wrote:
> On Tue, Oct 8, 2019 at 2:41 PM Peter Maydell  wrote:
>>
>> On Tue, 8 Oct 2019 at 13:37, Thomas Huth  wrote:
>>>
>>> On 08/10/2019 14.18, Aleksandar Markovic wrote:
 If I remember well, QAPI-related c files are generated while doing
 'make'. If that is true, these files should be deleted by 'make clean',
 shouldn't they?
>>>
>>> I think that's a philosophical question. Should "make clean" delete all
>>> files that have been generated by a Makefile (i.e. not by "configure"),
>>> or rather mainly the binary files?
>>
>> https://www.gnu.org/software/automake/manual/html_node/Clean.html
>>
>> The autoconf manual suggests some heuristics:
>>  - If make built it, and it is commonly something that one would want
>>to rebuild (for instance, a .o file), then mostlyclean should delete it.
>>  - Otherwise, if make built it, then clean should delete it.
>>  - If configure built it, then distclean should delete it.
>>  - If the maintainer built it (for instance, a .info file), then
>>maintainer-clean should delete it. However maintainer-clean should
>>not delete anything that needs to exist in order to run
>> './configure && make'.
>>
> 
> Thomas, can we reincarnate this patch? It needs only fairly simple
> corrections, as said by Peter above. It would be nice to have at least
> one release of QEMU with clean clean and distclean.

That depends ... Marc-André, Paolo, what's the status of the meson patch
series? Do you think it will be merged for the next release already? If
so, it does not make much sense to respin my distclean patch. Otherwise
I could do another iteration...

 Thomas

Re: [PATCH] .travis.yml: Use travis_retry() in case of network issues

2020-06-14 Thread Thomas Huth

On 14/06/2020 11.48, Mark Cave-Ayland wrote:
> On 13/06/2020 14:06, Philippe Mathieu-Daudé wrote:
> 
>> Use travis_retry() when cloning SLOF (see 31c8cc4f94e) in the
>> s390x container job, to avoid build failures:
>>
>>   $ ( cd ${SRC_DIR} ; git submodule update --init roms/SLOF )
>>   Submodule 'roms/SLOF' (https://git.qemu.org/git/SLOF.git) registered for 
>> path 'roms/SLOF'
>>   Cloning into '/home/travis/build/user/qemu/roms/SLOF'...
>>   fatal: unable to access 'https://git.qemu.org/git/SLOF.git/': Could not 
>> resolve host: git.qemu.org
>>   fatal: clone of 'https://git.qemu.org/git/SLOF.git' into submodule path 
>> '/home/travis/build/user/qemu/roms/SLOF' failed
>>   Failed to clone 'roms/SLOF'. Retry scheduled
>>   Cloning into '/home/travis/build/user/qemu/roms/SLOF'...
>>   fatal: unable to access 'https://git.qemu.org/git/SLOF.git/': Could not 
>> resolve host: git.qemu.org
>>   fatal: clone of 'https://git.qemu.org/git/SLOF.git' into submodule path 
>> '/home/travis/build/user/qemu/roms/SLOF' failed
>>   Failed to clone 'roms/SLOF' a second time, aborting
>>   The command "( cd ${SRC_DIR} ; git submodule update --init roms/SLOF )" 
>> exited with 1.
>>
>> Reported-by: Mark Cave-Ayland 
>> Signed-off-by: Philippe Mathieu-Daudé 
>> ---
>>  .travis.yml | 2 +-
>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/.travis.yml b/.travis.yml
>> index ec6367af1f..19a1b55aab 100644
>> --- a/.travis.yml
>> +++ b/.travis.yml
>> @@ -496,7 +496,7 @@ jobs:
>>  - CONFIG="--disable-containers 
>> --target-list=${MAIN_SOFTMMU_TARGETS},s390x-linux-user"
>>  - UNRELIABLE=true
>>script:
>> -- ( cd ${SRC_DIR} ; git submodule update --init roms/SLOF )
>> +- ( cd ${SRC_DIR} ; travis_retry git submodule update --init 
>> roms/SLOF )
>>  - BUILD_RC=0 && make -j${JOBS} || BUILD_RC=$?
>>  - |
>>if [ "$BUILD_RC" -eq 0 ] ; then
> 
> Hi Phil,
> 
> Thanks for diagnosing and proposing a fix. Is there a reason why SLOF in 
> particular
> is failing compared to other repositories that might also need a similar 
> change?

That's what I wonder, too. If git.qemu.org could not be resolved for
SLOF.git, why should it be resolvable for the other submodules that are
checked out automatically during the build process?

 Thomas

Re: [PATCH for-5.1 V4 3/4] hw/mips: Add Loongson-3 machine support (with KVM)

пон, 15. јун 2020. у 02:55 Huacai Chen  је написао/ла:
>
> Hi, Aleksandar,
>
> On Sun, Jun 14, 2020 at 3:51 PM Aleksandar Markovic
>  wrote:
> >
> > Hi, Huacai, this is another round of comments, that should be addressed in 
> > v5.
> >
> > уто, 2. јун 2020. у 04:40 Huacai Chen  је написао/ла:
> > >
> > > Add Loongson-3 based machine support, it use i8259 as the interrupt
> > > controler and use GPEX as the pci controller. Currently it can only
> > > work with KVM, but we will add TCG support in future.
> > >
> >
> > Add this paragraph at this place in the commit message:
> >
> > "As the machine model is not based on any exiting physical hardware,
> > the name of the machine is "loongson3-virt". It may be superseded in
> > future by a real machine model. If this happens, a regular deprecation
> > procedure shall occur for "loongson3-virt" machine."
> >
> OK, this will be added, and I will rename to "loongson3-virt-1.0",
> which can be updated in future.
> But I think rename the name string is enough, file names and function
> names can keep their old names.
>

Loongson3 is instruction set name, not a machine name, and treating
such name as machine name is incorrect. Renaming as I outlined in my
comments must occur.

Yours,
Aleksandar

> Huacai
> > > We already have a full functional Linux kernel (based on Linux-5.4.x LTS
> > > but not upstream yet) here:
> > >
> > > https://github.com/chenhuacai/linux
> > >
> > > How to use QEMU/Loongson-3?
> > > 1, Download kernel source from the above URL;
> > > 2, Build a kernel with arch/mips/configs/loongson3_{def,hpc}config;
> > > 3, Boot the a Loongson-3A4000 host with this kernel;
> > > 4, Build QEMU-5.0.0 with this patchset;
> > > 5, modprobe kvm;
> > > 6, Use QEMU with TCG (available in future):
> > >qemu-system-mips64el -M loongson3,accel=tcg -cpu Loongson-3A1000 
> > > -kernel  -append ...
> >
> > Machine should be named loongson3-virt.
> >
> > >Use QEMU with KVM (available at present):
> > >qemu-system-mips64el -M loongson3,accel=kvm -cpu Loongson-3A4000 
> > > -kernel  -append ...
> > >
> >
> > Machine should be named loongson3-virt.
> >
> > >The "-cpu" parameter can be omitted here and QEMU will use the correct 
> > > type for TCG/KVM automatically.
> > >
> >
> > This is not a good approach, the cpu parameter should be required,
> > and, if it is not correct for particular circumstance, an error
> > message should be emitted to the user, and the emulation terminated.
> >
> > > Signed-off-by: Huacai Chen 
> > > Co-developed-by: Jiaxun Yang 
> > > ---
> > >  default-configs/mips64el-softmmu.mak |   1 +
> > >  hw/mips/Kconfig  |  10 +
> > >  hw/mips/Makefile.objs|   1 +
> > >  hw/mips/loongson3.c  | 901 
> > > +++
> >
> > The name of the file should be loongson3-virt.c
> >
> > >  4 files changed, 913 insertions(+)
> > >  create mode 100644 hw/mips/loongson3.c
> > >
> > > diff --git a/default-configs/mips64el-softmmu.mak 
> > > b/default-configs/mips64el-softmmu.mak
> > > index 9f8a3ef..2a2a3fb 100644
> > > --- a/default-configs/mips64el-softmmu.mak
> > > +++ b/default-configs/mips64el-softmmu.mak
> > > @@ -3,6 +3,7 @@
> > >  include mips-softmmu-common.mak
> > >  CONFIG_IDE_VIA=y
> > >  CONFIG_FULOONG=y
> > > +CONFIG_LOONGSON3=y
> >
> > CONFIG_LOONGSON3-VIRT
> >
> > >  CONFIG_ATI_VGA=y
> > >  CONFIG_RTL8139_PCI=y
> > >  CONFIG_JAZZ=y
> > > diff --git a/hw/mips/Kconfig b/hw/mips/Kconfig
> > > index 67d39c5..42931fd 100644
> > > --- a/hw/mips/Kconfig
> > > +++ b/hw/mips/Kconfig
> > > @@ -45,6 +45,16 @@ config FULOONG
> > >  bool
> > >  select PCI_BONITO
> > >
> > > +config LOONGSON3
> >
> > LOONGSON3-VIRT
> >
> > > +bool
> > > +select PCKBD
> > > +select SERIAL
> > > +select ISA_BUS
> > > +select PCI_EXPRESS_GENERIC_BRIDGE
> > > +select VIRTIO_VGA
> > > +select QXL if SPICE
> > > +select MSI_NONBROKEN
> > > +
> > >  config MIPS_CPS
> > >  bool
> > >  select PTIMER
> > > diff --git a/hw/mips/Makefile.objs b/hw/mips/Makefile.objs
> > > index 3b3e6ea..31dedcb 100644
> > > --- a/hw/mips/Makefile.objs
> > > +++ b/hw/mips/Makefile.objs
> > > @@ -4,5 +4,6 @@ obj-$(CONFIG_MALTA) += gt64xxx_pci.o malta.o
> > >  obj-$(CONFIG_MIPSSIM) += mipssim.o
> > >  obj-$(CONFIG_JAZZ) += jazz.o
> > >  obj-$(CONFIG_FULOONG) += fuloong2e.o
> > > +obj-$(CONFIG_LOONGSON3) += loongson3.o
> >
> > CONFIG_LOONGSON3-VIRT
> >
> > >  obj-$(CONFIG_MIPS_CPS) += cps.o
> > >  obj-$(CONFIG_MIPS_BOSTON) += boston.o
> > > diff --git a/hw/mips/loongson3.c b/hw/mips/loongson3.c
> > > new file mode 100644
> > > index 000..e4b9538
> > > --- /dev/null
> > > +++ b/hw/mips/loongson3.c
> >
> > The file shoul be named loongson3-virt.c
> >
> > > @@ -0,0 +1,901 @@
> > > +/*
> > > + * Generic Loongson-3 Platform support
> >
> > "Support for loongson3-virt platform"
> >
> > > + *
> > > + * Copyright (c) 2016-2020 Huacai Chen (che...@lemote.com)
> > > + * This

Re: [PATCH for-5.1 V4 3/4] hw/mips: Add Loongson-3 machine support (with KVM)

пон, 15. јун 2020. у 02:55 Huacai Chen  је написао/ла:
>
> Hi, Aleksandar,
>
> On Sun, Jun 14, 2020 at 3:51 PM Aleksandar Markovic
>  wrote:
> >
> > Hi, Huacai, this is another round of comments, that should be addressed in 
> > v5.
> >
> > уто, 2. јун 2020. у 04:40 Huacai Chen  је написао/ла:
> > >
> > > Add Loongson-3 based machine support, it use i8259 as the interrupt
> > > controler and use GPEX as the pci controller. Currently it can only
> > > work with KVM, but we will add TCG support in future.
> > >
> >
> > Add this paragraph at this place in the commit message:
> >
> > "As the machine model is not based on any exiting physical hardware,
> > the name of the machine is "loongson3-virt". It may be superseded in
> > future by a real machine model. If this happens, a regular deprecation
> > procedure shall occur for "loongson3-virt" machine."
> >
> OK, this will be added, and I will rename to "loongson3-virt-1.0",
> which can be updated in future.
> But I think rename the name string is enough, file names and function
> names can keep their old names.
>

Sorry, Huacai, this is ruled out. We definitely do not want to pile
versions 1.0, 2.0, 3.0 etc. of such virtual machine. One can update
the machine without creating a new version if backward compatibility
for end user is satisfied. But, the better outcome would be if you
provide real machine model instead, rather than spend time and energy
on multi-version virtual machine.

Yours,
Aleksandar

> Huacai
> > > We already have a full functional Linux kernel (based on Linux-5.4.x LTS
> > > but not upstream yet) here:
> > >
> > > https://github.com/chenhuacai/linux
> > >
> > > How to use QEMU/Loongson-3?
> > > 1, Download kernel source from the above URL;
> > > 2, Build a kernel with arch/mips/configs/loongson3_{def,hpc}config;
> > > 3, Boot the a Loongson-3A4000 host with this kernel;
> > > 4, Build QEMU-5.0.0 with this patchset;
> > > 5, modprobe kvm;
> > > 6, Use QEMU with TCG (available in future):
> > >qemu-system-mips64el -M loongson3,accel=tcg -cpu Loongson-3A1000 
> > > -kernel  -append ...
> >
> > Machine should be named loongson3-virt.
> >
> > >Use QEMU with KVM (available at present):
> > >qemu-system-mips64el -M loongson3,accel=kvm -cpu Loongson-3A4000 
> > > -kernel  -append ...
> > >
> >
> > Machine should be named loongson3-virt.
> >
> > >The "-cpu" parameter can be omitted here and QEMU will use the correct 
> > > type for TCG/KVM automatically.
> > >
> >
> > This is not a good approach, the cpu parameter should be required,
> > and, if it is not correct for particular circumstance, an error
> > message should be emitted to the user, and the emulation terminated.
> >
> > > Signed-off-by: Huacai Chen 
> > > Co-developed-by: Jiaxun Yang 
> > > ---
> > >  default-configs/mips64el-softmmu.mak |   1 +
> > >  hw/mips/Kconfig  |  10 +
> > >  hw/mips/Makefile.objs|   1 +
> > >  hw/mips/loongson3.c  | 901 
> > > +++
> >
> > The name of the file should be loongson3-virt.c
> >
> > >  4 files changed, 913 insertions(+)
> > >  create mode 100644 hw/mips/loongson3.c
> > >
> > > diff --git a/default-configs/mips64el-softmmu.mak 
> > > b/default-configs/mips64el-softmmu.mak
> > > index 9f8a3ef..2a2a3fb 100644
> > > --- a/default-configs/mips64el-softmmu.mak
> > > +++ b/default-configs/mips64el-softmmu.mak
> > > @@ -3,6 +3,7 @@
> > >  include mips-softmmu-common.mak
> > >  CONFIG_IDE_VIA=y
> > >  CONFIG_FULOONG=y
> > > +CONFIG_LOONGSON3=y
> >
> > CONFIG_LOONGSON3-VIRT
> >
> > >  CONFIG_ATI_VGA=y
> > >  CONFIG_RTL8139_PCI=y
> > >  CONFIG_JAZZ=y
> > > diff --git a/hw/mips/Kconfig b/hw/mips/Kconfig
> > > index 67d39c5..42931fd 100644
> > > --- a/hw/mips/Kconfig
> > > +++ b/hw/mips/Kconfig
> > > @@ -45,6 +45,16 @@ config FULOONG
> > >  bool
> > >  select PCI_BONITO
> > >
> > > +config LOONGSON3
> >
> > LOONGSON3-VIRT
> >
> > > +bool
> > > +select PCKBD
> > > +select SERIAL
> > > +select ISA_BUS
> > > +select PCI_EXPRESS_GENERIC_BRIDGE
> > > +select VIRTIO_VGA
> > > +select QXL if SPICE
> > > +select MSI_NONBROKEN
> > > +
> > >  config MIPS_CPS
> > >  bool
> > >  select PTIMER
> > > diff --git a/hw/mips/Makefile.objs b/hw/mips/Makefile.objs
> > > index 3b3e6ea..31dedcb 100644
> > > --- a/hw/mips/Makefile.objs
> > > +++ b/hw/mips/Makefile.objs
> > > @@ -4,5 +4,6 @@ obj-$(CONFIG_MALTA) += gt64xxx_pci.o malta.o
> > >  obj-$(CONFIG_MIPSSIM) += mipssim.o
> > >  obj-$(CONFIG_JAZZ) += jazz.o
> > >  obj-$(CONFIG_FULOONG) += fuloong2e.o
> > > +obj-$(CONFIG_LOONGSON3) += loongson3.o
> >
> > CONFIG_LOONGSON3-VIRT
> >
> > >  obj-$(CONFIG_MIPS_CPS) += cps.o
> > >  obj-$(CONFIG_MIPS_BOSTON) += boston.o
> > > diff --git a/hw/mips/loongson3.c b/hw/mips/loongson3.c
> > > new file mode 100644
> > > index 000..e4b9538
> > > --- /dev/null
> > > +++ b/hw/mips/loongson3.c
> >
> > The file shoul be named loongson3-virt.c
> >
>

RE: [PATCH 1/2] migration/colo: fix typo in the COLO Framework module

2020-06-14 Thread Zhang, Chen

It looks normal to me.

Thanks
Zhang Chen

> -Original Message-
> From: Qemu-devel  bounces+chen.zhang=intel@nongnu.org> On Behalf Of Zhanghailiang
> Sent: Monday, June 15, 2020 11:06 AM
> To: Like Xu ; qemu-devel@nongnu.org
> Subject: RE: [PATCH 1/2] migration/colo: fix typo in the COLO Framework
> module
> 
> 
> I have checked this patch in mail archive, it has no problem, It seems that my
> email setup has some problem. It didn't show the right newline In this patch.
> 
> 
> > -Original Message-
> > From: Like Xu [mailto:like...@linux.intel.com]
> > Sent: Monday, June 15, 2020 10:24 AM
> > To: Zhanghailiang ;
> > qemu-devel@nongnu.org
> > Subject: Re: [PATCH 1/2] migration/colo: fix typo in the COLO
> > Framework module
> >
> > On 2020/6/15 9:36, Zhanghailiang wrote:
> > > Hi Like,
> > >
> > > Please check this patch, It seems that you didn't use git
> > > format-patch command to generate this patch, It is in wrong format.
> >
> > I rebase the patch on the top commit of
> > 7d3660e79830a069f1848bb4fa1cdf8f666424fb,
> > and hope it helps you.
> >
> > >
> > > Thanks,
> > > Hailiang
> >
> >  From 15c19be9be07598d4264a4a84b85d4efa79bff9d Mon Sep 17
> > 00:00:00 2001
> > From: Like Xu 
> > Date: Mon, 15 Jun 2020 10:10:57 +0800
> > Subject: [PATCH 1/2] migration/colo: fix typo in the COLO Framework
> > module
> >
> > Cc: Hailiang Zhang 
> > Signed-off-by: Like Xu 
> > ---
> >   docs/COLO-FT.txt | 8 
> >   migration/colo.c | 2 +-
> >   2 files changed, 5 insertions(+), 5 deletions(-)
> >
> > diff --git a/docs/COLO-FT.txt b/docs/COLO-FT.txt index
> > c8e1740935..fdc0207cff 100644
> > --- a/docs/COLO-FT.txt
> > +++ b/docs/COLO-FT.txt
> > @@ -10,7 +10,7 @@ See the COPYING file in the top-level directory.
> >   This document gives an overview of COLO's design and how to use it.
> >
> >   == Background ==
> > -Virtual machine (VM) replication is a well known technique for
> > providing
> > +Virtual machine (VM) replication is a well-known technique for
> > +providing
> >   application-agnostic software-implemented hardware fault tolerance,
> >   also known as "non-stop service".
> >
> > @@ -103,7 +103,7 @@ Primary side.
> >
> >   COLO Proxy:
> >   Delivers packets to Primary and Secondary, and then compare the
> > responses from -both side. Then decide whether to start a checkpoint
> > according to some rules.
> > +both sides. Then decide whether to start a checkpoint according to
> > +some
> > rules.
> >   Please refer to docs/colo-proxy.txt for more information.
> >
> >   Note:
> > @@ -146,12 +146,12 @@ in test procedure.
> >
> >   == Test procedure ==
> >   Note: Here we are running both instances on the same host for
> > testing, -change the IP Addresses if you want to run it on two hosts.
> > Initally
> > +change the IP Addresses if you want to run it on two hosts. Initially
> >   127.0.0.1 is the Primary Host and 127.0.0.2 is the Secondary Host.
> >
> >   == Startup qemu ==
> >   1. Primary:
> > -Note: Initally, $imagefolder/primary.qcow2 needs to be copied to all hosts.
> > +Note: Initially, $imagefolder/primary.qcow2 needs to be copied to all
> hosts.
> >   You don't need to change any IP's here, because 0.0.0.0 listens on any
> >   interface. The chardev's with 127.0.0.1 IP's loopback to the local qemu
> >   instance.
> > diff --git a/migration/colo.c b/migration/colo.c index
> > ea7d1e9d4e..80788d46b5 100644
> > --- a/migration/colo.c
> > +++ b/migration/colo.c
> > @@ -632,7 +632,7 @@ out:
> >   /*
> >* It is safe to unregister notifier after failover finished.
> >* Besides, colo_delay_timer and colo_checkpoint_sem can't be
> > - * released befor unregister notifier, or there will be use-after-free
> > + * released before unregister notifier, or there will be
> > + use-after-free
> >* error.
> >*/
> >   colo_compare_unregister_notifier(&packets_compare_notifier);
> > --
> > 2.21.3
> >

Re: [PATCH] migration: Count new_dirty instead of real_dirty

2020-06-14 Thread zhukeqian

Hi Paolo and Jian Zhou,

Do you have any suggestion on this patch?

Thanks,
Keqian

On 2020/6/1 12:02, Keqian Zhu wrote:
> DIRTY_LOG_INITIALLY_ALL_SET feature is on the queue. This fixs the
> dirty rate calculation for this feature. After introducing this
> feature, real_dirty_pages is equal to total memory size at begining.
> This causing wrong dirty rate and false positive throttling.
> 
> BTW, real dirty rate is not suitable and not very accurate.
> 
> 1. For not suitable: We mainly concern on the relationship between
>dirty rate and network bandwidth. Net increasement of dirty pages
>makes more sense.
> 2. For not very accurate: With manual dirty log clear, some dirty pages
>will be cleared during each peroid, our "real dirty rate" is less
>than real "real dirty rate".
> 
> Signed-off-by: Keqian Zhu 
> ---
>  include/exec/ram_addr.h | 5 ++---
>  1 file changed, 2 insertions(+), 3 deletions(-)
> 
> diff --git a/include/exec/ram_addr.h b/include/exec/ram_addr.h
> index 5e59a3d8d7..af9677e291 100644
> --- a/include/exec/ram_addr.h
> +++ b/include/exec/ram_addr.h
> @@ -443,7 +443,7 @@ static inline
>  uint64_t cpu_physical_memory_sync_dirty_bitmap(RAMBlock *rb,
> ram_addr_t start,
> ram_addr_t length,
> -   uint64_t *real_dirty_pages)
> +   uint64_t *accu_dirty_pages)
>  {
>  ram_addr_t addr;
>  unsigned long word = BIT_WORD((start + rb->offset) >> TARGET_PAGE_BITS);
> @@ -469,7 +469,6 @@ uint64_t cpu_physical_memory_sync_dirty_bitmap(RAMBlock 
> *rb,
>  if (src[idx][offset]) {
>  unsigned long bits = atomic_xchg(&src[idx][offset], 0);
>  unsigned long new_dirty;
> -*real_dirty_pages += ctpopl(bits);
>  new_dirty = ~dest[k];
>  dest[k] |= bits;
>  new_dirty &= bits;
> @@ -502,7 +501,6 @@ uint64_t cpu_physical_memory_sync_dirty_bitmap(RAMBlock 
> *rb,
>  start + addr + offset,
>  TARGET_PAGE_SIZE,
>  DIRTY_MEMORY_MIGRATION)) {
> -*real_dirty_pages += 1;
>  long k = (start + addr) >> TARGET_PAGE_BITS;
>  if (!test_and_set_bit(k, dest)) {
>  num_dirty++;
> @@ -511,6 +509,7 @@ uint64_t cpu_physical_memory_sync_dirty_bitmap(RAMBlock 
> *rb,
>  }
>  }
>  
> +*accu_dirty_pages += num_dirty;
>  return num_dirty;
>  }
>  #endif
>

RE: [PATCH 1/2] migration/colo: fix typo in the COLO Framework module

2020-06-14 Thread Zhanghailiang


I have checked this patch in mail archive, it has no problem,
It seems that my email setup has some problem. It didn't show the right newline
In this patch.


> -Original Message-
> From: Like Xu [mailto:like...@linux.intel.com]
> Sent: Monday, June 15, 2020 10:24 AM
> To: Zhanghailiang ;
> qemu-devel@nongnu.org
> Subject: Re: [PATCH 1/2] migration/colo: fix typo in the COLO Framework
> module
> 
> On 2020/6/15 9:36, Zhanghailiang wrote:
> > Hi Like,
> >
> > Please check this patch, It seems that you didn't use git format-patch
> > command to generate this patch, It is in wrong format.
> 
> I rebase the patch on the top commit of
> 7d3660e79830a069f1848bb4fa1cdf8f666424fb,
> and hope it helps you.
> 
> >
> > Thanks,
> > Hailiang
> 
>  From 15c19be9be07598d4264a4a84b85d4efa79bff9d Mon Sep 17
> 00:00:00 2001
> From: Like Xu 
> Date: Mon, 15 Jun 2020 10:10:57 +0800
> Subject: [PATCH 1/2] migration/colo: fix typo in the COLO Framework
> module
> 
> Cc: Hailiang Zhang 
> Signed-off-by: Like Xu 
> ---
>   docs/COLO-FT.txt | 8 
>   migration/colo.c | 2 +-
>   2 files changed, 5 insertions(+), 5 deletions(-)
> 
> diff --git a/docs/COLO-FT.txt b/docs/COLO-FT.txt index
> c8e1740935..fdc0207cff 100644
> --- a/docs/COLO-FT.txt
> +++ b/docs/COLO-FT.txt
> @@ -10,7 +10,7 @@ See the COPYING file in the top-level directory.
>   This document gives an overview of COLO's design and how to use it.
> 
>   == Background ==
> -Virtual machine (VM) replication is a well known technique for providing
> +Virtual machine (VM) replication is a well-known technique for
> +providing
>   application-agnostic software-implemented hardware fault tolerance,
>   also known as "non-stop service".
> 
> @@ -103,7 +103,7 @@ Primary side.
> 
>   COLO Proxy:
>   Delivers packets to Primary and Secondary, and then compare the
> responses from -both side. Then decide whether to start a checkpoint
> according to some rules.
> +both sides. Then decide whether to start a checkpoint according to some
> rules.
>   Please refer to docs/colo-proxy.txt for more information.
> 
>   Note:
> @@ -146,12 +146,12 @@ in test procedure.
> 
>   == Test procedure ==
>   Note: Here we are running both instances on the same host for testing,
> -change the IP Addresses if you want to run it on two hosts. Initally
> +change the IP Addresses if you want to run it on two hosts. Initially
>   127.0.0.1 is the Primary Host and 127.0.0.2 is the Secondary Host.
> 
>   == Startup qemu ==
>   1. Primary:
> -Note: Initally, $imagefolder/primary.qcow2 needs to be copied to all hosts.
> +Note: Initially, $imagefolder/primary.qcow2 needs to be copied to all hosts.
>   You don't need to change any IP's here, because 0.0.0.0 listens on any
>   interface. The chardev's with 127.0.0.1 IP's loopback to the local qemu
>   instance.
> diff --git a/migration/colo.c b/migration/colo.c index
> ea7d1e9d4e..80788d46b5 100644
> --- a/migration/colo.c
> +++ b/migration/colo.c
> @@ -632,7 +632,7 @@ out:
>   /*
>* It is safe to unregister notifier after failover finished.
>* Besides, colo_delay_timer and colo_checkpoint_sem can't be
> - * released befor unregister notifier, or there will be use-after-free
> + * released before unregister notifier, or there will be
> + use-after-free
>* error.
>*/
>   colo_compare_unregister_notifier(&packets_compare_notifier);
> --
> 2.21.3
>

Re: [PATCH v4 5/6] i386: Hyper-V VMBus ACPI DSDT entry

2020-06-14 Thread Jon Doron

On 14/06/2020, Maciej S. Szmigiero wrote:

Hi Jon,

On 14.06.2020 16:11, Jon Doron wrote:

On 28/05/2020, Jon Doron wrote:

On 28/05/2020, Igor Mammedov wrote:

On Thu, 28 May 2020 08:26:42 +0300
Jon Doron wrote:

On 22/05/2020, Igor Mammedow wrote:

On Thu, 21 May 2020 18:02:07 +0200
Paolo Bonzini wrote:

On 13/05/20 17:34, Igor Mammedov wrote:
> I'd rather avoid using random IRQ numbers (considering we are
> dealing with black-box here). So if it's really necessary to have
> IRQ described here, I'd suggest to implement them in device model
> so they would be reserved and QEMU would error out in a sane way if
> IRQ conflict is detected.

We don't generally detect ISA IRQ conflicts though, do we?

that I don't know that's why I'm not suggesting how to do it.
The point is hard-coding in AML random IRQs is not right thing to do,
(especially with the lack of 'any' spec), as minimum AML should pull
it from device model and that probably should be configurable and set
by board.

Other thing is:
I haven't looked at VMBus device model in detail, but DSDT part aren't
matching device though (device model is not ISA device hence AML part
shouldn't be on in ISA scope), where to put it is open question.
There were other issues with AML code, I've commented on, so I was
waiting on respin with comments addressed.
I don't think that this patch is good enough for merging.

But it seems like the current patch does match what's Microsoft HyperV
is publishing in it's APCI tables.

I dont think it's correct for us to "fix" Microsoft emulation even if
it's wrong, since that's what Windows probably expects to see...

I tried looking where Microsoft uses the ACPI tables to identify the
VMBus but without much luck in order to understand how flexible a change
would be for the OS to still detect the VMBus device, but in general
I think "correcting" something that is emulated 1:1 because there is no
spec is the right way.

I'd agree, if removing nonsense would break VMBus detection (does it?).
if something is that doesn't make sense but has to stay because it is need
to make windows happy, that's fine , just add annotate is with comment,
so it won't confuse anyone why that code exists there later on.

I suggest to:
1. try dropping _PS* & _STA as it doesn't actually does anything and _PS3 is
plain wrong
2. drop one IRQ, newer hyper-v seems to be doing fine with only one
3. it's not ISA device, I'd suggest to move into _SB scope
4. I don't know much about IRQs but
git grep DEFINE_PROP_ | grep -i iqr
yields nothing so I'm not sure if it's acceptable. Typically it's board that
assigns
IRQ and not device, for Sysbus devices (see:
sysbus_init_irq/sysbus_connect_irq).
So I'd leave it upto Paolo or someone else to decide/comment on.

Sounds like a plan, I'll try to come up with the test results
(at least for Windows 10 guest which is what I have setup) and update
this thread with the results.

-- Jon.

Paolo

Hi guys,

Sorry for the delay...

So first ill clarify what was the test, the test was to see the device
"Microsoft Hyper-V Virtual Machine Bus" in Windows Device Manager under
"System devices" with a state of "working properly".

It seems like it's ok to drop all the _PS* and _STA.

It seems to be functioning with single IRQ as well, it is worth noting that
even when i dropped the entire _CRS (so no IRQs resources are required, the
device was still showing that it's functioning, but I suspect this might affect
the child devices like hv-net and hv-scsi).

I guess you tested a single Windows version, correct?
It may be that requirements differ between Windows versions, just as you
say below about the required enlightenments.

Yes I have tested only a single version, but from the looks of it there
is only a single IRQ in the HyperV APCI table that I have looked at, and
I believe the one you have pasted as well in the past, so that change
sounds reasonable to me.

As for the enlightenments dont you prefer to have all those as mandatory
for VMBus in order not to run into the issue I have encountered?

With that said I did run into a small issue I set-up Win10 1903 (aka 19H1) and
it seems like VMBus now requires to have the following features enabled:
HV_VP_RUNTIME_AVAILABLE
HV_TIME_REF_COUNT_AVAILABLE
HV_SYNIC_AVAILABLE
HV_SYNTIMERS_AVAILABLE
HV_APIC_ACCESS_AVAILABLE
HV_HYPERCALL_AVAILABLE
HV_VP_INDEX_AVAILABLE

So notice that previously only SYNIC and VPINDEX was needed, now you need the
whole thing so you need to run qemu with something like
-cpu
host,hv-relaxed,hv_spinlocks=0x1fff,hv_time,hv-vapic,hv-vpindex,hv-synic,hv-runtime,hv-stimer

The validation was done in winhv!WinHvpCheckPartitionPrivileges .

Paolo I noticed you have done a PULL request, would you like to wait on it and
we will submit a version with a single IRQ (selectable by user property) and go
with Igor's suggestion dropping _PS* and _STA (though like I said before I
prefer to mimic the original HyperV with it's b

Re: [PATCH 1/2] migration/colo: fix typo in the COLO Framework module

2020-06-14 Thread Like Xu


On 2020/6/15 9:36, Zhanghailiang wrote:

Hi Like,

Please check this patch, It seems that you didn't use git format-patch command 
to generate this patch,
It is in wrong format.


I rebase the patch on the top commit of
7d3660e79830a069f1848bb4fa1cdf8f666424fb,
and hope it helps you.



Thanks,
Hailiang


From 15c19be9be07598d4264a4a84b85d4efa79bff9d Mon Sep 17 00:00:00 2001
From: Like Xu 
Date: Mon, 15 Jun 2020 10:10:57 +0800
Subject: [PATCH 1/2] migration/colo: fix typo in the COLO Framework module

Cc: Hailiang Zhang 
Signed-off-by: Like Xu 
---
 docs/COLO-FT.txt | 8 
 migration/colo.c | 2 +-
 2 files changed, 5 insertions(+), 5 deletions(-)

diff --git a/docs/COLO-FT.txt b/docs/COLO-FT.txt
index c8e1740935..fdc0207cff 100644
--- a/docs/COLO-FT.txt
+++ b/docs/COLO-FT.txt
@@ -10,7 +10,7 @@ See the COPYING file in the top-level directory.
 This document gives an overview of COLO's design and how to use it.

 == Background ==
-Virtual machine (VM) replication is a well known technique for providing
+Virtual machine (VM) replication is a well-known technique for providing
 application-agnostic software-implemented hardware fault tolerance,
 also known as "non-stop service".

@@ -103,7 +103,7 @@ Primary side.

 COLO Proxy:
 Delivers packets to Primary and Secondary, and then compare the responses 
from

-both side. Then decide whether to start a checkpoint according to some rules.
+both sides. Then decide whether to start a checkpoint according to some rules.
 Please refer to docs/colo-proxy.txt for more information.

 Note:
@@ -146,12 +146,12 @@ in test procedure.

 == Test procedure ==
 Note: Here we are running both instances on the same host for testing,
-change the IP Addresses if you want to run it on two hosts. Initally
+change the IP Addresses if you want to run it on two hosts. Initially
 127.0.0.1 is the Primary Host and 127.0.0.2 is the Secondary Host.

 == Startup qemu ==
 1. Primary:
-Note: Initally, $imagefolder/primary.qcow2 needs to be copied to all hosts.
+Note: Initially, $imagefolder/primary.qcow2 needs to be copied to all hosts.
 You don't need to change any IP's here, because 0.0.0.0 listens on any
 interface. The chardev's with 127.0.0.1 IP's loopback to the local qemu
 instance.
diff --git a/migration/colo.c b/migration/colo.c
index ea7d1e9d4e..80788d46b5 100644
--- a/migration/colo.c
+++ b/migration/colo.c
@@ -632,7 +632,7 @@ out:
 /*
  * It is safe to unregister notifier after failover finished.
  * Besides, colo_delay_timer and colo_checkpoint_sem can't be
- * released befor unregister notifier, or there will be use-after-free
+ * released before unregister notifier, or there will be use-after-free
  * error.
  */
 colo_compare_unregister_notifier(&packets_compare_notifier);
--
2.21.3

RE: [PATCH 1/2] migration/colo: fix typo in the COLO Framework module

2020-06-14 Thread Zhanghailiang

Hi Like,

Please check this patch, It seems that you didn't use git format-patch command 
to generate this patch,
It is in wrong format.

Thanks,
Hailiang

> -Original Message-
> From: Like Xu [mailto:like...@linux.intel.com]
> Sent: Sunday, June 14, 2020 4:45 PM
> To: qemu-devel@nongnu.org
> Cc: Like Xu ; Zhanghailiang
> 
> Subject: [PATCH 1/2] migration/colo: fix typo in the COLO Framework
> module
> 
> Cc: Hailiang Zhang 
> Signed-off-by: Like Xu 
> ---
>  docs/COLO-FT.txt | 8 
>  migration/colo.c | 2 +-
>  2 files changed, 5 insertions(+), 5 deletions(-)
> 
> diff --git a/docs/COLO-FT.txt b/docs/COLO-FT.txt index
> c8e1740935..fdc0207cff 100644
> --- a/docs/COLO-FT.txt
> +++ b/docs/COLO-FT.txt
> @@ -10,7 +10,7 @@ See the COPYING file in the top-level directory.
>  This document gives an overview of COLO's design and how to use it.
> 
>  == Background ==
> -Virtual machine (VM) replication is a well known technique for providing
> +Virtual machine (VM) replication is a well-known technique for
> +providing
>  application-agnostic software-implemented hardware fault tolerance,  also
> known as "non-stop service".
> 
> @@ -103,7 +103,7 @@ Primary side.
> 
>  COLO Proxy:
>  Delivers packets to Primary and Secondary, and then compare the responses
> from -both side. Then decide whether to start a checkpoint according to
> some rules.
> +both sides. Then decide whether to start a checkpoint according to some
> rules.
>  Please refer to docs/colo-proxy.txt for more information.
> 
>  Note:
> @@ -146,12 +146,12 @@ in test procedure.
> 
>  == Test procedure ==
>  Note: Here we are running both instances on the same host for testing,
> -change the IP Addresses if you want to run it on two hosts. Initally
> +change the IP Addresses if you want to run it on two hosts. Initially
>  127.0.0.1 is the Primary Host and 127.0.0.2 is the Secondary Host.
> 
>  == Startup qemu ==
>  1. Primary:
> -Note: Initally, $imagefolder/primary.qcow2 needs to be copied to all hosts.
> +Note: Initially, $imagefolder/primary.qcow2 needs to be copied to all hosts.
>  You don't need to change any IP's here, because 0.0.0.0 listens on any
> interface. The chardev's with 127.0.0.1 IP's loopback to the local qemu
> instance.
> diff --git a/migration/colo.c b/migration/colo.c index
> ea7d1e9d4e..80788d46b5 100644
> --- a/migration/colo.c
> +++ b/migration/colo.c
> @@ -632,7 +632,7 @@ out:
>  /*
>   * It is safe to unregister notifier after failover finished.
>   * Besides, colo_delay_timer and colo_checkpoint_sem can't be
> - * released befor unregister notifier, or there will be use-after-free
> + * released before unregister notifier, or there will be
> + use-after-free
>   * error.
>   */
>  colo_compare_unregister_notifier(&packets_compare_notifier);
> --
> 2.21.3

Re: [PATCH for-5.1 V4 3/4] hw/mips: Add Loongson-3 machine support (with KVM)

Hi, Aleksandar,

On Sun, Jun 14, 2020 at 3:51 PM Aleksandar Markovic
 wrote:
>
> Hi, Huacai, this is another round of comments, that should be addressed in v5.
>
> уто, 2. јун 2020. у 04:40 Huacai Chen  је написао/ла:
> >
> > Add Loongson-3 based machine support, it use i8259 as the interrupt
> > controler and use GPEX as the pci controller. Currently it can only
> > work with KVM, but we will add TCG support in future.
> >
>
> Add this paragraph at this place in the commit message:
>
> "As the machine model is not based on any exiting physical hardware,
> the name of the machine is "loongson3-virt". It may be superseded in
> future by a real machine model. If this happens, a regular deprecation
> procedure shall occur for "loongson3-virt" machine."
>
OK, this will be added, and I will rename to "loongson3-virt-1.0",
which can be updated in future.
But I think rename the name string is enough, file names and function
names can keep their old names.

Huacai
> > We already have a full functional Linux kernel (based on Linux-5.4.x LTS
> > but not upstream yet) here:
> >
> > https://github.com/chenhuacai/linux
> >
> > How to use QEMU/Loongson-3?
> > 1, Download kernel source from the above URL;
> > 2, Build a kernel with arch/mips/configs/loongson3_{def,hpc}config;
> > 3, Boot the a Loongson-3A4000 host with this kernel;
> > 4, Build QEMU-5.0.0 with this patchset;
> > 5, modprobe kvm;
> > 6, Use QEMU with TCG (available in future):
> >qemu-system-mips64el -M loongson3,accel=tcg -cpu Loongson-3A1000 
> > -kernel  -append ...
>
> Machine should be named loongson3-virt.
>
> >Use QEMU with KVM (available at present):
> >qemu-system-mips64el -M loongson3,accel=kvm -cpu Loongson-3A4000 
> > -kernel  -append ...
> >
>
> Machine should be named loongson3-virt.
>
> >The "-cpu" parameter can be omitted here and QEMU will use the correct 
> > type for TCG/KVM automatically.
> >
>
> This is not a good approach, the cpu parameter should be required,
> and, if it is not correct for particular circumstance, an error
> message should be emitted to the user, and the emulation terminated.
>
> > Signed-off-by: Huacai Chen 
> > Co-developed-by: Jiaxun Yang 
> > ---
> >  default-configs/mips64el-softmmu.mak |   1 +
> >  hw/mips/Kconfig  |  10 +
> >  hw/mips/Makefile.objs|   1 +
> >  hw/mips/loongson3.c  | 901 
> > +++
>
> The name of the file should be loongson3-virt.c
>
> >  4 files changed, 913 insertions(+)
> >  create mode 100644 hw/mips/loongson3.c
> >
> > diff --git a/default-configs/mips64el-softmmu.mak 
> > b/default-configs/mips64el-softmmu.mak
> > index 9f8a3ef..2a2a3fb 100644
> > --- a/default-configs/mips64el-softmmu.mak
> > +++ b/default-configs/mips64el-softmmu.mak
> > @@ -3,6 +3,7 @@
> >  include mips-softmmu-common.mak
> >  CONFIG_IDE_VIA=y
> >  CONFIG_FULOONG=y
> > +CONFIG_LOONGSON3=y
>
> CONFIG_LOONGSON3-VIRT
>
> >  CONFIG_ATI_VGA=y
> >  CONFIG_RTL8139_PCI=y
> >  CONFIG_JAZZ=y
> > diff --git a/hw/mips/Kconfig b/hw/mips/Kconfig
> > index 67d39c5..42931fd 100644
> > --- a/hw/mips/Kconfig
> > +++ b/hw/mips/Kconfig
> > @@ -45,6 +45,16 @@ config FULOONG
> >  bool
> >  select PCI_BONITO
> >
> > +config LOONGSON3
>
> LOONGSON3-VIRT
>
> > +bool
> > +select PCKBD
> > +select SERIAL
> > +select ISA_BUS
> > +select PCI_EXPRESS_GENERIC_BRIDGE
> > +select VIRTIO_VGA
> > +select QXL if SPICE
> > +select MSI_NONBROKEN
> > +
> >  config MIPS_CPS
> >  bool
> >  select PTIMER
> > diff --git a/hw/mips/Makefile.objs b/hw/mips/Makefile.objs
> > index 3b3e6ea..31dedcb 100644
> > --- a/hw/mips/Makefile.objs
> > +++ b/hw/mips/Makefile.objs
> > @@ -4,5 +4,6 @@ obj-$(CONFIG_MALTA) += gt64xxx_pci.o malta.o
> >  obj-$(CONFIG_MIPSSIM) += mipssim.o
> >  obj-$(CONFIG_JAZZ) += jazz.o
> >  obj-$(CONFIG_FULOONG) += fuloong2e.o
> > +obj-$(CONFIG_LOONGSON3) += loongson3.o
>
> CONFIG_LOONGSON3-VIRT
>
> >  obj-$(CONFIG_MIPS_CPS) += cps.o
> >  obj-$(CONFIG_MIPS_BOSTON) += boston.o
> > diff --git a/hw/mips/loongson3.c b/hw/mips/loongson3.c
> > new file mode 100644
> > index 000..e4b9538
> > --- /dev/null
> > +++ b/hw/mips/loongson3.c
>
> The file shoul be named loongson3-virt.c
>
> > @@ -0,0 +1,901 @@
> > +/*
> > + * Generic Loongson-3 Platform support
>
> "Support for loongson3-virt platform"
>
> > + *
> > + * Copyright (c) 2016-2020 Huacai Chen (che...@lemote.com)
> > + * This code is licensed under the GNU GPL v2.
> > + *
> > + * Contributions are licensed under the terms of the GNU GPL,
> > + * version 2 or (at your option) any later version.
>
> License preamble should be harmonized, as we already agreed upon.
>
> > + */
> > +
> > +/*
> > + * Generic PC Platform based on Loongson-3 CPU (MIPS64R2 with extensions,
> > + * 800~2000MHz)
> > + */
> > +
> > +#include "qemu/osdep.h"
> > +#include "qemu-common.h"
> > +#include "qemu/units.h"
> > +#include "qapi/error.h"
> > +#include "cpu.h"
> > +#

Re: [PATCH for-5.1 V4 1/4] hw/mips: Implement the kvm_type() hook in MachineClass

Hi, Aleksandar,

On Sun, Jun 14, 2020 at 4:07 PM Aleksandar Markovic
 wrote:
>
>
>
> уто, 2. јун 2020. у 04:38 Huacai Chen  је написао/ла:
> >
> > MIPS has two types of KVM: TE & VZ, and TE is the default type. Now we
> > can't create a VZ guest in QEMU because it lacks the kvm_type() hook in
> > MachineClass. Besides, libvirt uses a null-machine to detect the kvm
> > capability, so by default it will return "KVM not supported" on a VZ
> > platform. Thus, null-machine also need the kvm_type() hook.
> >
> > Reviewed-by: Aleksandar Markovic 
> > Signed-off-by: Huacai Chen 
> > Co-developed-by: Jiaxun Yang 
> > ---
>
> Huacai,
>
> Please take a look at Peter's remarks at:
>
> https://lists.gnu.org/archive/html/qemu-devel/2020-06/msg01878.html
>
> ...and refactor this patch for v5. My general advice: The simpler, the batter.
>
OK, I will rework this patch.

Huacai
> Best wishes,
> Aleksandar
>
> >  hw/core/Makefile.objs  |  2 +-
> >  hw/core/null-machine.c |  4 
> >  hw/mips/Makefile.objs  |  2 +-
> >  hw/mips/common.c   | 42 ++
> >  include/hw/mips/mips.h |  3 +++
> >  5 files changed, 51 insertions(+), 2 deletions(-)
> >  create mode 100644 hw/mips/common.c
> >
> > diff --git a/hw/core/Makefile.objs b/hw/core/Makefile.objs
> > index 1d540ed..b5672f4 100644
> > --- a/hw/core/Makefile.objs
> > +++ b/hw/core/Makefile.objs
> > @@ -17,11 +17,11 @@ common-obj-$(CONFIG_SOFTMMU) += 
> > vm-change-state-handler.o
> >  common-obj-$(CONFIG_SOFTMMU) += qdev-properties-system.o
> >  common-obj-$(CONFIG_SOFTMMU) += sysbus.o
> >  common-obj-$(CONFIG_SOFTMMU) += machine.o
> > -common-obj-$(CONFIG_SOFTMMU) += null-machine.o
> >  common-obj-$(CONFIG_SOFTMMU) += loader.o
> >  common-obj-$(CONFIG_SOFTMMU) += machine-hmp-cmds.o
> >  common-obj-$(CONFIG_SOFTMMU) += numa.o
> >  common-obj-$(CONFIG_SOFTMMU) += clock-vmstate.o
> > +obj-$(CONFIG_SOFTMMU) += null-machine.o
> >  obj-$(CONFIG_SOFTMMU) += machine-qmp-cmds.o
> >
> >  common-obj-$(CONFIG_EMPTY_SLOT) += empty_slot.o
> > diff --git a/hw/core/null-machine.c b/hw/core/null-machine.c
> > index cb47d9d..94a36f9 100644
> > --- a/hw/core/null-machine.c
> > +++ b/hw/core/null-machine.c
> > @@ -17,6 +17,7 @@
> >  #include "sysemu/sysemu.h"
> >  #include "exec/address-spaces.h"
> >  #include "hw/core/cpu.h"
> > +#include "hw/mips/mips.h"
> >
> >  static void machine_none_init(MachineState *mch)
> >  {
> > @@ -50,6 +51,9 @@ static void machine_none_machine_init(MachineClass *mc)
> >  mc->max_cpus = 1;
> >  mc->default_ram_size = 0;
> >  mc->default_ram_id = "ram";
> > +#ifdef TARGET_MIPS
> > +mc->kvm_type = mips_kvm_type;
> > +#endif
> >  }
> >
> >  DEFINE_MACHINE("none", machine_none_machine_init)
> > diff --git a/hw/mips/Makefile.objs b/hw/mips/Makefile.objs
> > index 739e2b7..3b3e6ea 100644
> > --- a/hw/mips/Makefile.objs
> > +++ b/hw/mips/Makefile.objs
> > @@ -1,4 +1,4 @@
> > -obj-y += addr.o mips_int.o
> > +obj-y += addr.o common.o mips_int.o
> >  obj-$(CONFIG_R4K) += r4k.o
> >  obj-$(CONFIG_MALTA) += gt64xxx_pci.o malta.o
> >  obj-$(CONFIG_MIPSSIM) += mipssim.o
> > diff --git a/hw/mips/common.c b/hw/mips/common.c
> > new file mode 100644
> > index 000..4d8e141
> > --- /dev/null
> > +++ b/hw/mips/common.c
> > @@ -0,0 +1,42 @@
> > +/*
> > + * Common MIPS routines
> > + *
> > + * Copyright (c) 2020 Huacai Chen (che...@lemote.com)
> > + * This code is licensed under the GNU GPL v2.
> > + */
> > +
> > +#include 
> > +#include "qemu/osdep.h"
> > +#include "qemu-common.h"
> > +#include "hw/boards.h"
> > +#include "hw/mips/mips.h"
> > +#include "sysemu/kvm_int.h"
> > +
> > +#ifndef CONFIG_KVM
> > +
> > +int mips_kvm_type(MachineState *machine, const char *vm_type)
> > +{
> > +return 0;
> > +}
> > +
> > +#else
> > +
> > +int mips_kvm_type(MachineState *machine, const char *vm_type)
> > +{
> > +int r;
> > +KVMState *s = KVM_STATE(machine->accelerator);
> > +
> > +r = kvm_check_extension(s, KVM_CAP_MIPS_VZ);
> > +if (r > 0) {
> > +return KVM_VM_MIPS_VZ;
> > +}
> > +
> > +r = kvm_check_extension(s, KVM_CAP_MIPS_TE);
> > +if (r > 0) {
> > +return KVM_VM_MIPS_TE;
> > +}
> > +
> > +return -1;
> > +}
> > +
> > +#endif
> > diff --git a/include/hw/mips/mips.h b/include/hw/mips/mips.h
> > index 0af4c3d..2ac0580 100644
> > --- a/include/hw/mips/mips.h
> > +++ b/include/hw/mips/mips.h
> > @@ -20,4 +20,7 @@ void rc4030_dma_write(void *dma, uint8_t *buf, int len);
> >
> >  DeviceState *rc4030_init(rc4030_dma **dmas, IOMMUMemoryRegion **dma_mr);
> >
> > +/* common.c */
> > +int mips_kvm_type(MachineState *machine, const char *vm_type);
> > +
> >  #endif
> > --
> > 2.7.0
> >

[PATCH] hw/xen_pt: Don't grant opregion permissions

2020-06-14 Thread Grzegorz Uriasz

With the upstreaming of linux based stubdomains to xen, qemu can't
assume it runs inside dom0 - permission assignment must be moved to
libxl running in dom0. This xen patch:
https://lists.xenproject.org/archives/html/xen-devel/2020-06/msg00973.html
implements granting the required permissions to the stubdomain running
qemu. This patch removes granting opregion permissions in qemu - this
should be fine as when qemu is running inside dom0 the memory mapping will
be successfully created without first explicitly granting the permission.

Signed-off-by: Grzegorz Uriasz 
---
 hw/xen/xen_pt_graphics.c | 13 -
 1 file changed, 13 deletions(-)

diff --git a/hw/xen/xen_pt_graphics.c b/hw/xen/xen_pt_graphics.c
index 7d46e9c209..303674365b 100644
--- a/hw/xen/xen_pt_graphics.c
+++ b/hw/xen/xen_pt_graphics.c
@@ -283,19 +283,6 @@ void igd_write_opregion(XenPCIPassthroughState *s, 
uint32_t val)
 igd_guest_opregion = (unsigned long)(val & ~XEN_PCI_INTEL_OPREGION_MASK)
 | (igd_host_opregion & 
XEN_PCI_INTEL_OPREGION_MASK);
 
-ret = xc_domain_iomem_permission(xen_xc, xen_domid,
-(unsigned long)(igd_host_opregion >> XC_PAGE_SHIFT),
-XEN_PCI_INTEL_OPREGION_PAGES,
-XEN_PCI_INTEL_OPREGION_ENABLE_ACCESSED);
-
-if (ret) {
-XEN_PT_ERR(&s->dev, "[%d]:Can't enable to access IGD host opregion:"
-" 0x%lx.\n", ret,
-(unsigned long)(igd_host_opregion >> XC_PAGE_SHIFT)),
-igd_guest_opregion = 0;
-return;
-}
-
 ret = xc_domain_memory_mapping(xen_xc, xen_domid,
 (unsigned long)(igd_guest_opregion >> XC_PAGE_SHIFT),
 (unsigned long)(igd_host_opregion >> XC_PAGE_SHIFT),
-- 
2.27.0

Re: [PATCH] target/mips: Fix PageMask with variable page size

недеља, 14. јун 2020., Jiaxun Yang  је написао/ла:

> Our current code assumed the target page size is always 4k
> when handling PageMask and VPN2, however, variable page size
> was just added to mips target and that's nolonger true.
>
> So we refined this piece of code to handle any target page size.
> Also added Big Page support defined by MIPS64 Release2.
>
> Signed-off-by: Jiaxun Yang 
> ---
>  target/mips/cp0_helper.c | 48 ++--


Hi, Jiaxun.

Thanks for this contribution too.

When you change machine.c the way you did it, you need to bump the version.
Please see git log on machine.c for details.

Also, this patch covers logicaly related, but slightly different and, in
some cases almost independanr things, and should be split to two or more
logical units - in other words, patches.

Thanks,
Akeksandar


>  target/mips/cpu.h|  3 ++-
>  target/mips/machine.c|  2 +-
>  3 files changed, 39 insertions(+), 14 deletions(-)
>
> diff --git a/target/mips/cp0_helper.c b/target/mips/cp0_helper.c
> index bbf12e4a97..7a134085f7 100644
> --- a/target/mips/cp0_helper.c
> +++ b/target/mips/cp0_helper.c
> @@ -872,20 +872,44 @@ void helper_mtc0_memorymapid(CPUMIPSState *env,
> target_ulong arg1)
>  }
>  }
>
> -void update_pagemask(CPUMIPSState *env, target_ulong arg1, int32_t
> *pagemask)
> +void helper_mtc0_pagemask(CPUMIPSState *env, target_ulong arg1)
>  {
> -uint64_t mask = arg1 >> (TARGET_PAGE_BITS + 1);
> -if (!(env->insn_flags & ISA_MIPS32R6) || (arg1 == ~0) ||
> -(mask == 0x || mask == 0x0003 || mask == 0x000F ||
> - mask == 0x003F || mask == 0x00FF || mask == 0x03FF ||
> - mask == 0x0FFF || mask == 0x3FFF || mask == 0x)) {
> -env->CP0_PageMask = arg1 & (0x1FFF & (TARGET_PAGE_MASK << 1));
> +uint64_t mask;
> +int maxmaskbits, maskbits;
> +
> +if (env->insn_flags & ISA_MIPS32R6) {
> +return;
>  }
> -}
>
> -void helper_mtc0_pagemask(CPUMIPSState *env, target_ulong arg1)
> -{
> -update_pagemask(env, arg1, &env->CP0_PageMask);
> +/* Don't care MASKX as we don't support 1KB page */
> +#ifdef TARGET_MIPS64
> +if (env->CP0_Config3 & CP0C3_BPG) {
> +maxmaskbits = 47;
> +} else {
> +maxmaskbits = 16;
> +}
> +#else
> +maxmaskbits = 16;
> +#endif
> +mask = extract64((uint64_t)arg1, CP0PM_MASK, maxmaskbits);
> +
> +maskbits = find_first_zero_bit(&mask, 64);
> +
> +/* Ensure no more set bit after first zero */
> +if (mask >> maskbits) {
> +goto invalid;
> +}
> +/* We don't support VTLB entry smaller than target page */
> +if ((maskbits + 12) < TARGET_PAGE_BITS) {
> +goto invalid;
> +}
> +env->CP0_PageMask = mask << CP0PM_MASK;
> +
> +return;
> +
> +invalid:
> +maskbits = MIN(maxmaskbits, MAX(maskbits, TARGET_PAGE_BITS - 12));
> +env->CP0_PageMask = ((1 << (maskbits + 1)) - 1) << CP0PM_MASK;
>  }
>
>  void helper_mtc0_pagegrain(CPUMIPSState *env, target_ulong arg1)
> @@ -,7 +1135,7 @@ void helper_mthc0_saar(CPUMIPSState *env,
> target_ulong arg1)
>  void helper_mtc0_entryhi(CPUMIPSState *env, target_ulong arg1)
>  {
>  target_ulong old, val, mask;
> -mask = (TARGET_PAGE_MASK << 1) | env->CP0_EntryHi_ASID_mask;
> +mask = ~((1 << 14) - 1) | env->CP0_EntryHi_ASID_mask;
>  if (((env->CP0_Config4 >> CP0C4_IE) & 0x3) >= 2) {
>  mask |= 1 << CP0EnHi_EHINV;
>  }
> diff --git a/target/mips/cpu.h b/target/mips/cpu.h
> index 0b3c987bb3..b69806792d 100644
> --- a/target/mips/cpu.h
> +++ b/target/mips/cpu.h
> @@ -617,7 +617,8 @@ struct CPUMIPSState {
>  /*
>   * CP0 Register 5
>   */
> -int32_t CP0_PageMask;
> +target_ulong CP0_PageMask;
> +#define CP0PM_MASK 13
>  int32_t CP0_PageGrain_rw_bitmask;
>  int32_t CP0_PageGrain;
>  #define CP0PG_RIE 31
> diff --git a/target/mips/machine.c b/target/mips/machine.c
> index 5b23e3e912..b30a75d46b 100644
> --- a/target/mips/machine.c
> +++ b/target/mips/machine.c
> @@ -252,7 +252,7 @@ const VMStateDescription vmstate_mips_cpu = {
>  VMSTATE_UINT64(env.CP0_EntryLo1, MIPSCPU),
>  VMSTATE_UINTTL(env.CP0_Context, MIPSCPU),
>  VMSTATE_INT32(env.CP0_MemoryMapID, MIPSCPU),
> -VMSTATE_INT32(env.CP0_PageMask, MIPSCPU),
> +VMSTATE_UINTTL(env.CP0_PageMask, MIPSCPU),
>  VMSTATE_INT32(env.CP0_PageGrain, MIPSCPU),
>  VMSTATE_UINTTL(env.CP0_SegCtl0, MIPSCPU),
>  VMSTATE_UINTTL(env.CP0_SegCtl1, MIPSCPU),
> --
> 2.27.0
>

Re: [PATCH v4 5/6] i386: Hyper-V VMBus ACPI DSDT entry

2020-06-14 Thread Maciej S. Szmigiero

Hi Jon,

On 14.06.2020 16:11, Jon Doron wrote:
> On 28/05/2020, Jon Doron wrote:
>> On 28/05/2020, Igor Mammedov wrote:
>>> On Thu, 28 May 2020 08:26:42 +0300
>>> Jon Doron  wrote:
>>>
 On 22/05/2020, Igor Mammedow wrote:
> On Thu, 21 May 2020 18:02:07 +0200
> Paolo Bonzini  wrote:
>
>> On 13/05/20 17:34, Igor Mammedov wrote:
>> > I'd rather avoid using random IRQ numbers (considering we are
>> > dealing with black-box here). So if it's really necessary to have
>> > IRQ described here, I'd suggest to implement them in device model
>> > so they would be reserved and QEMU would error out in a sane way if
>> > IRQ conflict is detected.
>>
>> We don't generally detect ISA IRQ conflicts though, do we?
>
> that I don't know that's why I'm not suggesting how to do it.
> The point is hard-coding in AML random IRQs is not right thing to do,
> (especially with the lack of 'any' spec), as minimum AML should pull
> it from device model and that probably should be configurable and set
> by board.
>
> Other thing is:
> I haven't looked at VMBus device model in detail, but DSDT part aren't
> matching device though (device model is not ISA device hence AML part
> shouldn't be on in ISA scope), where to put it is open question.
> There were other issues with AML code, I've commented on, so I was
> waiting on respin with comments addressed.
> I don't think that this patch is good enough for merging.
>
>

 But it seems like the current patch does match what's Microsoft HyperV
 is publishing in it's APCI tables.

 I dont think it's correct for us to "fix" Microsoft emulation even if
 it's wrong, since that's what Windows probably expects to see...

 I tried looking where Microsoft uses the ACPI tables to identify the
 VMBus but without much luck in order to understand how flexible a change
 would be for the OS to still detect the VMBus device, but in general
 I think "correcting" something that is emulated 1:1 because there is no
 spec is the right way.
>>>
>>> I'd agree, if removing nonsense would break VMBus detection (does it?).
>>> if something is that doesn't make sense but has to stay because it is need
>>> to make windows happy, that's fine , just add annotate is with comment,
>>> so it won't confuse anyone why that code exists there later on.
>>>
>>> I suggest to:
>>> 1. try dropping _PS* & _STA as it doesn't actually does anything and _PS3 
>>> is plain wrong
>>> 2. drop one IRQ, newer hyper-v seems to be doing fine with only one
>>> 3. it's not ISA device, I'd suggest to move into _SB scope
>>> 4. I don't know much about IRQs but
>>>  git grep DEFINE_PROP_ | grep -i iqr
>>>   yields nothing so I'm not sure if it's acceptable. Typically it's board 
>>> that assigns
>>>   IRQ and not device, for Sysbus devices (see: 
>>> sysbus_init_irq/sysbus_connect_irq).
>>>   So I'd leave it upto Paolo or someone else to decide/comment on.
>>>
>>
>> Sounds like a plan, I'll try to come up with the test results
>> (at least for Windows 10 guest which is  what I have setup) and update
>> this thread with the results.
>>
>> -- Jon.
>>

>>
>> Paolo
>>
>

>>>
> Hi guys,
> 
> Sorry for the delay...
> 
> So first ill clarify what was the test, the test was to see the device
> "Microsoft Hyper-V Virtual Machine Bus" in Windows Device Manager under
> "System devices" with a state of "working properly".
> 
> It seems like it's ok to drop all the _PS* and _STA.
>
> It seems to be functioning with single IRQ as well, it is worth noting that 
> even when i dropped the entire _CRS (so no IRQs resources are required, the 
> device was still showing that it's functioning, but I suspect this might 
> affect the child devices like hv-net and hv-scsi).

I guess you tested a single Windows version, correct?
It may be that requirements differ between Windows versions, just as you
say below about the required enlightenments.
 
> With that said I did run into a small issue I set-up Win10 1903 (aka 19H1) 
> and it seems like VMBus now requires to have the following features enabled:
> HV_VP_RUNTIME_AVAILABLE
> HV_TIME_REF_COUNT_AVAILABLE
> HV_SYNIC_AVAILABLE
> HV_SYNTIMERS_AVAILABLE
> HV_APIC_ACCESS_AVAILABLE
> HV_HYPERCALL_AVAILABLE
> HV_VP_INDEX_AVAILABLE
> 
> So notice that previously only SYNIC and VPINDEX was needed, now you need the 
> whole thing so you need to run qemu with something like
> -cpu 
> host,hv-relaxed,hv_spinlocks=0x1fff,hv_time,hv-vapic,hv-vpindex,hv-synic,hv-runtime,hv-stimer
> 
> The validation was done in winhv!WinHvpCheckPartitionPrivileges .
>
> Paolo I noticed you have done a PULL request, would you like to wait on it 
> and we will submit a version with a single IRQ (selectable by user property) 
> and go with Igor's suggestion dropping _PS* and _STA (though like I said 
> before I prefer to mimic the original HyperV with it's bugs, but I'll

Re: [PATCH v9 0/5] vhost-user block device backend implementation

2020-06-14 Thread no-reply

Patchew URL: 
https://patchew.org/QEMU/20200614183907.514282-1-coiby...@gmail.com/



Hi,

This series failed the asan build test. Please find the testing commands and
their output below. If you have Docker installed, you can probably reproduce it
locally.

=== TEST SCRIPT BEGIN ===
#!/bin/bash
export ARCH=x86_64
make docker-image-fedora V=1 NETWORK=1
time make docker-test-debug@fedora TARGET_LIST=x86_64-softmmu J=14 NETWORK=1
=== TEST SCRIPT END ===

  CC  stubs/vm-stop.o
  CC  ui/input-keymap.o
  CC  qemu-keymap.o
/tmp/qemu-test/src/util/vhost-user-server.c:142:30: error: use of undeclared 
identifier 'VHOST_MEMORY_MAX_NREGIONS'
 VHOST_MEMORY_MAX_NREGIONS, nfds + nfds_t);
 ^
1 error generated.
make: *** [/tmp/qemu-test/src/rules.mak:69: util/vhost-user-server.o] Error 1
make: *** Waiting for unfinished jobs
  CC  contrib/elf2dmp/main.o
Traceback (most recent call last):
---
raise CalledProcessError(retcode, cmd)
subprocess.CalledProcessError: Command '['sudo', '-n', 'docker', 'run', 
'--label', 'com.qemu.instance.uuid=99a7788ed7f54df1b0ebb7f91beb522e', '-u', 
'1001', '--security-opt', 'seccomp=unconfined', '--rm', '-e', 
'TARGET_LIST=x86_64-softmmu', '-e', 'EXTRA_CONFIGURE_OPTS=', '-e', 'V=', '-e', 
'J=14', '-e', 'DEBUG=', '-e', 'SHOW_ENV=', '-e', 'CCACHE_DIR=/var/tmp/ccache', 
'-v', '/home/patchew/.cache/qemu-docker-ccache:/var/tmp/ccache:z', '-v', 
'/var/tmp/patchew-tester-tmp-9goaol7z/src/docker-src.2020-06-14-15.12.59.10439:/var/tmp/qemu:z,ro',
 'qemu:fedora', '/var/tmp/qemu/run', 'test-debug']' returned non-zero exit 
status 2.
filter=--filter=label=com.qemu.instance.uuid=99a7788ed7f54df1b0ebb7f91beb522e
make[1]: *** [docker-run] Error 1
make[1]: Leaving directory `/var/tmp/patchew-tester-tmp-9goaol7z/src'
make: *** [docker-run-test-debug@fedora] Error 2

real3m29.335s
user0m8.313s


The full log is available at
http://patchew.org/logs/20200614183907.514282-1-coiby...@gmail.com/testing.asan/?type=message.
---
Email generated automatically by Patchew [https://patchew.org/].
Please send your feedback to patchew-de...@redhat.com

Re: [PATCH v9 0/5] vhost-user block device backend implementation

2020-06-14 Thread no-reply

Patchew URL: 
https://patchew.org/QEMU/20200614183907.514282-1-coiby...@gmail.com/



Hi,

This series failed the docker-quick@centos7 build test. Please find the testing 
commands and
their output below. If you have Docker installed, you can probably reproduce it
locally.

=== TEST SCRIPT BEGIN ===
#!/bin/bash
make docker-image-centos7 V=1 NETWORK=1
time make docker-test-quick@centos7 SHOW_ENV=1 J=14 NETWORK=1
=== TEST SCRIPT END ===

  CC  hw/gpio/trace.o
  CC  hw/riscv/trace.o
/tmp/qemu-test/src/util/vhost-user-server.c: In function 'vu_message_read':
/tmp/qemu-test/src/util/vhost-user-server.c:142:30: error: 
'VHOST_MEMORY_MAX_NREGIONS' undeclared (first use in this function)
  VHOST_MEMORY_MAX_NREGIONS, nfds + nfds_t);
  ^
/tmp/qemu-test/src/util/vhost-user-server.c:142:30: note: each undeclared 
identifier is reported only once for each function it appears in
make: *** [util/vhost-user-server.o] Error 1
make: *** Waiting for unfinished jobs
Traceback (most recent call last):
  File "./tests/docker/docker.py", line 669, in 
---
raise CalledProcessError(retcode, cmd)
subprocess.CalledProcessError: Command '['sudo', '-n', 'docker', 'run', 
'--label', 'com.qemu.instance.uuid=408a16efe57d44399707cea73c0c46cb', '-u', 
'1001', '--security-opt', 'seccomp=unconfined', '--rm', '-e', 'TARGET_LIST=', 
'-e', 'EXTRA_CONFIGURE_OPTS=', '-e', 'V=', '-e', 'J=14', '-e', 'DEBUG=', '-e', 
'SHOW_ENV=1', '-e', 'CCACHE_DIR=/var/tmp/ccache', '-v', 
'/home/patchew/.cache/qemu-docker-ccache:/var/tmp/ccache:z', '-v', 
'/var/tmp/patchew-tester-tmp-hyuz9qap/src/docker-src.2020-06-14-15.10.05.3902:/var/tmp/qemu:z,ro',
 'qemu:centos7', '/var/tmp/qemu/run', 'test-quick']' returned non-zero exit 
status 2.
filter=--filter=label=com.qemu.instance.uuid=408a16efe57d44399707cea73c0c46cb
make[1]: *** [docker-run] Error 1
make[1]: Leaving directory `/var/tmp/patchew-tester-tmp-hyuz9qap/src'
make: *** [docker-run-test-quick@centos7] Error 2

real2m3.838s
user0m8.880s


The full log is available at
http://patchew.org/logs/20200614183907.514282-1-coiby...@gmail.com/testing.docker-quick@centos7/?type=message.
---
Email generated automatically by Patchew [https://patchew.org/].
Please send your feedback to patchew-de...@redhat.com

Re: [PATCH v8 3/4] vhost-user block device backend server


On Thu, Jun 11, 2020 at 04:24:52PM +0100, Stefan Hajnoczi wrote:

On Fri, Jun 05, 2020 at 07:35:37AM +0800, Coiby Xu wrote:

+static void coroutine_fn vu_block_virtio_process_req(void *opaque)
+{
+struct req_data *data = opaque;
+VuServer *server = data->server;
+VuVirtq *vq = data->vq;
+VuVirtqElement *elem = data->elem;
+uint32_t type;
+VuBlockReq *req;
+
+VuBlockDev *vdev_blk = get_vu_block_device_by_server(server);
+BlockBackend *backend = vdev_blk->backend;
+
+struct iovec *in_iov = elem->in_sg;
+struct iovec *out_iov = elem->out_sg;
+unsigned in_num = elem->in_num;
+unsigned out_num = elem->out_num;
+/* refer to hw/block/virtio_blk.c */
+if (elem->out_num < 1 || elem->in_num < 1) {
+error_report("virtio-blk request missing headers");
+free(elem);
+return;
+}
+
+req = g_new0(VuBlockReq, 1);


elem was allocated with enough space for VuBlockReq. Can this allocation
be eliminated?

 typedef struct VuBlockReq {
- VuVirtqElement *elem;
+ VuVirtqElement elem;
 int64_t sector_num;
 size_t size;
 struct virtio_blk_inhdr *in;
 struct virtio_blk_outhdr out;
 VuServer *server;
 struct VuVirtq *vq;
 } VuBlockReq;


Thank you for review this patch. Other issues for this patch have been
addressed in v9 except for this one. I'm not sure what you mean. I can't
find a way that doesn't require to allocate a VuBlockReq struct.


--
Best regards,
Coiby

Re: [PATCH v8 0/4] vhost-user block device backend implementation


Hi Stefano Garzarella,

On Thu, Jun 11, 2020 at 02:37:03PM +0200, Stefano Garzarella wrote:

Hi Coiby Xu,

On Fri, Jun 05, 2020 at 07:35:34AM +0800, Coiby Xu wrote:

v8
 - re-try connecting to socket server to fix asan error
 - fix license naming issue

v7
 - fix docker-test-debug@fedora errors by freeing malloced memory

v6
 - add missing license header and include guard
 - vhost-user server only serve one client one time
 - fix a bug in custom vu_message_read
 - using qemu-storage-daemon to start vhost-user-blk-server
 - a bug fix to pass docker-test-clang@ubuntu

v5:
 * re-use vu_kick_cb in libvhost-user
 * keeping processing VhostUserMsg in the same coroutine until there is
   detachment/attachment of AIOContext
 * Spawn separate coroutine for each VuVirtqElement
 * Other changes including relocating vhost-user-blk-server.c, coding
   style etc.

v4:
 * add object properties in class_init
 * relocate vhost-user-blk-test
 * other changes including using SocketAddress, coding style, etc.

v3:
 * separate generic vhost-user-server code from vhost-user-blk-server
   code
 * re-write vu_message_read and kick hander function as coroutines to
   directly call blk_co_preadv, blk_co_pwritev, etc.
 * add aio_context notifier functions to support multi-threading model
 * other fixes regarding coding style, warning report, etc.

v2:
 * Only enable this feature for Linux because eventfd is a Linux-specific
   feature


This patch series is an implementation of vhost-user block device
backend server, thanks to Stefan and Kevin's guidance.

Vhost-user block device backend server is a UserCreatable object and can be
started using object_add,

 (qemu) object_add 
vhost-user-blk-server,id=ID,unix-socket=/tmp/vhost-user-blk_vhost.socket,node-name=DRIVE_NAME,writable=off,blk-size=512
 (qemu) object_del ID

or appending the "-object" option when starting QEMU,

  $ -object 
vhost-user-blk-server,id=disk,unix-socket=/tmp/vhost-user-blk_vhost.socket,node-name=DRIVE_NAME,writable=off,blk-size=512

Then vhost-user client can connect to the server backend.
For example, QEMU could act as a client,

  $ -m 256 -object memory-backend-memfd,id=mem,size=256M,share=on -numa 
node,memdev=mem -chardev socket,id=char1,path=/tmp/vhost-user-blk_vhost.socket 
-device vhost-user-blk-pci,id=blk0,chardev=char1

And guest OS could access this vhost-user block device after mounting it.

Coiby Xu (4):
  Allow vu_message_read to be replaced
  generic vhost user server
  vhost-user block device backend server
  new qTest case to test the vhost-user-blk-server

 block/Makefile.objs|   1 +
 block/export/vhost-user-blk-server.c   | 716 
 block/export/vhost-user-blk-server.h   |  34 +
 contrib/libvhost-user/libvhost-user-glib.c |   2 +-
 contrib/libvhost-user/libvhost-user.c  |  11 +-
 contrib/libvhost-user/libvhost-user.h  |  21 +
 softmmu/vl.c   |   4 +
 tests/Makefile.include |   3 +-
 tests/qtest/Makefile.include   |   2 +
 tests/qtest/libqos/vhost-user-blk.c| 130 
 tests/qtest/libqos/vhost-user-blk.h|  44 ++
 tests/qtest/libqtest.c |  54 +-
 tests/qtest/libqtest.h |  38 ++
 tests/qtest/vhost-user-blk-test.c  | 737 +
 tests/vhost-user-bridge.c  |   2 +
 tools/virtiofsd/fuse_virtio.c  |   4 +-
 util/Makefile.objs |   1 +
 util/vhost-user-server.c   | 406 
 util/vhost-user-server.h   |  59 ++
 19 files changed, 2229 insertions(+), 40 deletions(-)
 create mode 100644 block/export/vhost-user-blk-server.c
 create mode 100644 block/export/vhost-user-blk-server.h
 create mode 100644 tests/qtest/libqos/vhost-user-blk.c
 create mode 100644 tests/qtest/libqos/vhost-user-blk.h
 create mode 100644 tests/qtest/vhost-user-blk-test.c
 create mode 100644 util/vhost-user-server.c
 create mode 100644 util/vhost-user-server.h



Should we add an entry in the MAINTAINERS file for some of the new files?
(e.g. util/vhost-user-server.*)


Yes, please. Thank you!

--
Best regards,
Coiby

Re: [PATCH v8 2/4] generic vhost user server


On Thu, Jun 11, 2020 at 02:14:49PM +0100, Stefan Hajnoczi wrote:

On Fri, Jun 05, 2020 at 07:35:36AM +0800, Coiby Xu wrote:

+static bool coroutine_fn
+vu_message_read(VuDev *vu_dev, int conn_fd, VhostUserMsg *vmsg)
+{
+struct iovec iov = {
+.iov_base = (char *)vmsg,
+.iov_len = VHOST_USER_HDR_SIZE,
+};
+int rc, read_bytes = 0;
+Error *local_err = NULL;
+/*
+ * Store fds/nfds returned from qio_channel_readv_full into
+ * temporary variables.
+ *
+ * VhostUserMsg is a packed structure, gcc will complain about passing
+ * pointer to a packed structure member if we pass &VhostUserMsg.fd_num
+ * and &VhostUserMsg.fds directly when calling qio_channel_readv_full,
+ * thus two temporary variables nfds and fds are used here.
+ */
+size_t nfds = 0, nfds_t = 0;
+int *fds = NULL, *fds_t = NULL;
+VuServer *server = container_of(vu_dev, VuServer, vu_dev);
+QIOChannel *ioc = NULL;
+
+if (conn_fd == server->sioc->fd) {
+ioc = server->ioc;
+} else {
+/* Slave communication will also use this function to read msg */
+ioc = slave_io_channel(server, conn_fd, &local_err);
+}
+
+if (!ioc) {
+error_report_err(local_err);
+goto fail;
+}
+
+assert(qemu_in_coroutine());
+do {
+/*
+ * qio_channel_readv_full may have short reads, keeping calling it
+ * until getting VHOST_USER_HDR_SIZE or 0 bytes in total
+ */
+rc = qio_channel_readv_full(ioc, &iov, 1, &fds_t, &nfds_t, &local_err);
+if (rc < 0) {
+if (rc == QIO_CHANNEL_ERR_BLOCK) {
+qio_channel_yield(ioc, G_IO_IN);
+continue;
+} else {
+error_report_err(local_err);
+return false;
+}
+}
+read_bytes += rc;
+if (nfds_t > 0) {
+fds = g_renew(int, fds, nfds + nfds_t);
+memcpy(fds + nfds, fds_t, nfds_t *sizeof(int));
+nfds += nfds_t;
+if (nfds > VHOST_MEMORY_MAX_NREGIONS) {
+error_report("A maximum of %d fds are allowed, "
+ "however got %lu fds now",
+ VHOST_MEMORY_MAX_NREGIONS, nfds);
+goto fail;
+}
+g_free(fds_t);


I'm not sure why the temporary fds[] array is necessary. Copying the fds
directly into vmsg->fds would be simpler:

 if (nfds + nfds_t > G_N_ELEMENTS(vmsg->fds)) {
 error_report("A maximum of %d fds are allowed, "
  "however got %lu fds now",
  VHOST_MEMORY_MAX_NREGIONS, nfds);
 goto fail;
 }
 memcpy(vmsg->fds + nfds, fds_t, nfds_t * sizeof(vds->fds[0]));
 nfds += nfds_t;

Did I misunderstand how this works?


No, the temporary fds[] array is not necessary. Thank for the
simplication!


+}
+if (read_bytes == VHOST_USER_HDR_SIZE || rc == 0) {
+break;
+}
+iov.iov_base = (char *)vmsg + read_bytes;
+iov.iov_len = VHOST_USER_HDR_SIZE - read_bytes;
+} while (true);
+
+vmsg->fd_num = nfds;
+if (nfds > 0) {
+memcpy(vmsg->fds, fds, nfds * sizeof(int));
+}
+g_free(fds);
+/* qio_channel_readv_full will make socket fds blocking, unblock them */
+vmsg_unblock_fds(vmsg);
+if (vmsg->size > sizeof(vmsg->payload)) {
+error_report("Error: too big message request: %d, "
+ "size: vmsg->size: %u, "
+ "while sizeof(vmsg->payload) = %zu",
+ vmsg->request, vmsg->size, sizeof(vmsg->payload));
+goto fail;
+}
+
+struct iovec iov_payload = {
+.iov_base = (char *)&vmsg->payload,
+.iov_len = vmsg->size,
+};
+if (vmsg->size) {
+rc = qio_channel_readv_all_eof(ioc, &iov_payload, 1, &local_err);
+if (rc == -1) {
+error_report_err(local_err);
+goto fail;
+}
+}
+
+return true;
+
+fail:
+vmsg_close_fds(vmsg);
+
+return false;
+}
+
+
+static void vu_client_start(VuServer *server);
+static coroutine_fn void vu_client_trip(void *opaque)
+{
+VuServer *server = opaque;
+
+while (!server->aio_context_changed && server->sioc) {
+vu_dispatch(&server->vu_dev);
+}
+
+if (server->aio_context_changed && server->sioc) {
+server->aio_context_changed = false;
+vu_client_start(server);
+}
+}
+
+static void vu_client_start(VuServer *server)
+{
+server->co_trip = qemu_coroutine_create(vu_client_trip, server);
+aio_co_enter(server->ctx, server->co_trip);
+}
+
+/*
+ * a wrapper for vu_kick_cb
+ *
+ * since aio_dispatch can only pass one user data pointer to the
+ * callback function, pack VuDev and pvt into a struct. Then unpack it
+ * and pass them to vu_kick_cb
+ */
+static void kick_handler(void *opaque)
+{
+KickInfo *kick_info = opaque;
+kick_info->cb(kick_info->vu_dev, 0, (void *) kick_info-

[PATCH v9 5/5] new qTest case to test the vhost-user-blk-server

This test case has the same tests as tests/virtio-blk-test.c except for
tests have block_resize. Since vhost-user server can only server one
client one time, two instances of qemu-storage-daemon are launched
for the hotplug test.

In order to not block scripts/tap-driver.pl, vhost-user-blk-server will
send "quit" command to qemu-storage-daemon's QMP monitor. So a function
is added to libqtest.c to establish socket connection with socket
server.

Signed-off-by: Coiby Xu 
---
 tests/Makefile.include  |   3 +-
 tests/qtest/Makefile.include|   2 +
 tests/qtest/libqos/vhost-user-blk.c | 130 +
 tests/qtest/libqos/vhost-user-blk.h |  48 ++
 tests/qtest/libqtest.c  |  35 +-
 tests/qtest/libqtest.h  |  17 +
 tests/qtest/vhost-user-blk-test.c   | 739 
 7 files changed, 971 insertions(+), 3 deletions(-)
 create mode 100644 tests/qtest/libqos/vhost-user-blk.c
 create mode 100644 tests/qtest/libqos/vhost-user-blk.h
 create mode 100644 tests/qtest/vhost-user-blk-test.c

diff --git a/tests/Makefile.include b/tests/Makefile.include
index c2397de8ed..303235b40f 100644
--- a/tests/Makefile.include
+++ b/tests/Makefile.include
@@ -638,7 +638,8 @@ endef
 $(patsubst %, check-qtest-%, $(QTEST_TARGETS)): check-qtest-%: %-softmmu/all 
$(check-qtest-y)
$(call do_test_human,$(check-qtest-$*-y:%=tests/qtest/%$(EXESUF)) 
$(check-qtest-generic-y:%=tests/qtest/%$(EXESUF)), \
  QTEST_QEMU_BINARY=$*-softmmu/qemu-system-$* \
- QTEST_QEMU_IMG=qemu-img$(EXESUF))
+ QTEST_QEMU_IMG=./qemu-img$(EXESUF) \
+ QTEST_QEMU_STORAGE_DAEMON_BINARY=./qemu-storage-daemon$(EXESUF))
 
 check-unit: $(check-unit-y)
$(call do_test_human, $^)
diff --git a/tests/qtest/Makefile.include b/tests/qtest/Makefile.include
index 9e5a51d033..b6f081cb26 100644
--- a/tests/qtest/Makefile.include
+++ b/tests/qtest/Makefile.include
@@ -186,6 +186,7 @@ libqos-obj-y += tests/qtest/libqos/virtio.o
 libqos-obj-$(CONFIG_VIRTFS) += tests/qtest/libqos/virtio-9p.o
 libqos-obj-y += tests/qtest/libqos/virtio-balloon.o
 libqos-obj-y += tests/qtest/libqos/virtio-blk.o
+libqos-obj-$(CONFIG_LINUX) += tests/qtest/libqos/vhost-user-blk.o
 libqos-obj-y += tests/qtest/libqos/virtio-mmio.o
 libqos-obj-y += tests/qtest/libqos/virtio-net.o
 libqos-obj-y += tests/qtest/libqos/virtio-pci.o
@@ -230,6 +231,7 @@ qos-test-obj-$(CONFIG_VHOST_NET_USER) += 
tests/qtest/vhost-user-test.o $(chardev
 qos-test-obj-y += tests/qtest/virtio-test.o
 qos-test-obj-$(CONFIG_VIRTFS) += tests/qtest/virtio-9p-test.o
 qos-test-obj-y += tests/qtest/virtio-blk-test.o
+qos-test-obj-$(CONFIG_LINUX) += tests/qtest/vhost-user-blk-test.o
 qos-test-obj-y += tests/qtest/virtio-net-test.o
 qos-test-obj-y += tests/qtest/virtio-rng-test.o
 qos-test-obj-y += tests/qtest/virtio-scsi-test.o
diff --git a/tests/qtest/libqos/vhost-user-blk.c 
b/tests/qtest/libqos/vhost-user-blk.c
new file mode 100644
index 00..3de9c59194
--- /dev/null
+++ b/tests/qtest/libqos/vhost-user-blk.c
@@ -0,0 +1,130 @@
+/*
+ * libqos driver framework
+ *
+ * Based on tests/qtest/libqos/virtio-blk.c
+ *
+ * Copyright (c) 2020 Coiby Xu 
+ *
+ * Copyright (c) 2018 Emanuele Giuseppe Esposito 
+ *
+ * This library is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU Lesser General Public
+ * License version 2.1 as published by the Free Software Foundation.
+ *
+ * This library is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
+ * Lesser General Public License for more details.
+ *
+ * You should have received a copy of the GNU Lesser General Public
+ * License along with this library; if not, see 
+ */
+
+#include "qemu/osdep.h"
+#include "libqtest.h"
+#include "qemu/module.h"
+#include "standard-headers/linux/virtio_blk.h"
+#include "libqos/qgraph.h"
+#include "libqos/vhost-user-blk.h"
+
+#define PCI_SLOT0x04
+#define PCI_FN  0x00
+
+/* virtio-blk-device */
+static void *qvhost_user_blk_get_driver(QVhostUserBlk *v_blk,
+const char *interface)
+{
+if (!g_strcmp0(interface, "vhost-user-blk")) {
+return v_blk;
+}
+if (!g_strcmp0(interface, "virtio")) {
+return v_blk->vdev;
+}
+
+fprintf(stderr, "%s not present in vhost-user-blk-device\n", interface);
+g_assert_not_reached();
+}
+
+static void *qvhost_user_blk_device_get_driver(void *object,
+   const char *interface)
+{
+QVhostUserBlkDevice *v_blk = object;
+return qvhost_user_blk_get_driver(&v_blk->blk, interface);
+}
+
+static void *vhost_user_blk_device_create(void *virtio_dev,
+  QGuestAllocator *t_alloc,
+  void *addr)
+{
+QVhostUserBlkDevice *vhost_user_b

[PATCH v9 1/5] Allow vu_message_read to be replaced

Allow vu_message_read to be replaced by one which will make use of the
QIOChannel functions. Thus reading vhost-user message won't stall the
guest.

Signed-off-by: Coiby Xu 
---
 contrib/libvhost-user/libvhost-user-glib.c |  2 +-
 contrib/libvhost-user/libvhost-user.c  | 11 ++-
 contrib/libvhost-user/libvhost-user.h  | 21 +
 tests/vhost-user-bridge.c  |  2 ++
 tools/virtiofsd/fuse_virtio.c  |  4 ++--
 5 files changed, 32 insertions(+), 8 deletions(-)

diff --git a/contrib/libvhost-user/libvhost-user-glib.c 
b/contrib/libvhost-user/libvhost-user-glib.c
index 53f1ca4cdd..0df2ec9271 100644
--- a/contrib/libvhost-user/libvhost-user-glib.c
+++ b/contrib/libvhost-user/libvhost-user-glib.c
@@ -147,7 +147,7 @@ vug_init(VugDev *dev, uint16_t max_queues, int socket,
 g_assert(dev);
 g_assert(iface);
 
-if (!vu_init(&dev->parent, max_queues, socket, panic, set_watch,
+if (!vu_init(&dev->parent, max_queues, socket, panic, NULL, set_watch,
  remove_watch, iface)) {
 return false;
 }
diff --git a/contrib/libvhost-user/libvhost-user.c 
b/contrib/libvhost-user/libvhost-user.c
index 3bca996c62..0c7368baa2 100644
--- a/contrib/libvhost-user/libvhost-user.c
+++ b/contrib/libvhost-user/libvhost-user.c
@@ -67,8 +67,6 @@
 /* The version of inflight buffer */
 #define INFLIGHT_VERSION 1
 
-#define VHOST_USER_HDR_SIZE offsetof(VhostUserMsg, payload.u64)
-
 /* The version of the protocol we support */
 #define VHOST_USER_VERSION 1
 #define LIBVHOST_USER_DEBUG 0
@@ -412,7 +410,7 @@ vu_process_message_reply(VuDev *dev, const VhostUserMsg 
*vmsg)
 goto out;
 }
 
-if (!vu_message_read(dev, dev->slave_fd, &msg_reply)) {
+if (!dev->read_msg(dev, dev->slave_fd, &msg_reply)) {
 goto out;
 }
 
@@ -647,7 +645,7 @@ vu_set_mem_table_exec_postcopy(VuDev *dev, VhostUserMsg 
*vmsg)
 /* Wait for QEMU to confirm that it's registered the handler for the
  * faults.
  */
-if (!vu_message_read(dev, dev->sock, vmsg) ||
+if (!dev->read_msg(dev, dev->sock, vmsg) ||
 vmsg->size != sizeof(vmsg->payload.u64) ||
 vmsg->payload.u64 != 0) {
 vu_panic(dev, "failed to receive valid ack for postcopy 
set-mem-table");
@@ -1653,7 +1651,7 @@ vu_dispatch(VuDev *dev)
 int reply_requested;
 bool need_reply, success = false;
 
-if (!vu_message_read(dev, dev->sock, &vmsg)) {
+if (!dev->read_msg(dev, dev->sock, &vmsg)) {
 goto end;
 }
 
@@ -1704,6 +1702,7 @@ vu_deinit(VuDev *dev)
 }
 
 if (vq->kick_fd != -1) {
+dev->remove_watch(dev, vq->kick_fd);
 close(vq->kick_fd);
 vq->kick_fd = -1;
 }
@@ -1751,6 +1750,7 @@ vu_init(VuDev *dev,
 uint16_t max_queues,
 int socket,
 vu_panic_cb panic,
+vu_read_msg_cb read_msg,
 vu_set_watch_cb set_watch,
 vu_remove_watch_cb remove_watch,
 const VuDevIface *iface)
@@ -1768,6 +1768,7 @@ vu_init(VuDev *dev,
 
 dev->sock = socket;
 dev->panic = panic;
+dev->read_msg = read_msg ? read_msg : vu_message_read;
 dev->set_watch = set_watch;
 dev->remove_watch = remove_watch;
 dev->iface = iface;
diff --git a/contrib/libvhost-user/libvhost-user.h 
b/contrib/libvhost-user/libvhost-user.h
index f30394fab6..d756da8548 100644
--- a/contrib/libvhost-user/libvhost-user.h
+++ b/contrib/libvhost-user/libvhost-user.h
@@ -30,6 +30,8 @@
 
 #define VHOST_MEMORY_MAX_NREGIONS 8
 
+#define VHOST_USER_HDR_SIZE offsetof(VhostUserMsg, payload.u64)
+
 typedef enum VhostSetConfigType {
 VHOST_SET_CONFIG_TYPE_MASTER = 0,
 VHOST_SET_CONFIG_TYPE_MIGRATION = 1,
@@ -205,6 +207,7 @@ typedef uint64_t (*vu_get_features_cb) (VuDev *dev);
 typedef void (*vu_set_features_cb) (VuDev *dev, uint64_t features);
 typedef int (*vu_process_msg_cb) (VuDev *dev, VhostUserMsg *vmsg,
   int *do_reply);
+typedef bool (*vu_read_msg_cb) (VuDev *dev, int sock, VhostUserMsg *vmsg);
 typedef void (*vu_queue_set_started_cb) (VuDev *dev, int qidx, bool started);
 typedef bool (*vu_queue_is_processed_in_order_cb) (VuDev *dev, int qidx);
 typedef int (*vu_get_config_cb) (VuDev *dev, uint8_t *config, uint32_t len);
@@ -373,6 +376,23 @@ struct VuDev {
 bool broken;
 uint16_t max_queues;
 
+/* @read_msg: custom method to read vhost-user message
+ *
+ * Read data from vhost_user socket fd and fill up
+ * the passed VhostUserMsg *vmsg struct.
+ *
+ * If reading fails, it should close the received set of file
+ * descriptors as socket message's auxiliary data.
+ *
+ * For the details, please refer to vu_message_read in libvhost-user.c
+ * which will be used by default if not custom method is provided when
+ * calling vu_init
+ *
+ * Returns: true if vhost-user message successfully received,
+ *  otherwise return false.
+ *
+ */
+vu_read_m

[PATCH v9 4/5] vhost-user block device backend server

By making use of libvhost-user, block device drive can be shared to
the connected vhost-user client. Only one client can connect to the
server one time.

Since vhost-user-server needs a block drive to be created first, delay
the creation of this object.

Signed-off-by: Coiby Xu 
---
 block/Makefile.objs  |   1 +
 block/export/vhost-user-blk-server.c | 669 +++
 block/export/vhost-user-blk-server.h |  35 ++
 softmmu/vl.c |   4 +
 4 files changed, 709 insertions(+)
 create mode 100644 block/export/vhost-user-blk-server.c
 create mode 100644 block/export/vhost-user-blk-server.h

diff --git a/block/Makefile.objs b/block/Makefile.objs
index 3635b6b4c1..0eb7eff470 100644
--- a/block/Makefile.objs
+++ b/block/Makefile.objs
@@ -24,6 +24,7 @@ block-obj-y += throttle-groups.o
 block-obj-$(CONFIG_LINUX) += nvme.o
 
 block-obj-y += nbd.o
+block-obj-$(CONFIG_LINUX) += export/vhost-user-blk-server.o 
../contrib/libvhost-user/libvhost-user.o
 block-obj-$(CONFIG_SHEEPDOG) += sheepdog.o
 block-obj-$(CONFIG_LIBISCSI) += iscsi.o
 block-obj-$(if $(CONFIG_LIBISCSI),y,n) += iscsi-opts.o
diff --git a/block/export/vhost-user-blk-server.c 
b/block/export/vhost-user-blk-server.c
new file mode 100644
index 00..bbf2ceaa9b
--- /dev/null
+++ b/block/export/vhost-user-blk-server.c
@@ -0,0 +1,669 @@
+/*
+ * Sharing QEMU block devices via vhost-user protocal
+ *
+ * Author: Coiby Xu 
+ *
+ * This work is licensed under the terms of the GNU GPL, version 2 or
+ * later.  See the COPYING file in the top-level directory.
+ */
+#include "qemu/osdep.h"
+#include "block/block.h"
+#include "vhost-user-blk-server.h"
+#include "qapi/error.h"
+#include "qom/object_interfaces.h"
+#include "sysemu/block-backend.h"
+#include "util/block-helpers.h"
+
+enum {
+VHOST_USER_BLK_MAX_QUEUES = 1,
+};
+struct virtio_blk_inhdr {
+unsigned char status;
+};
+
+
+typedef struct VuBlockReq {
+VuVirtqElement *elem;
+int64_t sector_num;
+size_t size;
+struct virtio_blk_inhdr *in;
+struct virtio_blk_outhdr out;
+VuServer *server;
+struct VuVirtq *vq;
+} VuBlockReq;
+
+
+static void vu_block_req_complete(VuBlockReq *req)
+{
+VuDev *vu_dev = &req->server->vu_dev;
+
+/* IO size with 1 extra status byte */
+vu_queue_push(vu_dev, req->vq, req->elem, req->size + 1);
+vu_queue_notify(vu_dev, req->vq);
+
+if (req->elem) {
+free(req->elem);
+}
+
+g_free(req);
+}
+
+static VuBlockDev *get_vu_block_device_by_server(VuServer *server)
+{
+return container_of(server, VuBlockDev, vu_server);
+}
+
+static int coroutine_fn
+vu_block_discard_write_zeroes(VuBlockReq *req, struct iovec *iov,
+  uint32_t iovcnt, uint32_t type)
+{
+struct virtio_blk_discard_write_zeroes desc;
+ssize_t size = iov_to_buf(iov, iovcnt, 0, &desc, sizeof(desc));
+if (unlikely(size != sizeof(desc))) {
+error_report("Invalid size %ld, expect %ld", size, sizeof(desc));
+return -EINVAL;
+}
+
+VuBlockDev *vdev_blk = get_vu_block_device_by_server(req->server);
+uint64_t range[2] = { le64_to_cpu(desc.sector) << 9,
+  le32_to_cpu(desc.num_sectors) << 9 };
+if (type == VIRTIO_BLK_T_DISCARD) {
+if (blk_co_pdiscard(vdev_blk->backend, range[0], range[1]) == 0) {
+return 0;
+}
+} else if (type == VIRTIO_BLK_T_WRITE_ZEROES) {
+if (blk_co_pwrite_zeroes(vdev_blk->backend,
+ range[0], range[1], 0) == 0) {
+return 0;
+}
+}
+
+return -EINVAL;
+}
+
+
+static void coroutine_fn vu_block_flush(VuBlockReq *req)
+{
+VuBlockDev *vdev_blk = get_vu_block_device_by_server(req->server);
+BlockBackend *backend = vdev_blk->backend;
+blk_co_flush(backend);
+}
+
+
+struct req_data {
+VuServer *server;
+VuVirtq *vq;
+VuVirtqElement *elem;
+};
+
+static void coroutine_fn vu_block_virtio_process_req(void *opaque)
+{
+struct req_data *data = opaque;
+VuServer *server = data->server;
+VuVirtq *vq = data->vq;
+VuVirtqElement *elem = data->elem;
+uint32_t type;
+VuBlockReq *req;
+
+VuBlockDev *vdev_blk = get_vu_block_device_by_server(server);
+BlockBackend *backend = vdev_blk->backend;
+
+struct iovec *in_iov = elem->in_sg;
+struct iovec *out_iov = elem->out_sg;
+unsigned in_num = elem->in_num;
+unsigned out_num = elem->out_num;
+/* refer to hw/block/virtio_blk.c */
+if (elem->out_num < 1 || elem->in_num < 1) {
+error_report("virtio-blk request missing headers");
+free(elem);
+return;
+}
+
+req = g_new0(VuBlockReq, 1);
+req->server = server;
+req->vq = vq;
+req->elem = elem;
+
+if (unlikely(iov_to_buf(out_iov, out_num, 0, &req->out,
+sizeof(req->out)) != sizeof(req->out))) {
+error_report("virtio-blk request outhdr too short");
+goto err;
+}
+

[PATCH v9 0/5] vhost-user block device backend implementation

v9
 - move logical block size check function to a utility function
 - fix issues regarding license, coding style, memory deallocation, etc.

v8
 - re-try connecting to socket server to fix asan error
 - fix license naming issue

v7
 - fix docker-test-debug@fedora errors by freeing malloced memory

v6
 - add missing license header and include guard
 - vhost-user server only serve one client one time
 - fix a bug in custom vu_message_read
 - using qemu-storage-daemon to start vhost-user-blk-server
 - a bug fix to pass docker-test-clang@ubuntu

v5:
 * re-use vu_kick_cb in libvhost-user
 * keeping processing VhostUserMsg in the same coroutine until there is
   detachment/attachment of AIOContext
 * Spawn separate coroutine for each VuVirtqElement
 * Other changes including relocating vhost-user-blk-server.c, coding
   style etc.

v4:
 * add object properties in class_init
 * relocate vhost-user-blk-test
 * other changes including using SocketAddress, coding style, etc.

v3:
 * separate generic vhost-user-server code from vhost-user-blk-server
   code
 * re-write vu_message_read and kick hander function as coroutines to
   directly call blk_co_preadv, blk_co_pwritev, etc.
 * add aio_context notifier functions to support multi-threading model
 * other fixes regarding coding style, warning report, etc.

v2:
 * Only enable this feature for Linux because eventfd is a Linux-specific
   feature


This patch series is an implementation of vhost-user block device
backend server, thanks to Stefan and Kevin's guidance.

Vhost-user block device backend server is a UserCreatable object and can be
started using object_add,

 (qemu) object_add 
vhost-user-blk-server,id=ID,unix-socket=/tmp/vhost-user-blk_vhost.socket,node-name=DRIVE_NAME,writable=off,logical-block-size=512
 (qemu) object_del ID

or appending the "-object" option when starting QEMU,

  $ -object 
vhost-user-blk-server,id=disk,unix-socket=/tmp/vhost-user-blk_vhost.socket,node-name=DRIVE_NAME,writable=off,logical-block-size=512

Then vhost-user client can connect to the server backend.
For example, QEMU could act as a client,

  $ -m 256 -object memory-backend-memfd,id=mem,size=256M,share=on -numa 
node,memdev=mem -chardev socket,id=char1,path=/tmp/vhost-user-blk_vhost.socket 
-device vhost-user-blk-pci,id=blk0,chardev=char1

And guest OS could access this vhost-user block device after mounting it.


Coiby Xu (5):
  Allow vu_message_read to be replaced
  generic vhost user server
  move logical block size check function to a common utility function
  vhost-user block device backend server
  new qTest case to test the vhost-user-blk-server

 block/Makefile.objs|   1 +
 block/export/vhost-user-blk-server.c   | 669 +++
 block/export/vhost-user-blk-server.h   |  35 +
 contrib/libvhost-user/libvhost-user-glib.c |   2 +-
 contrib/libvhost-user/libvhost-user.c  |  11 +-
 contrib/libvhost-user/libvhost-user.h  |  21 +
 hw/core/qdev-properties.c  |  18 +-
 softmmu/vl.c   |   4 +
 tests/Makefile.include |   3 +-
 tests/qtest/Makefile.include   |   2 +
 tests/qtest/libqos/vhost-user-blk.c| 130 
 tests/qtest/libqos/vhost-user-blk.h|  48 ++
 tests/qtest/libqtest.c |  35 +-
 tests/qtest/libqtest.h |  17 +
 tests/qtest/vhost-user-blk-test.c  | 739 +
 tests/vhost-user-bridge.c  |   2 +
 tools/virtiofsd/fuse_virtio.c  |   4 +-
 util/Makefile.objs |   2 +
 util/block-helpers.c   |  46 ++
 util/block-helpers.h   |   7 +
 util/vhost-user-server.c   | 400 +++
 util/vhost-user-server.h   |  61 ++
 22 files changed, 2231 insertions(+), 26 deletions(-)
 create mode 100644 block/export/vhost-user-blk-server.c
 create mode 100644 block/export/vhost-user-blk-server.h
 create mode 100644 tests/qtest/libqos/vhost-user-blk.c
 create mode 100644 tests/qtest/libqos/vhost-user-blk.h
 create mode 100644 tests/qtest/vhost-user-blk-test.c
 create mode 100644 util/block-helpers.c
 create mode 100644 util/block-helpers.h
 create mode 100644 util/vhost-user-server.c
 create mode 100644 util/vhost-user-server.h

--
2.27.0

[PATCH v9 2/5] generic vhost user server

Sharing QEMU devices via vhost-user protocol.

Only one vhost-user client can connect to the server one time.

Signed-off-by: Coiby Xu 
---
 util/Makefile.objs   |   1 +
 util/vhost-user-server.c | 400 +++
 util/vhost-user-server.h |  61 ++
 3 files changed, 462 insertions(+)
 create mode 100644 util/vhost-user-server.c
 create mode 100644 util/vhost-user-server.h

diff --git a/util/Makefile.objs b/util/Makefile.objs
index cc5e37177a..b4d4af06dc 100644
--- a/util/Makefile.objs
+++ b/util/Makefile.objs
@@ -66,6 +66,7 @@ util-obj-y += hbitmap.o
 util-obj-y += main-loop.o
 util-obj-y += nvdimm-utils.o
 util-obj-y += qemu-coroutine.o qemu-coroutine-lock.o qemu-coroutine-io.o
+util-obj-$(CONFIG_LINUX) += vhost-user-server.o
 util-obj-y += qemu-coroutine-sleep.o
 util-obj-y += qemu-co-shared-resource.o
 util-obj-y += qemu-sockets.o
diff --git a/util/vhost-user-server.c b/util/vhost-user-server.c
new file mode 100644
index 00..393beeb6b9
--- /dev/null
+++ b/util/vhost-user-server.c
@@ -0,0 +1,400 @@
+/*
+ * Sharing QEMU devices via vhost-user protocol
+ *
+ * Author: Coiby Xu 
+ *
+ * This work is licensed under the terms of the GNU GPL, version 2 or
+ * later.  See the COPYING file in the top-level directory.
+ */
+#include "qemu/osdep.h"
+#include 
+#include "qemu/main-loop.h"
+#include "vhost-user-server.h"
+
+static void vmsg_close_fds(VhostUserMsg *vmsg)
+{
+int i;
+for (i = 0; i < vmsg->fd_num; i++) {
+close(vmsg->fds[i]);
+}
+}
+
+static void vmsg_unblock_fds(VhostUserMsg *vmsg)
+{
+int i;
+for (i = 0; i < vmsg->fd_num; i++) {
+qemu_set_nonblock(vmsg->fds[i]);
+}
+}
+
+static void vu_accept(QIONetListener *listener, QIOChannelSocket *sioc,
+  gpointer opaque);
+
+static void close_client(VuServer *server)
+{
+vu_deinit(&server->vu_dev);
+object_unref(OBJECT(server->sioc));
+object_unref(OBJECT(server->ioc));
+server->sioc_slave = NULL;
+object_unref(OBJECT(server->ioc_slave));
+/*
+ * Set the callback function for network listener so another
+ * vhost-user client can connect to this server
+ */
+qio_net_listener_set_client_func(server->listener,
+ vu_accept,
+ server,
+ NULL);
+}
+
+static void panic_cb(VuDev *vu_dev, const char *buf)
+{
+VuServer *server = container_of(vu_dev, VuServer, vu_dev);
+
+if (buf) {
+error_report("vu_panic: %s", buf);
+}
+
+if (server->sioc) {
+close_client(server);
+server->sioc = NULL;
+}
+
+if (server->device_panic_notifier) {
+server->device_panic_notifier(server);
+}
+}
+
+static QIOChannel *slave_io_channel(VuServer *server, int fd,
+Error **local_err)
+{
+if (server->sioc_slave) {
+if (fd == server->sioc_slave->fd) {
+return server->ioc_slave;
+}
+} else {
+server->sioc_slave = qio_channel_socket_new_fd(fd, local_err);
+if (!*local_err) {
+server->ioc_slave = QIO_CHANNEL(server->sioc_slave);
+return server->ioc_slave;
+}
+}
+
+return NULL;
+}
+
+static bool coroutine_fn
+vu_message_read(VuDev *vu_dev, int conn_fd, VhostUserMsg *vmsg)
+{
+struct iovec iov = {
+.iov_base = (char *)vmsg,
+.iov_len = VHOST_USER_HDR_SIZE,
+};
+int rc, read_bytes = 0;
+Error *local_err = NULL;
+/*
+ * Store fds/nfds returned from qio_channel_readv_full into
+ * temporary variables.
+ *
+ * VhostUserMsg is a packed structure, gcc will complain about passing
+ * pointer to a packed structure member if we pass &VhostUserMsg.fd_num
+ * and &VhostUserMsg.fds directly when calling qio_channel_readv_full,
+ * thus two temporary variables nfds and fds are used here.
+ */
+size_t nfds = 0, nfds_t = 0;
+int *fds_t = NULL;
+VuServer *server = container_of(vu_dev, VuServer, vu_dev);
+QIOChannel *ioc = NULL;
+
+if (conn_fd == server->sioc->fd) {
+ioc = server->ioc;
+} else {
+/* Slave communication will also use this function to read msg */
+ioc = slave_io_channel(server, conn_fd, &local_err);
+}
+
+if (!ioc) {
+error_report_err(local_err);
+goto fail;
+}
+
+assert(qemu_in_coroutine());
+do {
+/*
+ * qio_channel_readv_full may have short reads, keeping calling it
+ * until getting VHOST_USER_HDR_SIZE or 0 bytes in total
+ */
+rc = qio_channel_readv_full(ioc, &iov, 1, &fds_t, &nfds_t, &local_err);
+if (rc < 0) {
+if (rc == QIO_CHANNEL_ERR_BLOCK) {
+qio_channel_yield(ioc, G_IO_IN);
+continue;
+} else {
+error_report_err(local_err);
+return false;
+}
+}
+read_b

[PATCH v9 3/5] move logical block size check function to a common utility function

Move logical block size check function in 
hw/core/qdev-properties.c:set_blocksize() to util/block-helpers.c

Signed-off-by: Coiby Xu 
---
 hw/core/qdev-properties.c | 18 +++
 util/Makefile.objs|  1 +
 util/block-helpers.c  | 46 +++
 util/block-helpers.h  |  7 ++
 4 files changed, 57 insertions(+), 15 deletions(-)
 create mode 100644 util/block-helpers.c
 create mode 100644 util/block-helpers.h

diff --git a/hw/core/qdev-properties.c b/hw/core/qdev-properties.c
index cc924815da..a4a6aa5204 100644
--- a/hw/core/qdev-properties.c
+++ b/hw/core/qdev-properties.c
@@ -14,6 +14,7 @@
 #include "qapi/visitor.h"
 #include "chardev/char.h"
 #include "qemu/uuid.h"
+#include "util/block-helpers.h"
 
 void qdev_prop_set_after_realize(DeviceState *dev, const char *name,
   Error **errp)
@@ -736,8 +737,6 @@ static void set_blocksize(Object *obj, Visitor *v, const 
char *name,
 Property *prop = opaque;
 uint16_t value, *ptr = qdev_get_prop_ptr(dev, prop);
 Error *local_err = NULL;
-const int64_t min = 512;
-const int64_t max = 32768;
 
 if (dev->realized) {
 qdev_prop_set_after_realize(dev, name, errp);
@@ -749,21 +748,10 @@ static void set_blocksize(Object *obj, Visitor *v, const 
char *name,
 error_propagate(errp, local_err);
 return;
 }
-/* value of 0 means "unset" */
-if (value && (value < min || value > max)) {
-error_setg(errp, QERR_PROPERTY_VALUE_OUT_OF_RANGE,
-   dev->id ? : "", name, (int64_t)value, min, max);
+check_logical_block_size(dev->id ? : "", name, value, errp);
+if (errp) {
 return;
 }
-
-/* We rely on power-of-2 blocksizes for bitmasks */
-if ((value & (value - 1)) != 0) {
-error_setg(errp,
-  "Property %s.%s doesn't take value '%" PRId64 "', it's not a 
power of 2",
-  dev->id ?: "", name, (int64_t)value);
-return;
-}
-
 *ptr = value;
 }
 
diff --git a/util/Makefile.objs b/util/Makefile.objs
index b4d4af06dc..fa5380ddab 100644
--- a/util/Makefile.objs
+++ b/util/Makefile.objs
@@ -66,6 +66,7 @@ util-obj-y += hbitmap.o
 util-obj-y += main-loop.o
 util-obj-y += nvdimm-utils.o
 util-obj-y += qemu-coroutine.o qemu-coroutine-lock.o qemu-coroutine-io.o
+util-obj-y += block-helpers.o
 util-obj-$(CONFIG_LINUX) += vhost-user-server.o
 util-obj-y += qemu-coroutine-sleep.o
 util-obj-y += qemu-co-shared-resource.o
diff --git a/util/block-helpers.c b/util/block-helpers.c
new file mode 100644
index 00..d31309cc0e
--- /dev/null
+++ b/util/block-helpers.c
@@ -0,0 +1,46 @@
+/*
+ * Block utility functions
+ *
+ * Copyright (c) 2020 Coiby Xu 
+ *
+ * This work is licensed under the terms of the GNU GPL, version 2 or later.
+ * See the COPYING file in the top-level directory.
+ */
+
+#include "qemu/osdep.h"
+#include "qapi/error.h"
+#include "qapi/qmp/qerror.h"
+#include "block-helpers.h"
+
+/*
+ * Logical block size input validation
+ *
+ * The size should meet the following conditions:
+ * 1. min=512
+ * 2. max=32768
+ * 3. a power of 2
+ *
+ *  Moved from hw/core/qdev-properties.c:set_blocksize()
+ */
+void check_logical_block_size(const char *id, const char *name, uint16_t value,
+ Error **errp)
+{
+const int64_t min = 512;
+const int64_t max = 32768;
+
+/* value of 0 means "unset" */
+if (value && (value < min || value > max)) {
+error_setg(errp, QERR_PROPERTY_VALUE_OUT_OF_RANGE,
+   id, name, (int64_t)value, min, max);
+return;
+}
+
+/* We rely on power-of-2 blocksizes for bitmasks */
+if ((value & (value - 1)) != 0) {
+error_setg(errp,
+   "Property %s.%s doesn't take value '%" PRId64
+   "', it's not a power of 2",
+   id, name, (int64_t)value);
+return;
+}
+}
diff --git a/util/block-helpers.h b/util/block-helpers.h
new file mode 100644
index 00..f06be282a1
--- /dev/null
+++ b/util/block-helpers.h
@@ -0,0 +1,7 @@
+#ifndef BLOCK_HELPERS_H
+#define BLOCK_HELPERS_H
+
+void check_logical_block_size(const char *id, const char *name, uint16_t value,
+ Error **errp);
+
+#endif /* BLOCK_HELPERS_H */
-- 
2.27.0

[PATCH v4 3/9] grackle: Set revision in PCI config to match hardware

Signed-off-by: BALATON Zoltan 
---
 hw/pci-host/grackle.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/hw/pci-host/grackle.c b/hw/pci-host/grackle.c
index 4b3af0c704..48d11f13ab 100644
--- a/hw/pci-host/grackle.c
+++ b/hw/pci-host/grackle.c
@@ -130,7 +130,7 @@ static void grackle_pci_class_init(ObjectClass *klass, void 
*data)
 k->realize   = grackle_pci_realize;
 k->vendor_id = PCI_VENDOR_ID_MOTOROLA;
 k->device_id = PCI_DEVICE_ID_MOTOROLA_MPC106;
-k->revision  = 0x00;
+k->revision  = 0x40;
 k->class_id  = PCI_CLASS_BRIDGE_HOST;
 /*
  * PCI-facing part of the host bridge, not usable without the
-- 
2.21.3

[PATCH v4 8/9] WIP RFC macio/cuda: Attempt to add i2c support

This is a non-working RFC patch attempt to implement i2c bus in CUDA
needed for firmware to access SPD data of installed RAM. The skeleton
is there but actual operation fails because I don't know how this is
supposed to work and the i2c bus state becomes invalid quickly. Also
sending back results may be missing or wrong. Help fixing and
finishing this is welcome, I don't plan to spend more time with this
so just submitted it for whoever picks this up.

Signed-off-by: BALATON Zoltan 
---
 hw/misc/macio/cuda.c | 65 +++-
 include/hw/misc/macio/cuda.h |  1 +
 2 files changed, 65 insertions(+), 1 deletion(-)

diff --git a/hw/misc/macio/cuda.c b/hw/misc/macio/cuda.c
index e0cc0aac5d..9609828091 100644
--- a/hw/misc/macio/cuda.c
+++ b/hw/misc/macio/cuda.c
@@ -28,6 +28,7 @@
 #include "hw/ppc/mac.h"
 #include "hw/qdev-properties.h"
 #include "migration/vmstate.h"
+#include "hw/i2c/i2c.h"
 #include "hw/input/adb.h"
 #include "hw/misc/mos6522.h"
 #include "hw/misc/macio/cuda.h"
@@ -369,6 +370,64 @@ static bool cuda_cmd_set_time(CUDAState *s,
 return true;
 }
 
+static bool cuda_cmd_get_set_iic(CUDAState *s,
+ const uint8_t *in_data, int in_len,
+ uint8_t *out_data, int *out_len)
+{
+int i;
+
+qemu_log_mask(LOG_UNIMP, "CUDA: unimplemented GET_SET_IIC %s 0x%x %d\n",
+  (in_data[0] & 1 ? "read" : "write"), in_data[0] >> 1,
+  in_len);
+if (i2c_start_transfer(s->i2c_bus, in_data[0] >> 1, in_data[0] & 1)) {
+return false;
+}
+for (i = 0; i < in_len - 3; i++) {
+if (i2c_send(s->i2c_bus, in_data[i])) {
+i2c_end_transfer(s->i2c_bus);
+return false;
+}
+}
+return true;
+}
+
+static bool cuda_cmd_combined_iic(CUDAState *s,
+  const uint8_t *in_data, int in_len,
+  uint8_t *out_data, int *out_len)
+{
+int i;
+
+if (in_len < 3) {
+qemu_log_mask(LOG_GUEST_ERROR,
+  "CUDA: COMBINED_FORMAT_IIC too few input bytes\n");
+return false;
+}
+if ((in_data[0] & 0xfe) != (in_data[2] & 0xfe)) {
+qemu_log_mask(LOG_GUEST_ERROR,
+  "CUDA: COMBINED_FORMAT_IIC address mismatch\n");
+return false;
+}
+
+uint8_t addr = in_data[0] >> 1;
+int recv = in_data[0] & 1;
+
+uint8_t data = in_data[1];
+if (i2c_start_transfer(s->i2c_bus, in_data[0] >> 1, in_data[0] & 1) ||
+i2c_send_recv(s->i2c_bus, &data, in_data[0] & 1)) {
+return false;
+} else {
+for (i = 0; i < in_len - 3; i++) {
+data = in_data[3 + i];
+if (i2c_send_recv(s->i2c_bus, (in_data[2] & 1 ? &out_data[i] :
+  &data), in_data[2] & 1)) {
+i2c_end_transfer(s->i2c_bus);
+return false;
+}
+}
+}
+return true;
+}
+
 static const CudaCommand handlers[] = {
 { CUDA_AUTOPOLL, "AUTOPOLL", cuda_cmd_autopoll },
 { CUDA_SET_AUTO_RATE, "SET_AUTO_RATE",  cuda_cmd_set_autorate },
@@ -381,6 +440,8 @@ static const CudaCommand handlers[] = {
   cuda_cmd_set_power_message },
 { CUDA_GET_TIME, "GET_TIME", cuda_cmd_get_time },
 { CUDA_SET_TIME, "SET_TIME", cuda_cmd_set_time },
+{ CUDA_GET_SET_IIC, "GET_SET_IIC", cuda_cmd_get_set_iic },
+{ CUDA_COMBINED_FORMAT_IIC, "COMBINED_FORMAT_IIC", cuda_cmd_combined_iic },
 };
 
 static void cuda_receive_packet(CUDAState *s,
@@ -548,6 +609,7 @@ static void cuda_init(Object *obj)
 {
 CUDAState *s = CUDA(obj);
 SysBusDevice *sbd = SYS_BUS_DEVICE(obj);
+DeviceState *dev = DEVICE(obj);
 
 sysbus_init_child_obj(obj, "mos6522-cuda", &s->mos6522_cuda,
   sizeof(s->mos6522_cuda), TYPE_MOS6522_CUDA);
@@ -556,7 +618,8 @@ static void cuda_init(Object *obj)
 sysbus_init_mmio(sbd, &s->mem);
 
 qbus_create_inplace(&s->adb_bus, sizeof(s->adb_bus), TYPE_ADB_BUS,
-DEVICE(obj), "adb.0");
+dev, "adb.0");
+s->i2c_bus = i2c_init_bus(dev, "i2c");
 }
 
 static Property cuda_properties[] = {
diff --git a/include/hw/misc/macio/cuda.h b/include/hw/misc/macio/cuda.h
index 5768075ac5..0c798100dc 100644
--- a/include/hw/misc/macio/cuda.h
+++ b/include/hw/misc/macio/cuda.h
@@ -79,6 +79,7 @@ typedef struct CUDAState {
 
 ADBBusState adb_bus;
 MOS6522CUDAState mos6522_cuda;
+I2CBus *i2c_bus;
 
 uint32_t tick_offset;
 uint64_t tb_frequency;
-- 
2.21.3

[PATCH v4 2/9] mac_newworld: Allow loading binary ROM image

Fall back to load binary ROM image if loading ELF fails. This also
moves PROM_BASE and PROM_SIZE defines to board as these are matching
the ROM size and address on this board.

Signed-off-by: BALATON Zoltan 
---
Notes:
Unlike mac_oldworld where the openbios-ppc image loads at end of ROM
region here we only check size and assume ELF image is loaded from
PROM_BASE, Checking the load addr here is tricky because this board is
also be compiled both 64 and 32 bit and load_elf seems to always
return 64 bit value so handling that could become a mess. If this is a
problem then it's a preexisting one so should be fixed in a separate
patch. This one just allows loading ROM binary too otherwise
preserving previous behaviour.

 hw/ppc/mac.h  |  2 --
 hw/ppc/mac_newworld.c | 22 ++
 2 files changed, 14 insertions(+), 10 deletions(-)

diff --git a/hw/ppc/mac.h b/hw/ppc/mac.h
index 6af87d1fa0..a0d9e47031 100644
--- a/hw/ppc/mac.h
+++ b/hw/ppc/mac.h
@@ -38,10 +38,8 @@
 /* SMP is not enabled, for now */
 #define MAX_CPUS 1
 
-#define BIOS_SIZE(1 * MiB)
 #define NVRAM_SIZE0x2000
 #define PROM_FILENAME"openbios-ppc"
-#define PROM_ADDR 0xfff0
 
 #define KERNEL_LOAD_ADDR 0x0100
 #define KERNEL_GAP   0x0010
diff --git a/hw/ppc/mac_newworld.c b/hw/ppc/mac_newworld.c
index 3507f26f6e..5c8a625276 100644
--- a/hw/ppc/mac_newworld.c
+++ b/hw/ppc/mac_newworld.c
@@ -82,6 +82,8 @@
 
 #define NDRV_VGA_FILENAME "qemu_vga.ndrv"
 
+#define PROM_BASE 0xfff0
+#define PROM_SIZE (1 * MiB)
 
 static void fw_cfg_boot_set(void *opaque, const char *boot_device,
 Error **errp)
@@ -100,7 +102,7 @@ static void ppc_core99_reset(void *opaque)
 
 cpu_reset(CPU(cpu));
 /* 970 CPUs want to get their initial IP as part of their boot protocol */
-cpu->env.nip = PROM_ADDR + 0x100;
+cpu->env.nip = PROM_BASE + 0x100;
 }
 
 /* PowerPC Mac99 hardware initialisation */
@@ -153,25 +155,29 @@ static void ppc_core99_init(MachineState *machine)
 /* allocate RAM */
 memory_region_add_subregion(get_system_memory(), 0, machine->ram);
 
-/* allocate and load BIOS */
-memory_region_init_rom(bios, NULL, "ppc_core99.bios", BIOS_SIZE,
+/* allocate and load firmware ROM */
+memory_region_init_rom(bios, NULL, "ppc_core99.bios", PROM_SIZE,
&error_fatal);
+memory_region_add_subregion(get_system_memory(), PROM_BASE, bios);
 
-if (bios_name == NULL)
+if (!bios_name) {
 bios_name = PROM_FILENAME;
+}
 filename = qemu_find_file(QEMU_FILE_TYPE_BIOS, bios_name);
-memory_region_add_subregion(get_system_memory(), PROM_ADDR, bios);
-
-/* Load OpenBIOS (ELF) */
 if (filename) {
+/* Load OpenBIOS (ELF) */
 bios_size = load_elf(filename, NULL, NULL, NULL, NULL,
  NULL, NULL, NULL, 1, PPC_ELF_MACHINE, 0, 0);
 
+if (bios_size <= 0) {
+/* or load binary ROM image */
+bios_size = load_image_targphys(filename, PROM_BASE, PROM_SIZE);
+}
 g_free(filename);
 } else {
 bios_size = -1;
 }
-if (bios_size < 0 || bios_size > BIOS_SIZE) {
+if (bios_size < 0 || bios_size > PROM_SIZE) {
 error_report("could not load PowerPC bios '%s'", bios_name);
 exit(1);
 }
-- 
2.21.3

[PATCH v4 4/9] mac_oldworld: Rename ppc_heathrow_reset to ppc_heathrow_cpu_reset

This function resets a CPU not the whole machine so reflect that in
its name.

Signed-off-by: BALATON Zoltan 
Reviewed-by: Philippe Mathieu-Daudé 
---
 hw/ppc/mac_oldworld.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/hw/ppc/mac_oldworld.c b/hw/ppc/mac_oldworld.c
index 33421c28c4..2afdef55aa 100644
--- a/hw/ppc/mac_oldworld.c
+++ b/hw/ppc/mac_oldworld.c
@@ -73,7 +73,7 @@ static uint64_t translate_kernel_address(void *opaque, 
uint64_t addr)
 return (addr & 0x0fff) + KERNEL_LOAD_ADDR;
 }
 
-static void ppc_heathrow_reset(void *opaque)
+static void ppc_heathrow_cpu_reset(void *opaque)
 {
 PowerPCCPU *cpu = opaque;
 
@@ -118,7 +118,7 @@ static void ppc_heathrow_init(MachineState *machine)
 
 /* Set time-base frequency to 16.6 Mhz */
 cpu_ppc_tb_init(env,  TBFREQ);
-qemu_register_reset(ppc_heathrow_reset, cpu);
+qemu_register_reset(ppc_heathrow_cpu_reset, cpu);
 }
 
 /* allocate RAM */
-- 
2.21.3

[PATCH v4 5/9] mac_oldworld: Map macio to expected address at reset

Add a reset function that maps macio to the address expected by the
firmware of the board at startup.

Signed-off-by: BALATON Zoltan 
---
 hw/ppc/mac.h  | 12 
 hw/ppc/mac_oldworld.c | 17 +++--
 2 files changed, 27 insertions(+), 2 deletions(-)

diff --git a/hw/ppc/mac.h b/hw/ppc/mac.h
index a0d9e47031..e04288ddfd 100644
--- a/hw/ppc/mac.h
+++ b/hw/ppc/mac.h
@@ -55,6 +55,18 @@
 #define OLDWORLD_IDE1_IRQ  0xe
 #define OLDWORLD_IDE1_DMA_IRQ  0x3
 
+/* g3beige machine */
+#define TYPE_HEATHROW_MACHINE MACHINE_TYPE_NAME("g3beige")
+#define HEATHROW_MACHINE(obj) OBJECT_CHECK(HeathrowMachineState, (obj), \
+   TYPE_HEATHROW_MACHINE)
+
+typedef struct HeathrowMachineState {
+/*< private >*/
+MachineState parent;
+
+PCIDevice *macio_pci;
+} HeathrowMachineState;
+
 /* New World IRQs */
 #define NEWWORLD_CUDA_IRQ  0x19
 #define NEWWORLD_PMU_IRQ   0x19
diff --git a/hw/ppc/mac_oldworld.c b/hw/ppc/mac_oldworld.c
index 2afdef55aa..cb4a0f3211 100644
--- a/hw/ppc/mac_oldworld.c
+++ b/hw/ppc/mac_oldworld.c
@@ -73,6 +73,15 @@ static uint64_t translate_kernel_address(void *opaque, 
uint64_t addr)
 return (addr & 0x0fff) + KERNEL_LOAD_ADDR;
 }
 
+static void ppc_heathrow_reset(MachineState *machine)
+{
+HeathrowMachineState *m = HEATHROW_MACHINE(machine);
+
+qemu_devices_reset();
+pci_default_write_config(m->macio_pci, PCI_COMMAND, PCI_COMMAND_MEMORY, 2);
+pci_default_write_config(m->macio_pci, PCI_BASE_ADDRESS_0, 0xf300, 4);
+}
+
 static void ppc_heathrow_cpu_reset(void *opaque)
 {
 PowerPCCPU *cpu = opaque;
@@ -82,6 +91,7 @@ static void ppc_heathrow_cpu_reset(void *opaque)
 
 static void ppc_heathrow_init(MachineState *machine)
 {
+HeathrowMachineState *hm = HEATHROW_MACHINE(machine);
 ram_addr_t ram_size = machine->ram_size;
 const char *kernel_filename = machine->kernel_filename;
 const char *kernel_cmdline = machine->kernel_cmdline;
@@ -289,7 +299,8 @@ static void ppc_heathrow_init(MachineState *machine)
 ide_drive_get(hd, ARRAY_SIZE(hd));
 
 /* MacIO */
-macio = OLDWORLD_MACIO(pci_create(pci_bus, -1, TYPE_OLDWORLD_MACIO));
+hm->macio_pci = pci_create(pci_bus, -1, TYPE_OLDWORLD_MACIO);
+macio = OLDWORLD_MACIO(hm->macio_pci);
 dev = DEVICE(macio);
 qdev_prop_set_uint64(dev, "frequency", tbfreq);
 object_property_set_link(OBJECT(macio), OBJECT(pic_dev), "pic",
@@ -441,6 +452,7 @@ static void heathrow_class_init(ObjectClass *oc, void *data)
 
 mc->desc = "Heathrow based PowerMAC";
 mc->init = ppc_heathrow_init;
+mc->reset = ppc_heathrow_reset;
 mc->block_default_type = IF_IDE;
 mc->max_cpus = MAX_CPUS;
 #ifndef TARGET_PPC64
@@ -457,9 +469,10 @@ static void heathrow_class_init(ObjectClass *oc, void 
*data)
 }
 
 static const TypeInfo ppc_heathrow_machine_info = {
-.name  = MACHINE_TYPE_NAME("g3beige"),
+.name  = TYPE_HEATHROW_MACHINE,
 .parent= TYPE_MACHINE,
 .class_init= heathrow_class_init,
+.instance_size = sizeof(HeathrowMachineState),
 .interfaces = (InterfaceInfo[]) {
 { TYPE_FW_PATH_PROVIDER },
 { }
-- 
2.21.3

[PATCH v4 0/9] Mac Old World ROM experiment

Last version with some changes according to review and adding more
patches. The patch adding i2c support to CUDA is not yet working, only
included here as RFC and show direction but any help fixing it is
welcome as I've run out of free time for this. I think with i2c
support fixed (and maybe adding real screamer implementation) could
get us somewhere with the firmware ROM. Once it starts poking a video
card I'm willing to look at what ati-vga may need to work with this
but help is welcome getting to that point.

Regards,
BALATON Zoltan

BALATON Zoltan (9):
  mac_oldworld: Allow loading binary ROM image
  mac_newworld: Allow loading binary ROM image
  grackle: Set revision in PCI config to match hardware
  mac_oldworld: Rename ppc_heathrow_reset to ppc_heathrow_cpu_reset
  mac_oldworld: Map macio to expected address at reset
  mac_oldworld: Add machine ID register
  macio: Add dummy screamer register area
  WIP macio/cuda: Attempt to add i2c support
  mac_oldworld: Add SPD data to cover RAM

 hw/misc/macio/cuda.c | 65 -
 hw/misc/macio/macio.c| 34 +
 hw/pci-host/grackle.c|  2 +-
 hw/ppc/mac.h | 15 +-
 hw/ppc/mac_newworld.c| 22 +
 hw/ppc/mac_oldworld.c| 93 ++--
 include/hw/misc/macio/cuda.h |  1 +
 7 files changed, 206 insertions(+), 26 deletions(-)

-- 
2.21.3

[PATCH v4 9/9] mac_oldworld: Add SPD data to cover RAM

OpenBIOS gets RAM size via fw_cfg but rhe original board firmware
detects RAM using SPD data so generate and add SDP eeproms to cover as
much RAM as possible to describe with SPD (this may be less than the
actual ram_size due to SDRAM size constraints).

Signed-off-by: BALATON Zoltan 
---
 hw/ppc/mac_oldworld.c | 19 ++-
 1 file changed, 18 insertions(+), 1 deletion(-)

diff --git a/hw/ppc/mac_oldworld.c b/hw/ppc/mac_oldworld.c
index 53615af6b1..1f85859034 100644
--- a/hw/ppc/mac_oldworld.c
+++ b/hw/ppc/mac_oldworld.c
@@ -34,6 +34,7 @@
 #include "hw/input/adb.h"
 #include "sysemu/sysemu.h"
 #include "net/net.h"
+#include "hw/i2c/smbus_eeprom.h"
 #include "hw/isa/isa.h"
 #include "hw/pci/pci.h"
 #include "hw/pci/pci_host.h"
@@ -137,6 +138,8 @@ static void ppc_heathrow_init(MachineState *machine)
 DriveInfo *hd[MAX_IDE_BUS * MAX_IDE_DEVS];
 void *fw_cfg;
 uint64_t tbfreq;
+uint8_t *spd_data[3] = {};
+I2CBus *i2c_bus;
 
 linux_boot = (kernel_filename != NULL);
 
@@ -156,8 +159,16 @@ static void ppc_heathrow_init(MachineState *machine)
  "maximum 2047 MB", ram_size / MiB);
 exit(1);
 }
-
 memory_region_add_subregion(sysmem, 0, machine->ram);
+for (i = 0; i < 3; i++) {
+int size_left = ram_size - i * 512 * MiB;
+if (size_left > 0) {
+uint32_t s = size_left / MiB;
+s = (s > 512 ? 512 : s);
+s = 1U << (31 - clz32(s));
+spd_data[i] = spd_data_generate(SDR, s * MiB);
+}
+}
 
 /* allocate and load firmware ROM */
 memory_region_init_rom(bios, NULL, "ppc_heathrow.bios", PROM_SIZE,
@@ -340,6 +351,12 @@ static void ppc_heathrow_init(MachineState *machine)
 macio_ide_init_drives(macio_ide, &hd[MAX_IDE_DEVS]);
 
 dev = DEVICE(object_resolve_path_component(OBJECT(macio), "cuda"));
+i2c_bus = I2C_BUS(qdev_get_child_bus(dev, "i2c"));
+for (i = 0; i < 3; i++) {
+if (spd_data[i]) {
+smbus_eeprom_init_one(i2c_bus, 0x50 + i, spd_data[i]);
+}
+}
 adb_bus = qdev_get_child_bus(dev, "adb.0");
 dev = qdev_create(adb_bus, TYPE_ADB_KEYBOARD);
 qdev_init_nofail(dev);
-- 
2.21.3

[PATCH v4 1/9] mac_oldworld: Allow loading binary ROM image

The beige G3 Power Macintosh has a 4MB firmware ROM. Fix the size of
the rom region and fall back to loading a binary image with -bios if
loading ELF image failed. This allows testing emulation with a ROM
image from real hardware as well as using an ELF OpenBIOS image.

Signed-off-by: BALATON Zoltan 
---
v4: use load address from ELF to check if ROM is too big

 hw/ppc/mac_oldworld.c | 29 -
 1 file changed, 20 insertions(+), 9 deletions(-)

diff --git a/hw/ppc/mac_oldworld.c b/hw/ppc/mac_oldworld.c
index 0b4c1c6373..33421c28c4 100644
--- a/hw/ppc/mac_oldworld.c
+++ b/hw/ppc/mac_oldworld.c
@@ -59,6 +59,8 @@
 #define NDRV_VGA_FILENAME "qemu_vga.ndrv"
 
 #define GRACKLE_BASE 0xfec0
+#define PROM_BASE 0xffc0
+#define PROM_SIZE (4 * MiB)
 
 static void fw_cfg_boot_set(void *opaque, const char *boot_device,
 Error **errp)
@@ -99,6 +101,7 @@ static void ppc_heathrow_init(MachineState *machine)
 SysBusDevice *s;
 DeviceState *dev, *pic_dev;
 BusState *adb_bus;
+uint64_t bios_addr;
 int bios_size;
 unsigned int smp_cpus = machine->smp.cpus;
 uint16_t ppc_boot_device;
@@ -127,24 +130,32 @@ static void ppc_heathrow_init(MachineState *machine)
 
 memory_region_add_subregion(sysmem, 0, machine->ram);
 
-/* allocate and load BIOS */
-memory_region_init_rom(bios, NULL, "ppc_heathrow.bios", BIOS_SIZE,
+/* allocate and load firmware ROM */
+memory_region_init_rom(bios, NULL, "ppc_heathrow.bios", PROM_SIZE,
&error_fatal);
+memory_region_add_subregion(sysmem, PROM_BASE, bios);
 
-if (bios_name == NULL)
+if (!bios_name) {
 bios_name = PROM_FILENAME;
+}
 filename = qemu_find_file(QEMU_FILE_TYPE_BIOS, bios_name);
-memory_region_add_subregion(sysmem, PROM_ADDR, bios);
-
-/* Load OpenBIOS (ELF) */
 if (filename) {
-bios_size = load_elf(filename, NULL, 0, NULL, NULL, NULL, NULL, NULL,
- 1, PPC_ELF_MACHINE, 0, 0);
+/* Load OpenBIOS (ELF) */
+bios_size = load_elf(filename, NULL, NULL, NULL, NULL, &bios_addr,
+ NULL, NULL, 1, PPC_ELF_MACHINE, 0, 0);
+if (bios_size <= 0) {
+/* or load binary ROM image */
+bios_size = load_image_targphys(filename, PROM_BASE, PROM_SIZE);
+bios_addr = PROM_BASE;
+} else {
+/* load_elf sets high 32 bits for some reason, strip those */
+bios_addr &= 0xULL;
+}
 g_free(filename);
 } else {
 bios_size = -1;
 }
-if (bios_size < 0 || bios_size > BIOS_SIZE) {
+if (bios_size < 0 || bios_addr - PROM_BASE + bios_size > PROM_SIZE) {
 error_report("could not load PowerPC bios '%s'", bios_name);
 exit(1);
 }
-- 
2.21.3

[PATCH v4 6/9] mac_oldworld: Add machine ID register

The G3 beige machine has a machine ID register that is accessed by the
firmware to deternine the board config. Add basic emulation of it.

Signed-off-by: BALATON Zoltan 
---
v4: Move MermoryRegion to MachineState, use constants

 hw/ppc/mac.h  |  1 +
 hw/ppc/mac_oldworld.c | 24 
 2 files changed, 25 insertions(+)

diff --git a/hw/ppc/mac.h b/hw/ppc/mac.h
index e04288ddfd..f4e1d5c758 100644
--- a/hw/ppc/mac.h
+++ b/hw/ppc/mac.h
@@ -64,6 +64,7 @@ typedef struct HeathrowMachineState {
 /*< private >*/
 MachineState parent;
 
+MemoryRegion machine_id;
 PCIDevice *macio_pci;
 } HeathrowMachineState;
 
diff --git a/hw/ppc/mac_oldworld.c b/hw/ppc/mac_oldworld.c
index cb4a0f3211..53615af6b1 100644
--- a/hw/ppc/mac_oldworld.c
+++ b/hw/ppc/mac_oldworld.c
@@ -52,6 +52,9 @@
 
 #define MAX_IDE_BUS 2
 #define CFG_ADDR 0xf510
+#define MACHINE_ID_ADDR 0xff04
+#define MACHINE_ID_VAL 0x3d8c
+
 #define TBFREQ 1660UL
 #define CLOCKFREQ 26600UL
 #define BUSFREQ 6600UL
@@ -89,6 +92,22 @@ static void ppc_heathrow_cpu_reset(void *opaque)
 cpu_reset(CPU(cpu));
 }
 
+static uint64_t machine_id_read(void *opaque, hwaddr addr, unsigned size)
+{
+return (addr == 0 && size == 2 ? MACHINE_ID_VAL : 0);
+}
+
+static void machine_id_write(void *opaque, hwaddr addr,
+ uint64_t val, unsigned size)
+{
+return;
+}
+
+const MemoryRegionOps machine_id_reg_ops = {
+.read = machine_id_read,
+.write = machine_id_write,
+};
+
 static void ppc_heathrow_init(MachineState *machine)
 {
 HeathrowMachineState *hm = HEATHROW_MACHINE(machine);
@@ -242,6 +261,11 @@ static void ppc_heathrow_init(MachineState *machine)
 }
 }
 
+memory_region_init_io(&hm->machine_id, OBJECT(machine),
+  &machine_id_reg_ops, NULL, "machine_id", 2);
+memory_region_add_subregion(get_system_memory(), MACHINE_ID_ADDR,
+&hm->machine_id);
+
 /* XXX: we register only 1 output pin for heathrow PIC */
 pic_dev = qdev_create(NULL, TYPE_HEATHROW);
 qdev_init_nofail(pic_dev);
-- 
2.21.3

[PATCH v4 7/9] macio: Add dummy screamer register area

The only thing this returns is an idle status so the firmware
continues, otherwise just ignores and logs access for debugging. This
is a stop gap until proper implementation of this device lands.

Signed-off-by: BALATON Zoltan 
---
This could be reverted as the first patch of a series adding real
implementation so it should not cause much trouble. Or in case it's
found that firmware continues once SPD data is available this patch
may not be needed.

 hw/misc/macio/macio.c | 34 ++
 1 file changed, 34 insertions(+)

diff --git a/hw/misc/macio/macio.c b/hw/misc/macio/macio.c
index 3779865ab2..dbc3df9ab1 100644
--- a/hw/misc/macio/macio.c
+++ b/hw/misc/macio/macio.c
@@ -26,6 +26,7 @@
 #include "qemu/osdep.h"
 #include "qapi/error.h"
 #include "qemu/module.h"
+#include "qemu/log.h"
 #include "hw/ppc/mac.h"
 #include "hw/misc/macio/cuda.h"
 #include "hw/pci/pci.h"
@@ -103,6 +104,33 @@ static void macio_init_child_obj(MacIOState *s, const char 
*childname,
 qdev_set_parent_bus(DEVICE(child), BUS(&s->macio_bus));
 }
 
+#define AWAC_CODEC_STATUS_REG 0x20
+
+#define AWAC_MAKER_CRYSTAL 1
+#define AWAC_REV_SCREAMER 3
+#define AWAC_VALID_DATA 0x40
+
+static uint64_t screamer_read(void *opaque, hwaddr addr, unsigned size)
+{
+qemu_log_mask(LOG_UNIMP,
+  "macio: screamer read %" HWADDR_PRIx "  %d\n", addr, size);
+return (addr == AWAC_CODEC_STATUS_REG ? AWAC_VALID_DATA << 8 |
+AWAC_MAKER_CRYSTAL << 16 | AWAC_REV_SCREAMER << 20 : 0);
+}
+
+static void screamer_write(void *opaque, hwaddr addr,
+   uint64_t val, unsigned size)
+{
+qemu_log_mask(LOG_UNIMP,
+  "macio: screamer write %" HWADDR_PRIx "  %d = %"PRIx64"\n",
+  addr, size, val);
+}
+
+const MemoryRegionOps screamer_ops = {
+.read = screamer_read,
+.write = screamer_write,
+};
+
 static void macio_common_realize(PCIDevice *d, Error **errp)
 {
 MacIOState *s = MACIO(d);
@@ -158,6 +186,7 @@ static void macio_oldworld_realize(PCIDevice *d, Error 
**errp)
 DeviceState *pic_dev = DEVICE(os->pic);
 Error *err = NULL;
 SysBusDevice *sysbus_dev;
+MemoryRegion *screamer = g_new(MemoryRegion, 1);
 
 macio_common_realize(d, &err);
 if (err) {
@@ -217,6 +246,11 @@ static void macio_oldworld_realize(PCIDevice *d, Error 
**errp)
 error_propagate(errp, err);
 return;
 }
+
+/* Dummy screamer sound device */
+memory_region_init_io(screamer, OBJECT(d), &screamer_ops, NULL,
+  "screamer", 0x2000);
+memory_region_add_subregion(&s->bar, 0x14000, screamer);
 }
 
 static void macio_init_ide(MacIOState *s, MACIOIDEState *ide, size_t ide_size,
-- 
2.21.3

Re: [PATCH 21/22] adb: use adb_device prefix for ADB device trace events

On 6/14/20 4:28 PM, Mark Cave-Ayland wrote:
> This is to allow us to distinguish between ADB device events and ADB
> bus events separately.
> 
> Signed-off-by: Mark Cave-Ayland 
> ---
>  hw/input/adb-kbd.c| 12 ++--
>  hw/input/adb-mouse.c  | 12 ++--
>  hw/input/trace-events | 20 ++--
>  3 files changed, 22 insertions(+), 22 deletions(-)
> 
> diff --git a/hw/input/adb-kbd.c b/hw/input/adb-kbd.c
> index 23760ecf7b..3cfb6a7a20 100644
> --- a/hw/input/adb-kbd.c
> +++ b/hw/input/adb-kbd.c
> @@ -243,7 +243,7 @@ static int adb_kbd_request(ADBDevice *d, uint8_t *obuf,
>  olen = 0;
>  switch (cmd) {
>  case ADB_WRITEREG:
> -trace_adb_kbd_writereg(reg, buf[1]);
> +trace_adb_device_kbd_writereg(reg, buf[1]);
>  switch (reg) {
>  case 2:
>  /* LED status */
> @@ -256,7 +256,7 @@ static int adb_kbd_request(ADBDevice *d, uint8_t *obuf,
>  case ADB_CMD_CHANGE_ID_AND_ACT:
>  case ADB_CMD_CHANGE_ID_AND_ENABLE:
>  d->devaddr = buf[1] & 0xf;
> -trace_adb_kbd_request_change_addr(d->devaddr);
> +trace_adb_device_kbd_request_change_addr(d->devaddr);
>  break;
>  default:
>  d->devaddr = buf[1] & 0xf;
> @@ -270,8 +270,8 @@ static int adb_kbd_request(ADBDevice *d, uint8_t *obuf,
>  d->handler = buf[2];
>  }
>  
> -trace_adb_kbd_request_change_addr_and_handler(d->devaddr,
> -  d->handler);
> +trace_adb_device_kbd_request_change_addr_and_handler(
> +d->devaddr, d->handler);
>  break;
>  }
>  }
> @@ -294,7 +294,7 @@ static int adb_kbd_request(ADBDevice *d, uint8_t *obuf,
>  olen = 2;
>  break;
>  }
> -trace_adb_kbd_readreg(reg, obuf[0], obuf[1]);
> +trace_adb_device_kbd_readreg(reg, obuf[0], obuf[1]);
>  break;
>  }
>  return olen;
> @@ -321,7 +321,7 @@ static void adb_keyboard_event(DeviceState *dev, 
> QemuConsole *src,
>  /* FIXME: take handler into account when translating qcode */
>  keycode = qcode_to_adb_keycode[qcode];
>  if (keycode == NO_KEY) {  /* We don't want to send this to the guest */
> -trace_adb_kbd_no_key();
> +trace_adb_device_kbd_no_key();
>  return;
>  }
>  if (evt->u.key.data->down == false) { /* if key release event */
> diff --git a/hw/input/adb-mouse.c b/hw/input/adb-mouse.c
> index e2359fd74d..577a38ff2e 100644
> --- a/hw/input/adb-mouse.c
> +++ b/hw/input/adb-mouse.c
> @@ -121,7 +121,7 @@ static int adb_mouse_request(ADBDevice *d, uint8_t *obuf,
>  s->dx = 0;
>  s->dy = 0;
>  s->dz = 0;
> -trace_adb_mouse_flush();
> +trace_adb_device_mouse_flush();
>  return 0;
>  }
>  
> @@ -130,7 +130,7 @@ static int adb_mouse_request(ADBDevice *d, uint8_t *obuf,
>  olen = 0;
>  switch (cmd) {
>  case ADB_WRITEREG:
> -trace_adb_mouse_writereg(reg, buf[1]);
> +trace_adb_device_mouse_writereg(reg, buf[1]);
>  switch (reg) {
>  case 2:
>  break;
> @@ -152,7 +152,7 @@ static int adb_mouse_request(ADBDevice *d, uint8_t *obuf,
>  case ADB_CMD_CHANGE_ID_AND_ACT:
>  case ADB_CMD_CHANGE_ID_AND_ENABLE:
>  d->devaddr = buf[1] & 0xf;
> -trace_adb_mouse_request_change_addr(d->devaddr);
> +trace_adb_device_mouse_request_change_addr(d->devaddr);
>  break;
>  default:
>  d->devaddr = buf[1] & 0xf;
> @@ -172,8 +172,8 @@ static int adb_mouse_request(ADBDevice *d, uint8_t *obuf,
>  d->handler = buf[2];
>  }
>  
> -trace_adb_mouse_request_change_addr_and_handler(d->devaddr,
> -d->handler);
> +trace_adb_device_mouse_request_change_addr_and_handler(
> +d->devaddr, d->handler);
>  break;
>  }
>  }
> @@ -191,7 +191,7 @@ static int adb_mouse_request(ADBDevice *d, uint8_t *obuf,
>  olen = 2;
>  break;
>  }
> -trace_adb_mouse_readreg(reg, obuf[0], obuf[1]);
> +trace_adb_device_mouse_readreg(reg, obuf[0], obuf[1]);
>  break;
>  }
>  return olen;
> diff --git a/hw/input/trace-events b/hw/input/trace-events
> index a2888fd10c..6f0d78241c 100644
> --- a/hw/input/trace-events
> +++ b/hw/input/trace-events
> @@ -1,18 +1,18 @@
>  # See docs/devel/tracing.txt for syntax documentation.
>  
>  # adb-kbd.c
> -adb_kbd_no_key(void) "Ignoring NO_KEY"
> -adb_kbd_writereg(int reg, uint8_t val) "reg %d val 0x%2.2x"
> -adb_kbd_readreg(int reg, uint8_t val0, uint8_t val1) "reg %d obuf[0] 0x%2.2x 
> obuf[1] 0

Re: [PATCH 22/22] adb: add ADB bus trace events

Hi Mark,

On 6/14/20 4:28 PM, Mark Cave-Ayland wrote:
> Signed-off-by: Mark Cave-Ayland 
> ---
>  hw/input/adb.c| 23 ++-
>  hw/input/trace-events |  7 +++
>  2 files changed, 29 insertions(+), 1 deletion(-)
> 
> diff --git a/hw/input/adb.c b/hw/input/adb.c
> index fe0f6c7ef3..4976f52c36 100644
> --- a/hw/input/adb.c
> +++ b/hw/input/adb.c
> @@ -29,10 +29,18 @@
>  #include "qemu/module.h"
>  #include "qemu/timer.h"
>  #include "adb-internal.h"
> +#include "trace.h"
>  
>  /* error codes */
>  #define ADB_RET_NOTPRESENT (-2)
>  
> +static const char *adb_commands[] = {
> +"RESET", "FLUSH", "(Reserved 0x2)", "(Reserved 0x3)",
> +"Reserved (0x4)", "(Reserved 0x5)", "(Reserved 0x6)", "(Reserved 0x7)",
> +"LISTEN r0", "LISTEN r1", "LISTEN r2", "LISTEN r3",
> +"TALK r0", "TALK r1", "TALK r2", "TALK r3",
> +};
> +
>  static void adb_device_reset(ADBDevice *d)
>  {
>  qdev_reset_all(DEVICE(d));
> @@ -86,9 +94,16 @@ static int do_adb_request(ADBBusState *s, uint8_t *obuf, 
> const uint8_t *buf,
>  
>  int adb_request(ADBBusState *s, uint8_t *obuf, const uint8_t *buf, int len)
>  {
> +int ret;
> +
> +trace_adb_bus_request(buf[0] >> 4, adb_commands[buf[0] & 0xf], len);
> +
>  assert(s->autopoll_blocked);
>  
> -return do_adb_request(s, obuf, buf, len);
> +ret = do_adb_request(s, obuf, buf, len);
> +
> +trace_adb_bus_request_done(buf[0] >> 4, adb_commands[buf[0] & 0xf], ret);
> +return ret;
>  }
>  
>  int adb_poll(ADBBusState *s, uint8_t *obuf, uint16_t poll_mask)
> @@ -160,6 +175,8 @@ void adb_set_autopoll_mask(ADBBusState *s, uint16_t mask)
>  
>  void adb_autopoll_block(ADBBusState *s)
>  {
> +trace_adb_bus_autopoll_block("autopoll BLOCKED");

Regarding how trace backends work, in this case it is better
to use a boolean value and let the backend do the formatting:

   trace_adb_bus_autopoll_block(true);

The rationale is it is easier for backends to filter on a
bool (register) arg rather than fetching memory for strcmp.

So format can be:

adb_bus_autopoll_block(bool state) "autopoll is_blocked:%u"

Anyway if you want to keep as it, it is cleaner to change the
format as "autopoll %s".

> +
>  s->autopoll_blocked = true;

This can also be:

   trace_adb_bus_autopoll_block(s->autopoll_blocked);

>  
>  if (s->autopoll_enabled) {
> @@ -169,6 +186,8 @@ void adb_autopoll_block(ADBBusState *s)
>  
>  void adb_autopoll_unblock(ADBBusState *s)
>  {
> +trace_adb_bus_autopoll_block("autopoll UNBLOCKED");
> +
>  s->autopoll_blocked = false;

Ditto:

   trace_adb_bus_autopoll_block(s->autopoll_blocked);

>  
>  if (s->autopoll_enabled) {
> @@ -183,7 +202,9 @@ static void adb_autopoll(void *opaque)
>  ADBBusState *s = opaque;
>  
>  if (!s->autopoll_blocked) {
> +trace_adb_bus_autopoll_cb(s->autopoll_mask);
>  s->autopoll_cb(s->autopoll_cb_opaque);
> +trace_adb_bus_autopoll_cb_done(s->autopoll_mask);
>  }
>  
>  timer_mod(s->autopoll_timer,
> diff --git a/hw/input/trace-events b/hw/input/trace-events
> index 6f0d78241c..119d1ce2bd 100644
> --- a/hw/input/trace-events
> +++ b/hw/input/trace-events
> @@ -14,6 +14,13 @@ adb_device_mouse_readreg(int reg, uint8_t val0, uint8_t 
> val1) "reg %d obuf[0] 0x
>  adb_device_mouse_request_change_addr(int devaddr) "change addr to 0x%x"
>  adb_device_mouse_request_change_addr_and_handler(int devaddr, int handler) 
> "change addr and handler to 0x%x, 0x%x"
>  
> +# adb.c
> +adb_bus_request(uint8_t addr, const char *cmd, int size) "device 0x%x %s 
> cmdsize=%d"
> +adb_bus_request_done(uint8_t addr, const char *cmd, int size) "device 0x%x 
> %s replysize=%d"
> +adb_bus_autopoll_block(const char *s) "%s"
> +adb_bus_autopoll_cb(uint16_t mask) "executing autopoll_cb with autopoll mask 
> 0x%x"
> +adb_bus_autopoll_cb_done(uint16_t mask) "done executing autopoll_cb with 
> autopoll mask 0x%x"
> +
>  # pckbd.c
>  pckbd_kbd_read_data(uint32_t val) "0x%02x"
>  pckbd_kbd_read_status(int status) "0x%02x"
> 

Reviewed-by: Philippe Mathieu-Daudé

Re: [PATCH 18/22] mac_via: move VIA1 portB write logic into mos6522_q800_via1_write()

On 6/14/20 4:28 PM, Mark Cave-Ayland wrote:
> Currently the logic is split between the mos6522 portB_write() callback and
> the memory region used to capture the VIA1 MMIO accesses. Move everything
> into the latter mos6522_q800_via1_write() function to keep all the logic in
> one place to make it easier to follow.
> 
> Signed-off-by: Mark Cave-Ayland 
> ---
>  hw/misc/mac_via.c | 24 ++--
>  1 file changed, 10 insertions(+), 14 deletions(-)
> 
> diff --git a/hw/misc/mac_via.c b/hw/misc/mac_via.c
> index 669fdca4c4..4779236f95 100644
> --- a/hw/misc/mac_via.c
> +++ b/hw/misc/mac_via.c
> @@ -801,11 +801,21 @@ static void mos6522_q800_via1_write(void *opaque, 
> hwaddr addr, uint64_t val,
>  unsigned size)
>  {
>  MOS6522Q800VIA1State *v1s = MOS6522_Q800_VIA1(opaque);
> +MacVIAState *m = container_of(v1s, MacVIAState, mos6522_via1);

Reviewed-by: Philippe Mathieu-Daudé 

>  MOS6522State *ms = MOS6522(v1s);
>  
>  addr = (addr >> 9) & 0xf;
>  mos6522_write(ms, addr, val, size);
>  
> +switch (addr) {
> +case VIA_REG_B:
> +via1_rtc_update(m);
> +via1_adb_update(m);
> +
> +v1s->last_b = ms->b;
> +break;
> +}
> +
>  via1_one_second_update(v1s);
>  via1_VBL_update(v1s);
>  }
> @@ -1034,18 +1044,6 @@ static TypeInfo mac_via_info = {
>  };
>  
>  /* VIA 1 */
> -static void mos6522_q800_via1_portB_write(MOS6522State *s)
> -{
> -MOS6522Q800VIA1State *v1s = container_of(s, MOS6522Q800VIA1State,
> - parent_obj);
> -MacVIAState *m = container_of(v1s, MacVIAState, mos6522_via1);
> -
> -via1_rtc_update(m);
> -via1_adb_update(m);
> -
> -v1s->last_b = s->b;
> -}
> -
>  static void mos6522_q800_via1_reset(DeviceState *dev)
>  {
>  MOS6522State *ms = MOS6522(dev);
> @@ -1068,10 +1066,8 @@ static void mos6522_q800_via1_init(Object *obj)
>  static void mos6522_q800_via1_class_init(ObjectClass *oc, void *data)
>  {
>  DeviceClass *dc = DEVICE_CLASS(oc);
> -MOS6522DeviceClass *mdc = MOS6522_DEVICE_CLASS(oc);
>  
>  dc->reset = mos6522_q800_via1_reset;
> -mdc->portB_write = mos6522_q800_via1_portB_write;
>  }
>  
>  static const TypeInfo mos6522_q800_via1_type_info = {
>

Re: [PATCH 05/22] pmu: honour autopoll_rate_ms when rearming the ADB autopoll timer

On 6/14/20 4:28 PM, Mark Cave-Ayland wrote:
> Don't use a fixed value but instead use the default value from the ADB bus
> state.
> 
> Signed-off-by: Mark Cave-Ayland 

Reviewed-by: Philippe Mathieu-Daudé 

> ---
>  hw/misc/macio/pmu.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/hw/misc/macio/pmu.c b/hw/misc/macio/pmu.c
> index 3af4ef1a04..edb061e417 100644
> --- a/hw/misc/macio/pmu.c
> +++ b/hw/misc/macio/pmu.c
> @@ -104,7 +104,7 @@ static void pmu_adb_poll(void *opaque)
>  }
>  
>  timer_mod(s->adb_poll_timer,
> -  qemu_clock_get_ms(QEMU_CLOCK_VIRTUAL) + 30);
> +  qemu_clock_get_ms(QEMU_CLOCK_VIRTUAL) + s->autopoll_rate_ms);
>  }
>  
>  static void pmu_one_sec_timer(void *opaque)
> @@ -180,7 +180,7 @@ static void pmu_cmd_set_adb_autopoll(PMUState *s, 
> uint16_t mask)
>  s->adb_poll_mask = mask;
>  if (mask) {
>  timer_mod(s->adb_poll_timer,
> -  qemu_clock_get_ms(QEMU_CLOCK_VIRTUAL) + 30);
> +  qemu_clock_get_ms(QEMU_CLOCK_VIRTUAL) + 
> s->autopoll_rate_ms);
>  } else {
>  timer_del(s->adb_poll_timer);
>  }
>

Re: [PATCH 03/22] cuda: convert ADB autopoll timer from ns to ms

On 6/14/20 4:28 PM, Mark Cave-Ayland wrote:
> This is in preparation for consolidating all of the ADB autopoll management
> in one place.
> 
> Signed-off-by: Mark Cave-Ayland 

Reviewed-by: Philippe Mathieu-Daudé 

> ---
>  hw/misc/macio/cuda.c | 15 ---
>  1 file changed, 8 insertions(+), 7 deletions(-)
> 
> diff --git a/hw/misc/macio/cuda.c b/hw/misc/macio/cuda.c
> index e0cc0aac5d..a407f2abc8 100644
> --- a/hw/misc/macio/cuda.c
> +++ b/hw/misc/macio/cuda.c
> @@ -208,8 +208,9 @@ static void cuda_adb_poll(void *opaque)
>  obuf[1] = 0x40; /* polled data */
>  cuda_send_packet_to_host(s, obuf, olen + 2);
>  }
> -timer_mod(s->adb_poll_timer, qemu_clock_get_ns(QEMU_CLOCK_VIRTUAL) +
> -  (NANOSECONDS_PER_SECOND / (1000 / s->autopoll_rate_ms)));
> +
> +timer_mod(s->adb_poll_timer, qemu_clock_get_ms(QEMU_CLOCK_VIRTUAL) +
> +  s->autopoll_rate_ms);
>  }
>  
>  /* description of commands */
> @@ -236,8 +237,8 @@ static bool cuda_cmd_autopoll(CUDAState *s,
>  s->autopoll = autopoll;
>  if (autopoll) {
>  timer_mod(s->adb_poll_timer,
> -  qemu_clock_get_ns(QEMU_CLOCK_VIRTUAL) +
> -  (NANOSECONDS_PER_SECOND / (1000 / 
> s->autopoll_rate_ms)));
> +  qemu_clock_get_ms(QEMU_CLOCK_VIRTUAL) +
> +  s->autopoll_rate_ms);
>  } else {
>  timer_del(s->adb_poll_timer);
>  }
> @@ -262,8 +263,8 @@ static bool cuda_cmd_set_autorate(CUDAState *s,
>  s->autopoll_rate_ms = in_data[0];
>  if (s->autopoll) {
>  timer_mod(s->adb_poll_timer,
> -  qemu_clock_get_ns(QEMU_CLOCK_VIRTUAL) +
> -  (NANOSECONDS_PER_SECOND / (1000 / s->autopoll_rate_ms)));
> +  qemu_clock_get_ms(QEMU_CLOCK_VIRTUAL) +
> +  s->autopoll_rate_ms);
>  }
>  return true;
>  }
> @@ -539,7 +540,7 @@ static void cuda_realize(DeviceState *dev, Error **errp)
>  s->sr_delay_timer = timer_new_ns(QEMU_CLOCK_VIRTUAL, cuda_set_sr_int, s);
>  s->sr_delay_ns = 20 * SCALE_US;
>  
> -s->adb_poll_timer = timer_new_ns(QEMU_CLOCK_VIRTUAL, cuda_adb_poll, s);
> +s->adb_poll_timer = timer_new_ms(QEMU_CLOCK_VIRTUAL, cuda_adb_poll, s);
>  s->adb_poll_mask = 0x;
>  s->autopoll_rate_ms = 20;
>  }
>

Re: [PATCH 01/22] adb: coding style update to fix checkpatch errors

On 6/14/20 4:28 PM, Mark Cave-Ayland wrote:
> This will help ensure that style guidelines are being maintained during
> subsequent changes.
> 
> Signed-off-by: Mark Cave-Ayland 

Reviewed-by: Philippe Mathieu-Daudé 

> ---
>  hw/input/adb.c | 9 +
>  1 file changed, 5 insertions(+), 4 deletions(-)
> 
> diff --git a/hw/input/adb.c b/hw/input/adb.c
> index b1ac4a3852..bf1bc30d19 100644
> --- a/hw/input/adb.c
> +++ b/hw/input/adb.c
> @@ -44,14 +44,14 @@ int adb_request(ADBBusState *s, uint8_t *obuf, const 
> uint8_t *buf, int len)
>  
>  cmd = buf[0] & 0xf;
>  if (cmd == ADB_BUSRESET) {
> -for(i = 0; i < s->nb_devices; i++) {
> +for (i = 0; i < s->nb_devices; i++) {
>  d = s->devices[i];
>  adb_device_reset(d);
>  }
>  return 0;
>  }
>  devaddr = buf[0] >> 4;
> -for(i = 0; i < s->nb_devices; i++) {
> +for (i = 0; i < s->nb_devices; i++) {
>  d = s->devices[i];
>  if (d->devaddr == devaddr) {
>  ADBDeviceClass *adc = ADB_DEVICE_GET_CLASS(d);
> @@ -69,9 +69,10 @@ int adb_poll(ADBBusState *s, uint8_t *obuf, uint16_t 
> poll_mask)
>  uint8_t buf[1];
>  
>  olen = 0;
> -for(i = 0; i < s->nb_devices; i++) {
> -if (s->poll_index >= s->nb_devices)
> +for (i = 0; i < s->nb_devices; i++) {
> +if (s->poll_index >= s->nb_devices) {
>  s->poll_index = 0;
> +}
>  d = s->devices[s->poll_index];
>  if ((1 << d->devaddr) & poll_mask) {
>  buf[0] = ADB_READREG | (d->devaddr << 4);
>

Re: [PATCH v4 5/6] i386: Hyper-V VMBus ACPI DSDT entry

2020-06-14 Thread Jon Doron

On 14/06/2020, Jon Doron wrote:

On 28/05/2020, Jon Doron wrote:

On 28/05/2020, Igor Mammedov wrote:

On Thu, 28 May 2020 08:26:42 +0300
Jon Doron wrote:

On 22/05/2020, Igor Mammedow wrote:

On Thu, 21 May 2020 18:02:07 +0200
Paolo Bonzini wrote:

On 13/05/20 17:34, Igor Mammedov wrote:

I'd rather avoid using random IRQ numbers (considering we are
dealing with black-box here). So if it's really necessary to have
IRQ described here, I'd suggest to implement them in device model
so they would be reserved and QEMU would error out in a sane way if
IRQ conflict is detected.

We don't generally detect ISA IRQ conflicts though, do we?

But it seems like the current patch does match what's Microsoft HyperV
is publishing in it's APCI tables.

I dont think it's correct for us to "fix" Microsoft emulation even if
it's wrong, since that's what Windows probably expects to see...

Sounds like a plan, I'll try to come up with the test results
(at least for Windows 10 guest which is what I have setup) and update
this thread with the results.

-- Jon.

Paolo

Hi guys,

Sorry for the delay...

So first ill clarify what was the test, the test was to see the device
"Microsoft Hyper-V Virtual Machine Bus" in Windows Device Manager under
"System devices" with a state of "working properly".

It seems like it's ok to drop all the _PS* and _STA.

It seems to be functioning with single IRQ as well, it is worth noting
that even when i dropped the entire _CRS (so no IRQs resources are
required, the device was still showing that it's functioning, but I
suspect this might affect the child devices like hv-net and hv-scsi).

With that said I did run into a small issue I set-up Win10 1903 (aka
19H1) and it seems like VMBus now requires to have the following
features enabled:

HV_VP_RUNTIME_AVAILABLE
HV_TIME_REF_COUNT_AVAILABLE
HV_SYNIC_AVAILABLE
HV_SYNTIMERS_AVAILABLE
HV_APIC_ACCESS_AVAILABLE
HV_HYPERCALL_AVAILABLE
HV_VP_INDEX_AVAILABLE

So notice that previously only SYNIC and VPINDEX was needed, now you
need the whole thing so you need to run qemu with something like

-cpu
host,hv-relaxed,hv_spinlocks=0x1fff,hv_time,hv-vapic,hv-vpindex,hv-synic,hv-runtime,hv-stimer

The validation was done in winhv!WinHvpCheckPartitionPrivileges .

Paolo I noticed you have done a PULL request, would you like to wait
on it and we will submit a version with a single IRQ (selectable by
user property) and go with Igor's suggestion dropping _PS* and _STA
(though like I said before I prefer to mimic the original HyperV with
it's bugs, but I'll leave this decision to you).

Also today VMBus only verifies SYNIC is enabled I'm not sure how but I
wonder if we want to some how exports from the CPU which other HV
features are enabled so we can verify all the required ones are set,
would appreciate if you have any suggestions here.

Cheers,
-- Jon.

I got the latest DSDT from one of the latest builds 19041

Device (\_SB.VMOD.VMBS)
{
Name (STA, 0x0F)
Name (_ADR, Zero) // _ADR: Address
Name (_DDN, "VMBUS") // _DDN: DOS Device Name
Name (_HID, "VMBus") // _HID: Hardware ID
Name (_UID, Zero) // _UID:

Re: [PATCH v2 1/5] mac_oldworld: Allow loading binary ROM image


On Sun, 14 Jun 2020, Mark Cave-Ayland wrote:

On 13/06/2020 14:36, BALATON Zoltan wrote:


The G3 beige machine has a 4MB firmware ROM. Fix the size of the rom
region and allow loading a binary image with -bios. This makes it
possible to test emulation with a ROM image from real hardware.

Signed-off-by: BALATON Zoltan 
---
 hw/ppc/mac_oldworld.c | 24 +++-
 1 file changed, 15 insertions(+), 9 deletions(-)

diff --git a/hw/ppc/mac_oldworld.c b/hw/ppc/mac_oldworld.c
index 0b4c1c6373..3812adc441 100644
--- a/hw/ppc/mac_oldworld.c
+++ b/hw/ppc/mac_oldworld.c
@@ -59,6 +59,8 @@
 #define NDRV_VGA_FILENAME "qemu_vga.ndrv"

 #define GRACKLE_BASE 0xfec0
+#define PROM_BASE 0xffc0
+#define PROM_SIZE (4 * MiB)

 static void fw_cfg_boot_set(void *opaque, const char *boot_device,
 Error **errp)
@@ -127,24 +129,28 @@ static void ppc_heathrow_init(MachineState *machine)

 memory_region_add_subregion(sysmem, 0, machine->ram);

-/* allocate and load BIOS */
-memory_region_init_rom(bios, NULL, "ppc_heathrow.bios", BIOS_SIZE,
+/* allocate and load firmware ROM */
+memory_region_init_rom(bios, NULL, "ppc_heathrow.bios", PROM_SIZE,
&error_fatal);
+memory_region_add_subregion(sysmem, PROM_BASE, bios);

-if (bios_name == NULL)
+if (!bios_name) {
 bios_name = PROM_FILENAME;
+}
 filename = qemu_find_file(QEMU_FILE_TYPE_BIOS, bios_name);
-memory_region_add_subregion(sysmem, PROM_ADDR, bios);
-
-/* Load OpenBIOS (ELF) */
 if (filename) {
-bios_size = load_elf(filename, NULL, 0, NULL, NULL, NULL, NULL, NULL,
- 1, PPC_ELF_MACHINE, 0, 0);
+/* Load OpenBIOS (ELF) */
+bios_size = load_elf(filename, NULL, NULL, NULL, NULL, NULL, NULL,
+ NULL, 1, PPC_ELF_MACHINE, 0, 0);
+if (bios_size <= 0) {
+/* or load binary ROM image */
+bios_size = load_image_targphys(filename, PROM_BASE, PROM_SIZE);
+}
 g_free(filename);
 } else {
 bios_size = -1;
 }
-if (bios_size < 0 || bios_size > BIOS_SIZE) {
+if (bios_size < 0 || bios_size > PROM_SIZE) {
 error_report("could not load PowerPC bios '%s'", bios_name);
 exit(1);
 }


I think the logic could be improved a bit here: load_elf() can return the 
physical
address from the ELF, so it would make sense to use that as the address for
load_image_targphys() if present, and otherwise fall back to loading at 
0xffc0.


I don't get this. No need to do it that way because load_elf already loads 
the image at address specified in ELF file (I guess because it still works 
with OpenBIOS after this patch) so don't have to call load_image_targphys 
for that case. The above tries load_elf and only if it did not succeed 
calls load_image_targphys to load a binary image to fill the ROM. I don't 
see how this logic could be simpler.


Maybe we need the load address from the ELF to check if an ELF would 
overflow the region as in elf_addr + bios_size > PROM_ADDR + PROM_SIZE but 
I'm not sure. Any suggestion?



It may also make sense to split PROM_ADDR to PROM_ADDR_OLDWORLD and
PROM_ADDR_NEWWORLD (and similar for BIOS_SIZE) to allow these values to be 
adjusted
separately for each machine.


BIOS_SIZE is not used in this board after this patch any more so that's 
basically PROM_SIZE_NEWWORLD now which can be defined in mac_newworld and 
removed from mac.h. Then we have separate PROM_SIZE for each board. I've 
also defined PROM_ADDR here in mac_oldworld and similar define can be 
added to mac_newworld if needed. These should not be in mac.h I think as 
these are board specific. I regard the previous BIOS_* values specific to 
OpenBIOS not to boards so now that boards can use other ROMs not just 
OpenBIOS BIOS_SIZE may not be needed, what we need is the size of the ROM 
chip on board instead.


Regards,
BALATON Zoltan

[PATCH 22/22] adb: add ADB bus trace events

Signed-off-by: Mark Cave-Ayland 
---
 hw/input/adb.c| 23 ++-
 hw/input/trace-events |  7 +++
 2 files changed, 29 insertions(+), 1 deletion(-)

diff --git a/hw/input/adb.c b/hw/input/adb.c
index fe0f6c7ef3..4976f52c36 100644
--- a/hw/input/adb.c
+++ b/hw/input/adb.c
@@ -29,10 +29,18 @@
 #include "qemu/module.h"
 #include "qemu/timer.h"
 #include "adb-internal.h"
+#include "trace.h"
 
 /* error codes */
 #define ADB_RET_NOTPRESENT (-2)
 
+static const char *adb_commands[] = {
+"RESET", "FLUSH", "(Reserved 0x2)", "(Reserved 0x3)",
+"Reserved (0x4)", "(Reserved 0x5)", "(Reserved 0x6)", "(Reserved 0x7)",
+"LISTEN r0", "LISTEN r1", "LISTEN r2", "LISTEN r3",
+"TALK r0", "TALK r1", "TALK r2", "TALK r3",
+};
+
 static void adb_device_reset(ADBDevice *d)
 {
 qdev_reset_all(DEVICE(d));
@@ -86,9 +94,16 @@ static int do_adb_request(ADBBusState *s, uint8_t *obuf, 
const uint8_t *buf,
 
 int adb_request(ADBBusState *s, uint8_t *obuf, const uint8_t *buf, int len)
 {
+int ret;
+
+trace_adb_bus_request(buf[0] >> 4, adb_commands[buf[0] & 0xf], len);
+
 assert(s->autopoll_blocked);
 
-return do_adb_request(s, obuf, buf, len);
+ret = do_adb_request(s, obuf, buf, len);
+
+trace_adb_bus_request_done(buf[0] >> 4, adb_commands[buf[0] & 0xf], ret);
+return ret;
 }
 
 int adb_poll(ADBBusState *s, uint8_t *obuf, uint16_t poll_mask)
@@ -160,6 +175,8 @@ void adb_set_autopoll_mask(ADBBusState *s, uint16_t mask)
 
 void adb_autopoll_block(ADBBusState *s)
 {
+trace_adb_bus_autopoll_block("autopoll BLOCKED");
+
 s->autopoll_blocked = true;
 
 if (s->autopoll_enabled) {
@@ -169,6 +186,8 @@ void adb_autopoll_block(ADBBusState *s)
 
 void adb_autopoll_unblock(ADBBusState *s)
 {
+trace_adb_bus_autopoll_block("autopoll UNBLOCKED");
+
 s->autopoll_blocked = false;
 
 if (s->autopoll_enabled) {
@@ -183,7 +202,9 @@ static void adb_autopoll(void *opaque)
 ADBBusState *s = opaque;
 
 if (!s->autopoll_blocked) {
+trace_adb_bus_autopoll_cb(s->autopoll_mask);
 s->autopoll_cb(s->autopoll_cb_opaque);
+trace_adb_bus_autopoll_cb_done(s->autopoll_mask);
 }
 
 timer_mod(s->autopoll_timer,
diff --git a/hw/input/trace-events b/hw/input/trace-events
index 6f0d78241c..119d1ce2bd 100644
--- a/hw/input/trace-events
+++ b/hw/input/trace-events
@@ -14,6 +14,13 @@ adb_device_mouse_readreg(int reg, uint8_t val0, uint8_t 
val1) "reg %d obuf[0] 0x
 adb_device_mouse_request_change_addr(int devaddr) "change addr to 0x%x"
 adb_device_mouse_request_change_addr_and_handler(int devaddr, int handler) 
"change addr and handler to 0x%x, 0x%x"
 
+# adb.c
+adb_bus_request(uint8_t addr, const char *cmd, int size) "device 0x%x %s 
cmdsize=%d"
+adb_bus_request_done(uint8_t addr, const char *cmd, int size) "device 0x%x %s 
replysize=%d"
+adb_bus_autopoll_block(const char *s) "%s"
+adb_bus_autopoll_cb(uint16_t mask) "executing autopoll_cb with autopoll mask 
0x%x"
+adb_bus_autopoll_cb_done(uint16_t mask) "done executing autopoll_cb with 
autopoll mask 0x%x"
+
 # pckbd.c
 pckbd_kbd_read_data(uint32_t val) "0x%02x"
 pckbd_kbd_read_status(int status) "0x%02x"
-- 
2.20.1

[PATCH 20/22] adb: only call autopoll callbacks when autopoll is not blocked

Handle this at the ADB bus level so that individual implementations do not need
to handle this themselves.

Finally add an assert() into adb_request() to prevent developers from 
accidentally
making an explicit ADB request without blocking autopoll.

Signed-off-by: Mark Cave-Ayland 
---
 hw/input/adb.c| 7 +--
 hw/misc/mac_via.c | 6 +-
 2 files changed, 6 insertions(+), 7 deletions(-)

diff --git a/hw/input/adb.c b/hw/input/adb.c
index 70aa1f4570..fe0f6c7ef3 100644
--- a/hw/input/adb.c
+++ b/hw/input/adb.c
@@ -86,10 +86,11 @@ static int do_adb_request(ADBBusState *s, uint8_t *obuf, 
const uint8_t *buf,
 
 int adb_request(ADBBusState *s, uint8_t *obuf, const uint8_t *buf, int len)
 {
+assert(s->autopoll_blocked);
+
 return do_adb_request(s, obuf, buf, len);
 }
 
-/* XXX: move that to cuda ? */
 int adb_poll(ADBBusState *s, uint8_t *obuf, uint16_t poll_mask)
 {
 ADBDevice *d;
@@ -181,7 +182,9 @@ static void adb_autopoll(void *opaque)
 {
 ADBBusState *s = opaque;
 
-s->autopoll_cb(s->autopoll_cb_opaque);
+if (!s->autopoll_blocked) {
+s->autopoll_cb(s->autopoll_cb_opaque);
+}
 
 timer_mod(s->autopoll_timer,
   qemu_clock_get_ms(QEMU_CLOCK_VIRTUAL) +
diff --git a/hw/misc/mac_via.c b/hw/misc/mac_via.c
index 7676545474..efe96138d0 100644
--- a/hw/misc/mac_via.c
+++ b/hw/misc/mac_via.c
@@ -615,11 +615,7 @@ static void adb_via_poll(void *opaque)
  * received, however we must block autopoll until the point where
  * the entire reply has been read back to the host
  */
-if (adb_bus->autopoll_blocked) {
-return;
-} else {
-adb_autopoll_block(adb_bus);
-}
+adb_autopoll_block(adb_bus);
 
 m->adb_data_in_index = 0;
 m->adb_data_out_index = 0;
-- 
2.20.1

[PATCH 18/22] mac_via: move VIA1 portB write logic into mos6522_q800_via1_write()

Currently the logic is split between the mos6522 portB_write() callback and
the memory region used to capture the VIA1 MMIO accesses. Move everything
into the latter mos6522_q800_via1_write() function to keep all the logic in
one place to make it easier to follow.

Signed-off-by: Mark Cave-Ayland 
---
 hw/misc/mac_via.c | 24 ++--
 1 file changed, 10 insertions(+), 14 deletions(-)

diff --git a/hw/misc/mac_via.c b/hw/misc/mac_via.c
index 669fdca4c4..4779236f95 100644
--- a/hw/misc/mac_via.c
+++ b/hw/misc/mac_via.c
@@ -801,11 +801,21 @@ static void mos6522_q800_via1_write(void *opaque, hwaddr 
addr, uint64_t val,
 unsigned size)
 {
 MOS6522Q800VIA1State *v1s = MOS6522_Q800_VIA1(opaque);
+MacVIAState *m = container_of(v1s, MacVIAState, mos6522_via1);
 MOS6522State *ms = MOS6522(v1s);
 
 addr = (addr >> 9) & 0xf;
 mos6522_write(ms, addr, val, size);
 
+switch (addr) {
+case VIA_REG_B:
+via1_rtc_update(m);
+via1_adb_update(m);
+
+v1s->last_b = ms->b;
+break;
+}
+
 via1_one_second_update(v1s);
 via1_VBL_update(v1s);
 }
@@ -1034,18 +1044,6 @@ static TypeInfo mac_via_info = {
 };
 
 /* VIA 1 */
-static void mos6522_q800_via1_portB_write(MOS6522State *s)
-{
-MOS6522Q800VIA1State *v1s = container_of(s, MOS6522Q800VIA1State,
- parent_obj);
-MacVIAState *m = container_of(v1s, MacVIAState, mos6522_via1);
-
-via1_rtc_update(m);
-via1_adb_update(m);
-
-v1s->last_b = s->b;
-}
-
 static void mos6522_q800_via1_reset(DeviceState *dev)
 {
 MOS6522State *ms = MOS6522(dev);
@@ -1068,10 +1066,8 @@ static void mos6522_q800_via1_init(Object *obj)
 static void mos6522_q800_via1_class_init(ObjectClass *oc, void *data)
 {
 DeviceClass *dc = DEVICE_CLASS(oc);
-MOS6522DeviceClass *mdc = MOS6522_DEVICE_CLASS(oc);
 
 dc->reset = mos6522_q800_via1_reset;
-mdc->portB_write = mos6522_q800_via1_portB_write;
 }
 
 static const TypeInfo mos6522_q800_via1_type_info = {
-- 
2.20.1

[PATCH 19/22] mac_via: rework ADB state machine to be compatible with both MacOS and Linux

The existing ADB state machine is designed to work with Linux which has a 
different
interpretation of the state machine detailed in "Guide to the Macintosh Family
Hardware". In particular the current Linux implementation includes an extra 
change
to IDLE state when switching the VIA between send and receive modes which does 
not
occur in MacOS, and omitting this transition causes the current mac_via ADB 
state
machine to fail.

Rework the ADB state machine accordingly so that it can enumerate and autopoll 
the
ADB under both Linux and MacOS, including the addition of the new 
adb_autopoll_block()
and adb_autopoll_unblock() functions.

Signed-off-by: Mark Cave-Ayland 
---
 hw/misc/mac_via.c | 363 +-
 hw/misc/trace-events  |   3 +
 include/hw/misc/mac_via.h |   1 +
 3 files changed, 246 insertions(+), 121 deletions(-)

diff --git a/hw/misc/mac_via.c b/hw/misc/mac_via.c
index 4779236f95..7676545474 100644
--- a/hw/misc/mac_via.c
+++ b/hw/misc/mac_via.c
@@ -599,176 +599,297 @@ static void via1_rtc_update(MacVIAState *m)
 m->cmd = REG_EMPTY;
 }
 
-static int adb_via_poll(MacVIAState *s, int state, uint8_t *data)
+static void adb_via_poll(void *opaque)
 {
-ADBBusState *adb_bus = &s->adb_bus;
+MacVIAState *m = opaque;
+MOS6522Q800VIA1State *v1s = MOS6522_Q800_VIA1(&m->mos6522_via1);
+MOS6522State *s = MOS6522(v1s);
+ADBBusState *adb_bus = &m->adb_bus;
+uint8_t obuf[9];
+uint8_t *data = &s->sr;
+int olen;
+uint16_t pending;
 
-if (state != ADB_STATE_IDLE) {
-return 0;
+/*
+ * Setting vADBInt below indicates that an autopoll reply has been
+ * received, however we must block autopoll until the point where
+ * the entire reply has been read back to the host
+ */
+if (adb_bus->autopoll_blocked) {
+return;
+} else {
+adb_autopoll_block(adb_bus);
 }
 
-if (s->adb_data_in_size < s->adb_data_in_index) {
-return 0;
-}
+m->adb_data_in_index = 0;
+m->adb_data_out_index = 0;
+olen = adb_poll(adb_bus, obuf, adb_bus->autopoll_mask);
+
+if (olen > 0) {
+/* Autopoll response */
+*data = obuf[0];
+olen--;
+memcpy(m->adb_data_in, &obuf[1], olen);
+m->adb_data_in_size = olen;
+
+s->b &= ~VIA1B_vADBInt;
+qemu_irq_raise(m->adb_data_ready);
+} else if (olen < 0) {
+/* Bus timeout (device does not exist) */
+*data = 0xff;
+s->b |= VIA1B_vADBInt;
+adb_autopoll_unblock(adb_bus);
+} else {
+pending = adb_bus->pending & ~(1 << (m->adb_autopoll_cmd >> 4));
+
+if (pending) {
+/*
+ * Bus timeout (device exists but another device has data). Block
+ * autopoll so the OS can read out the first EVEN and first ODD
+ * byte to determine bus timeout and SRQ status
+ */
+*data = m->adb_autopoll_cmd;
+s->b &= ~VIA1B_vADBInt;
 
-if (s->adb_data_out_index != 0) {
-return 0;
-}
+obuf[0] = 0xff;
+obuf[1] = 0xff;
+olen = 2;
 
-s->adb_data_in_index = 0;
-s->adb_data_out_index = 0;
-s->adb_data_in_size = adb_poll(adb_bus, s->adb_data_in,
-   adb_bus->autopoll_mask);
+memcpy(m->adb_data_in, obuf, olen);
+m->adb_data_in_size = olen;
 
-if (s->adb_data_in_size) {
-*data = s->adb_data_in[s->adb_data_in_index++];
-qemu_irq_raise(s->adb_data_ready);
+qemu_irq_raise(m->adb_data_ready);
+} else {
+/* Bus timeout (device exists but no other device has data) */
+*data = 0;
+s->b |= VIA1B_vADBInt;
+adb_autopoll_unblock(adb_bus);
+}
 }
 
-return s->adb_data_in_size;
+trace_via1_adb_poll(*data, (s->b & VIA1B_vADBInt) ? "+" : "-",
+adb_bus->status, m->adb_data_in_index, olen);
 }
 
-static int adb_via_send(MacVIAState *s, int state, uint8_t data)
+static int adb_via_send_len(uint8_t data)
 {
-switch (state) {
-case ADB_STATE_NEW:
-s->adb_data_out_index = 0;
-break;
-case ADB_STATE_EVEN:
-if ((s->adb_data_out_index & 1) == 0) {
-return 0;
-}
-break;
-case ADB_STATE_ODD:
-if (s->adb_data_out_index & 1) {
-return 0;
+/* Determine the send length from the given ADB command */
+uint8_t cmd = data & 0xc;
+uint8_t reg = data & 0x3;
+
+switch (cmd) {
+case 0x8:
+/* Listen command */
+switch (reg) {
+case 2:
+/* Register 2 is only used for the keyboard */
+return 3;
+case 3:
+/*
+ * Fortunately our devices only implement writes
+ * to register 3 which is fixed at 2 bytes
+ */
+return 3;
+default:
+qemu_log_mask(LOG_UNIMP, "A

[PATCH 17/22] pmu: add adb_autopoll_block() and adb_autopoll_unblock() functions

Ensure that the PMU buffer is protected from autopoll requests overwriting
its contents whilst existing PMU requests are in progress.

Signed-off-by: Mark Cave-Ayland 
---
 hw/misc/macio/pmu.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/hw/misc/macio/pmu.c b/hw/misc/macio/pmu.c
index e2291cc9f6..833dea4f71 100644
--- a/hw/misc/macio/pmu.c
+++ b/hw/misc/macio/pmu.c
@@ -515,6 +515,7 @@ static void pmu_update(PMUState *s)
 {
 MOS6522PMUState *mps = &s->mos6522_pmu;
 MOS6522State *ms = MOS6522(mps);
+ADBBusState *adb_bus = &s->adb_bus;
 
 /* Only react to changes in reg B */
 if (ms->b == s->last_b) {
@@ -576,6 +577,7 @@ static void pmu_update(PMUState *s)
 s->cmd_rsp_pos = 0;
 s->cmd_state = pmu_state_cmd;
 
+adb_autopoll_block(adb_bus);
 trace_pmu_debug_protocol_cmd(s->cmd, s->cmdlen, s->rsplen);
 break;
 
@@ -634,6 +636,7 @@ static void pmu_update(PMUState *s)
 if (s->cmd_state == pmu_state_rsp && s->rsplen == s->cmd_rsp_pos) {
 trace_pmu_debug_protocol_cmd_resp_complete(ms->ier);
 
+adb_autopoll_unblock(adb_bus);
 s->cmd_state = pmu_state_idle;
 }
 }
-- 
2.20.1

[PATCH 16/22] cuda: add adb_autopoll_block() and adb_autopoll_unblock() functions

Ensure that the CUDA buffer is protected from autopoll requests overwriting
its contents whilst existing CUDA requests are in progress.

Signed-off-by: Mark Cave-Ayland 
---
 hw/misc/macio/cuda.c | 5 +
 1 file changed, 5 insertions(+)

diff --git a/hw/misc/macio/cuda.c b/hw/misc/macio/cuda.c
index 716866ea34..3e46ab6864 100644
--- a/hw/misc/macio/cuda.c
+++ b/hw/misc/macio/cuda.c
@@ -114,6 +114,7 @@ static void cuda_update(CUDAState *s)
 {
 MOS6522CUDAState *mcs = &s->mos6522_cuda;
 MOS6522State *ms = MOS6522(mcs);
+ADBBusState *adb_bus = &s->adb_bus;
 int packet_received, len;
 
 packet_received = 0;
@@ -124,6 +125,9 @@ static void cuda_update(CUDAState *s)
 /* data output */
 if ((ms->b & (TACK | TIP)) != (s->last_b & (TACK | TIP))) {
 if (s->data_out_index < sizeof(s->data_out)) {
+if (s->data_out_index == 0) {
+adb_autopoll_block(adb_bus);
+}
 trace_cuda_data_send(ms->sr);
 s->data_out[s->data_out_index++] = ms->sr;
 cuda_delay_set_sr_int(s);
@@ -138,6 +142,7 @@ static void cuda_update(CUDAState *s)
 /* indicate end of transfer */
 if (s->data_in_index >= s->data_in_size) {
 ms->b = (ms->b | TREQ);
+adb_autopoll_unblock(adb_bus);
 }
 cuda_delay_set_sr_int(s);
 }
-- 
2.20.1

[PATCH 10/22] mac_via: convert to use ADBBusState internal autopoll variables

Signed-off-by: Mark Cave-Ayland 
---
 hw/misc/mac_via.c | 22 ++
 include/hw/misc/mac_via.h |  1 -
 2 files changed, 10 insertions(+), 13 deletions(-)

diff --git a/hw/misc/mac_via.c b/hw/misc/mac_via.c
index e05623d730..669fdca4c4 100644
--- a/hw/misc/mac_via.c
+++ b/hw/misc/mac_via.c
@@ -601,6 +601,8 @@ static void via1_rtc_update(MacVIAState *m)
 
 static int adb_via_poll(MacVIAState *s, int state, uint8_t *data)
 {
+ADBBusState *adb_bus = &s->adb_bus;
+
 if (state != ADB_STATE_IDLE) {
 return 0;
 }
@@ -615,7 +617,8 @@ static int adb_via_poll(MacVIAState *s, int state, uint8_t 
*data)
 
 s->adb_data_in_index = 0;
 s->adb_data_out_index = 0;
-s->adb_data_in_size = adb_poll(&s->adb_bus, s->adb_data_in, 0x);
+s->adb_data_in_size = adb_poll(adb_bus, s->adb_data_in,
+   adb_bus->autopoll_mask);
 
 if (s->adb_data_in_size) {
 *data = s->adb_data_in[s->adb_data_in_index++];
@@ -768,10 +771,6 @@ static void via_adb_poll(void *opaque)
 s->b &= ~VIA1B_vADBInt;
 }
 }
-
-timer_mod(m->adb_poll_timer,
-  qemu_clock_get_ns(QEMU_CLOCK_VIRTUAL) +
-  (NANOSECONDS_PER_SECOND / VIA_ADB_POLL_FREQ));
 }
 
 static uint64_t mos6522_q800_via1_read(void *opaque, hwaddr addr, unsigned 
size)
@@ -854,10 +853,9 @@ static void mac_via_reset(DeviceState *dev)
 {
 MacVIAState *m = MAC_VIA(dev);
 MOS6522Q800VIA1State *v1s = &m->mos6522_via1;
+ADBBusState *adb_bus = &m->adb_bus;
 
-timer_mod(m->adb_poll_timer,
-  qemu_clock_get_ns(QEMU_CLOCK_VIRTUAL) +
-  (NANOSECONDS_PER_SECOND / VIA_ADB_POLL_FREQ));
+adb_set_autopoll_enabled(adb_bus, true);
 
 timer_del(v1s->VBL_timer);
 v1s->next_VBL = 0;
@@ -872,6 +870,7 @@ static void mac_via_realize(DeviceState *dev, Error **errp)
 {
 MacVIAState *m = MAC_VIA(dev);
 MOS6522State *ms;
+ADBBusState *adb_bus = &m->adb_bus;
 struct tm tm;
 int ret;
 
@@ -904,7 +903,7 @@ static void mac_via_realize(DeviceState *dev, Error **errp)
 qemu_get_timedate(&tm, 0);
 m->tick_offset = (uint32_t)mktimegm(&tm) + RTC_OFFSET;
 
-m->adb_poll_timer = timer_new_ns(QEMU_CLOCK_VIRTUAL, via_adb_poll, m);
+adb_register_autopoll_callback(adb_bus, via_adb_poll, m);
 m->adb_data_ready = qdev_get_gpio_in_named(dev, "via1-irq",
VIA1_IRQ_ADB_READY_BIT);
 
@@ -977,8 +976,8 @@ static int mac_via_post_load(void *opaque, int version_id)
 
 static const VMStateDescription vmstate_mac_via = {
 .name = "mac-via",
-.version_id = 1,
-.minimum_version_id = 1,
+.version_id = 2,
+.minimum_version_id = 2,
 .post_load = mac_via_post_load,
 .fields = (VMStateField[]) {
 /* VIAs */
@@ -1002,7 +1001,6 @@ static const VMStateDescription vmstate_mac_via = {
 VMSTATE_INT32(wprotect, MacVIAState),
 VMSTATE_INT32(alt, MacVIAState),
 /* ADB */
-VMSTATE_TIMER_PTR(adb_poll_timer, MacVIAState),
 VMSTATE_INT32(adb_data_in_size, MacVIAState),
 VMSTATE_INT32(adb_data_in_index, MacVIAState),
 VMSTATE_INT32(adb_data_out_index, MacVIAState),
diff --git a/include/hw/misc/mac_via.h b/include/hw/misc/mac_via.h
index e74f85be0f..2aaf9e27bf 100644
--- a/include/hw/misc/mac_via.h
+++ b/include/hw/misc/mac_via.h
@@ -106,7 +106,6 @@ typedef struct MacVIAState {
 
 /* ADB */
 ADBBusState adb_bus;
-QEMUTimer *adb_poll_timer;
 qemu_irq adb_data_ready;
 int adb_data_in_size;
 int adb_data_in_index;
-- 
2.20.1

[PATCH 15/22] adb: add autopoll_blocked variable to block autopoll

Whilst autopoll is enabled it is necessary to prevent the ADB buffer contents
from being overwritten until the host has read back the response in its
entirety.

Add adb_autopoll_block() and adb_autopoll_unblock() functions in preparation
for ensuring that the ADB buffer contents are protected for explicit ADB
requests.

Signed-off-by: Mark Cave-Ayland 
---
 hw/input/adb.c | 21 +
 include/hw/input/adb.h |  4 
 2 files changed, 25 insertions(+)

diff --git a/hw/input/adb.c b/hw/input/adb.c
index b3ad7c5fca..70aa1f4570 100644
--- a/hw/input/adb.c
+++ b/hw/input/adb.c
@@ -157,6 +157,26 @@ void adb_set_autopoll_mask(ADBBusState *s, uint16_t mask)
 }
 }
 
+void adb_autopoll_block(ADBBusState *s)
+{
+s->autopoll_blocked = true;
+
+if (s->autopoll_enabled) {
+timer_del(s->autopoll_timer);
+}
+}
+
+void adb_autopoll_unblock(ADBBusState *s)
+{
+s->autopoll_blocked = false;
+
+if (s->autopoll_enabled) {
+timer_mod(s->autopoll_timer,
+  qemu_clock_get_ms(QEMU_CLOCK_VIRTUAL) +
+  s->autopoll_rate_ms);
+}
+}
+
 static void adb_autopoll(void *opaque)
 {
 ADBBusState *s = opaque;
@@ -184,6 +204,7 @@ static const VMStateDescription vmstate_adb_bus = {
 VMSTATE_BOOL(autopoll_enabled, ADBBusState),
 VMSTATE_UINT8(autopoll_rate_ms, ADBBusState),
 VMSTATE_UINT16(autopoll_mask, ADBBusState),
+VMSTATE_BOOL(autopoll_blocked, ADBBusState),
 VMSTATE_END_OF_LIST()
 }
 };
diff --git a/include/hw/input/adb.h b/include/hw/input/adb.h
index cff264739c..bb75a7b1e3 100644
--- a/include/hw/input/adb.h
+++ b/include/hw/input/adb.h
@@ -86,6 +86,7 @@ struct ADBBusState {
 
 QEMUTimer *autopoll_timer;
 bool autopoll_enabled;
+bool autopoll_blocked;
 uint8_t autopoll_rate_ms;
 uint16_t autopoll_mask;
 void (*autopoll_cb)(void *opaque);
@@ -96,6 +97,9 @@ int adb_request(ADBBusState *s, uint8_t *buf_out,
 const uint8_t *buf, int len);
 int adb_poll(ADBBusState *s, uint8_t *buf_out, uint16_t poll_mask);
 
+void adb_autopoll_block(ADBBusState *s);
+void adb_autopoll_unblock(ADBBusState *s);
+
 void adb_set_autopoll_enabled(ADBBusState *s, bool enabled);
 void adb_set_autopoll_rate_ms(ADBBusState *s, int rate_ms);
 void adb_set_autopoll_mask(ADBBusState *s, uint16_t mask);
-- 
2.20.1

[PATCH 09/22] pmu: convert to use ADBBusState internal autopoll variables

Signed-off-by: Mark Cave-Ayland 
---
 hw/misc/macio/pmu.c | 39 ++---
 include/hw/misc/macio/pmu.h |  3 ---
 2 files changed, 15 insertions(+), 27 deletions(-)

diff --git a/hw/misc/macio/pmu.c b/hw/misc/macio/pmu.c
index edb061e417..e2291cc9f6 100644
--- a/hw/misc/macio/pmu.c
+++ b/hw/misc/macio/pmu.c
@@ -90,10 +90,11 @@ static void pmu_update_extirq(PMUState *s)
 static void pmu_adb_poll(void *opaque)
 {
 PMUState *s = opaque;
+ADBBusState *adb_bus = &s->adb_bus;
 int olen;
 
 if (!(s->intbits & PMU_INT_ADB)) {
-olen = adb_poll(&s->adb_bus, s->adb_reply, s->adb_poll_mask);
+olen = adb_poll(adb_bus, s->adb_reply, adb_bus->autopoll_mask);
 trace_pmu_adb_poll(olen);
 
 if (olen > 0) {
@@ -102,9 +103,6 @@ static void pmu_adb_poll(void *opaque)
 pmu_update_extirq(s);
 }
 }
-
-timer_mod(s->adb_poll_timer,
-  qemu_clock_get_ms(QEMU_CLOCK_VIRTUAL) + s->autopoll_rate_ms);
 }
 
 static void pmu_one_sec_timer(void *opaque)
@@ -171,18 +169,15 @@ static void pmu_cmd_set_int_mask(PMUState *s,
 
 static void pmu_cmd_set_adb_autopoll(PMUState *s, uint16_t mask)
 {
-trace_pmu_cmd_set_adb_autopoll(mask);
+ADBBusState *adb_bus = &s->adb_bus;
 
-if (s->adb_poll_mask == mask) {
-return;
-}
+trace_pmu_cmd_set_adb_autopoll(mask);
 
-s->adb_poll_mask = mask;
 if (mask) {
-timer_mod(s->adb_poll_timer,
-  qemu_clock_get_ms(QEMU_CLOCK_VIRTUAL) + s->autopoll_rate_ms);
+adb_set_autopoll_mask(adb_bus, mask);
+adb_set_autopoll_enabled(adb_bus, true);
 } else {
-timer_del(s->adb_poll_timer);
+adb_set_autopoll_enabled(adb_bus, false);
 }
 }
 
@@ -265,6 +260,8 @@ static void pmu_cmd_adb_poll_off(PMUState *s,
  const uint8_t *in_data, uint8_t in_len,
  uint8_t *out_data, uint8_t *out_len)
 {
+ADBBusState *adb_bus = &s->adb_bus;
+
 if (in_len != 0) {
 qemu_log_mask(LOG_GUEST_ERROR,
   "PMU: ADB POLL OFF command, invalid len: %d want: 0\n",
@@ -272,9 +269,8 @@ static void pmu_cmd_adb_poll_off(PMUState *s,
 return;
 }
 
-if (s->has_adb && s->adb_poll_mask) {
-timer_del(s->adb_poll_timer);
-s->adb_poll_mask = 0;
+if (s->has_adb) {
+adb_set_autopoll_enabled(adb_bus, false);
 }
 }
 
@@ -682,12 +678,10 @@ static bool pmu_adb_state_needed(void *opaque)
 
 static const VMStateDescription vmstate_pmu_adb = {
 .name = "pmu/adb",
-.version_id = 0,
-.minimum_version_id = 0,
+.version_id = 1,
+.minimum_version_id = 1,
 .needed = pmu_adb_state_needed,
 .fields = (VMStateField[]) {
-VMSTATE_UINT16(adb_poll_mask, PMUState),
-VMSTATE_TIMER_PTR(adb_poll_timer, PMUState),
 VMSTATE_UINT8(adb_reply_size, PMUState),
 VMSTATE_BUFFER(adb_reply, PMUState),
 VMSTATE_END_OF_LIST()
@@ -712,7 +706,6 @@ static const VMStateDescription vmstate_pmu = {
 VMSTATE_BUFFER(cmd_rsp, PMUState),
 VMSTATE_UINT8(intbits, PMUState),
 VMSTATE_UINT8(intmask, PMUState),
-VMSTATE_UINT8(autopoll_rate_ms, PMUState),
 VMSTATE_UINT32(tick_offset, PMUState),
 VMSTATE_TIMER_PTR(one_sec_timer, PMUState),
 VMSTATE_INT64(one_sec_target, PMUState),
@@ -732,7 +725,6 @@ static void pmu_reset(DeviceState *dev)
 s->intbits = 0;
 
 s->cmd_state = pmu_state_idle;
-s->adb_poll_mask = 0;
 }
 
 static void pmu_realize(DeviceState *dev, Error **errp)
@@ -741,6 +733,7 @@ static void pmu_realize(DeviceState *dev, Error **errp)
 SysBusDevice *sbd;
 MOS6522State *ms;
 DeviceState *d;
+ADBBusState *adb_bus = &s->adb_bus;
 struct tm tm;
 
 /* Pass IRQ from 6522 */
@@ -758,9 +751,7 @@ static void pmu_realize(DeviceState *dev, Error **errp)
 if (s->has_adb) {
 qbus_create_inplace(&s->adb_bus, sizeof(s->adb_bus), TYPE_ADB_BUS,
 dev, "adb.0");
-s->adb_poll_timer = timer_new_ms(QEMU_CLOCK_VIRTUAL, pmu_adb_poll, s);
-s->adb_poll_mask = 0x;
-s->autopoll_rate_ms = 20;
+adb_register_autopoll_callback(adb_bus, pmu_adb_poll, s);
 }
 }
 
diff --git a/include/hw/misc/macio/pmu.h b/include/hw/misc/macio/pmu.h
index 4f34b6f9e7..72f75612b6 100644
--- a/include/hw/misc/macio/pmu.h
+++ b/include/hw/misc/macio/pmu.h
@@ -218,9 +218,6 @@ typedef struct PMUState {
 /* ADB */
 bool has_adb;
 ADBBusState adb_bus;
-uint16_t adb_poll_mask;
-uint8_t autopoll_rate_ms;
-QEMUTimer *adb_poll_timer;
 uint8_t adb_reply_size;
 uint8_t adb_reply[ADB_MAX_OUT_LEN];
 
-- 
2.20.1

[PATCH 13/22] adb: add status field for holding information about the last ADB request

Currently only 2 bits are defined: one to indicate if the request timed out (no
reply) and another to indicate whether the request was the result of an autopoll
operation.

Signed-off-by: Mark Cave-Ayland 
---
 hw/input/adb.c | 14 +++---
 include/hw/input/adb.h |  4 
 2 files changed, 15 insertions(+), 3 deletions(-)

diff --git a/hw/input/adb.c b/hw/input/adb.c
index c1adb21e6b..a7a482fdfa 100644
--- a/hw/input/adb.c
+++ b/hw/input/adb.c
@@ -42,7 +42,7 @@ int adb_request(ADBBusState *s, uint8_t *obuf, const uint8_t 
*buf, int len)
 {
 ADBDevice *d;
 ADBDeviceClass *adc;
-int devaddr, cmd, i;
+int devaddr, cmd, olen, i;
 
 cmd = buf[0] & 0xf;
 if (cmd == ADB_BUSRESET) {
@@ -50,6 +50,7 @@ int adb_request(ADBBusState *s, uint8_t *obuf, const uint8_t 
*buf, int len)
 d = s->devices[i];
 adb_device_reset(d);
 }
+s->status = 0;
 return 0;
 }
 
@@ -63,16 +64,22 @@ int adb_request(ADBBusState *s, uint8_t *obuf, const 
uint8_t *buf, int len)
 }
 }
 
+s->status = 0;
 devaddr = buf[0] >> 4;
 for (i = 0; i < s->nb_devices; i++) {
 d = s->devices[i];
 adc = ADB_DEVICE_GET_CLASS(d);
 
 if (d->devaddr == devaddr) {
-return adc->devreq(d, obuf, buf, len);
+olen = adc->devreq(d, obuf, buf, len);
+if (!olen) {
+s->status |= ADB_STATUS_BUSTIMEOUT;
+}
+return olen;
 }
 }
 
+s->status |= ADB_STATUS_BUSTIMEOUT;
 return ADB_RET_NOTPRESENT;
 }
 
@@ -94,9 +101,10 @@ int adb_poll(ADBBusState *s, uint8_t *obuf, uint16_t 
poll_mask)
 olen = adb_request(s, obuf + 1, buf, 1);
 /* if there is data, we poll again the same device */
 if (olen > 0) {
+s->status |= ADB_STATUS_POLLREPLY;
 obuf[0] = buf[0];
 olen++;
-break;
+return olen;
 }
 }
 s->poll_index++;
diff --git a/include/hw/input/adb.h b/include/hw/input/adb.h
index f1bc358d8e..cff264739c 100644
--- a/include/hw/input/adb.h
+++ b/include/hw/input/adb.h
@@ -70,6 +70,9 @@ typedef struct ADBDeviceClass {
 #define TYPE_ADB_BUS "apple-desktop-bus"
 #define ADB_BUS(obj) OBJECT_CHECK(ADBBusState, (obj), TYPE_ADB_BUS)
 
+#define ADB_STATUS_BUSTIMEOUT  0x1
+#define ADB_STATUS_POLLREPLY   0x2
+
 struct ADBBusState {
 /*< private >*/
 BusState parent_obj;
@@ -79,6 +82,7 @@ struct ADBBusState {
 uint16_t pending;
 int nb_devices;
 int poll_index;
+uint8_t status;
 
 QEMUTimer *autopoll_timer;
 bool autopoll_enabled;
-- 
2.20.1

[PATCH 05/22] pmu: honour autopoll_rate_ms when rearming the ADB autopoll timer

Don't use a fixed value but instead use the default value from the ADB bus
state.

Signed-off-by: Mark Cave-Ayland 
---
 hw/misc/macio/pmu.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/hw/misc/macio/pmu.c b/hw/misc/macio/pmu.c
index 3af4ef1a04..edb061e417 100644
--- a/hw/misc/macio/pmu.c
+++ b/hw/misc/macio/pmu.c
@@ -104,7 +104,7 @@ static void pmu_adb_poll(void *opaque)
 }
 
 timer_mod(s->adb_poll_timer,
-  qemu_clock_get_ms(QEMU_CLOCK_VIRTUAL) + 30);
+  qemu_clock_get_ms(QEMU_CLOCK_VIRTUAL) + s->autopoll_rate_ms);
 }
 
 static void pmu_one_sec_timer(void *opaque)
@@ -180,7 +180,7 @@ static void pmu_cmd_set_adb_autopoll(PMUState *s, uint16_t 
mask)
 s->adb_poll_mask = mask;
 if (mask) {
 timer_mod(s->adb_poll_timer,
-  qemu_clock_get_ms(QEMU_CLOCK_VIRTUAL) + 30);
+  qemu_clock_get_ms(QEMU_CLOCK_VIRTUAL) + s->autopoll_rate_ms);
 } else {
 timer_del(s->adb_poll_timer);
 }
-- 
2.20.1

[PATCH 21/22] adb: use adb_device prefix for ADB device trace events

This is to allow us to distinguish between ADB device events and ADB
bus events separately.

Signed-off-by: Mark Cave-Ayland 
---
 hw/input/adb-kbd.c| 12 ++--
 hw/input/adb-mouse.c  | 12 ++--
 hw/input/trace-events | 20 ++--
 3 files changed, 22 insertions(+), 22 deletions(-)

diff --git a/hw/input/adb-kbd.c b/hw/input/adb-kbd.c
index 23760ecf7b..3cfb6a7a20 100644
--- a/hw/input/adb-kbd.c
+++ b/hw/input/adb-kbd.c
@@ -243,7 +243,7 @@ static int adb_kbd_request(ADBDevice *d, uint8_t *obuf,
 olen = 0;
 switch (cmd) {
 case ADB_WRITEREG:
-trace_adb_kbd_writereg(reg, buf[1]);
+trace_adb_device_kbd_writereg(reg, buf[1]);
 switch (reg) {
 case 2:
 /* LED status */
@@ -256,7 +256,7 @@ static int adb_kbd_request(ADBDevice *d, uint8_t *obuf,
 case ADB_CMD_CHANGE_ID_AND_ACT:
 case ADB_CMD_CHANGE_ID_AND_ENABLE:
 d->devaddr = buf[1] & 0xf;
-trace_adb_kbd_request_change_addr(d->devaddr);
+trace_adb_device_kbd_request_change_addr(d->devaddr);
 break;
 default:
 d->devaddr = buf[1] & 0xf;
@@ -270,8 +270,8 @@ static int adb_kbd_request(ADBDevice *d, uint8_t *obuf,
 d->handler = buf[2];
 }
 
-trace_adb_kbd_request_change_addr_and_handler(d->devaddr,
-  d->handler);
+trace_adb_device_kbd_request_change_addr_and_handler(
+d->devaddr, d->handler);
 break;
 }
 }
@@ -294,7 +294,7 @@ static int adb_kbd_request(ADBDevice *d, uint8_t *obuf,
 olen = 2;
 break;
 }
-trace_adb_kbd_readreg(reg, obuf[0], obuf[1]);
+trace_adb_device_kbd_readreg(reg, obuf[0], obuf[1]);
 break;
 }
 return olen;
@@ -321,7 +321,7 @@ static void adb_keyboard_event(DeviceState *dev, 
QemuConsole *src,
 /* FIXME: take handler into account when translating qcode */
 keycode = qcode_to_adb_keycode[qcode];
 if (keycode == NO_KEY) {  /* We don't want to send this to the guest */
-trace_adb_kbd_no_key();
+trace_adb_device_kbd_no_key();
 return;
 }
 if (evt->u.key.data->down == false) { /* if key release event */
diff --git a/hw/input/adb-mouse.c b/hw/input/adb-mouse.c
index e2359fd74d..577a38ff2e 100644
--- a/hw/input/adb-mouse.c
+++ b/hw/input/adb-mouse.c
@@ -121,7 +121,7 @@ static int adb_mouse_request(ADBDevice *d, uint8_t *obuf,
 s->dx = 0;
 s->dy = 0;
 s->dz = 0;
-trace_adb_mouse_flush();
+trace_adb_device_mouse_flush();
 return 0;
 }
 
@@ -130,7 +130,7 @@ static int adb_mouse_request(ADBDevice *d, uint8_t *obuf,
 olen = 0;
 switch (cmd) {
 case ADB_WRITEREG:
-trace_adb_mouse_writereg(reg, buf[1]);
+trace_adb_device_mouse_writereg(reg, buf[1]);
 switch (reg) {
 case 2:
 break;
@@ -152,7 +152,7 @@ static int adb_mouse_request(ADBDevice *d, uint8_t *obuf,
 case ADB_CMD_CHANGE_ID_AND_ACT:
 case ADB_CMD_CHANGE_ID_AND_ENABLE:
 d->devaddr = buf[1] & 0xf;
-trace_adb_mouse_request_change_addr(d->devaddr);
+trace_adb_device_mouse_request_change_addr(d->devaddr);
 break;
 default:
 d->devaddr = buf[1] & 0xf;
@@ -172,8 +172,8 @@ static int adb_mouse_request(ADBDevice *d, uint8_t *obuf,
 d->handler = buf[2];
 }
 
-trace_adb_mouse_request_change_addr_and_handler(d->devaddr,
-d->handler);
+trace_adb_device_mouse_request_change_addr_and_handler(
+d->devaddr, d->handler);
 break;
 }
 }
@@ -191,7 +191,7 @@ static int adb_mouse_request(ADBDevice *d, uint8_t *obuf,
 olen = 2;
 break;
 }
-trace_adb_mouse_readreg(reg, obuf[0], obuf[1]);
+trace_adb_device_mouse_readreg(reg, obuf[0], obuf[1]);
 break;
 }
 return olen;
diff --git a/hw/input/trace-events b/hw/input/trace-events
index a2888fd10c..6f0d78241c 100644
--- a/hw/input/trace-events
+++ b/hw/input/trace-events
@@ -1,18 +1,18 @@
 # See docs/devel/tracing.txt for syntax documentation.
 
 # adb-kbd.c
-adb_kbd_no_key(void) "Ignoring NO_KEY"
-adb_kbd_writereg(int reg, uint8_t val) "reg %d val 0x%2.2x"
-adb_kbd_readreg(int reg, uint8_t val0, uint8_t val1) "reg %d obuf[0] 0x%2.2x 
obuf[1] 0x%2.2x"
-adb_kbd_request_change_addr(int devaddr) "change addr to 0x%x"
-adb_kbd_request_change_addr_and_handler(int devaddr, int handler) "change addr 
and handler to 0x%x, 0x%x"
+adb_device_kbd_no_key(void) "Ignoring NO_KEY"
+adb_device_kbd_writereg(int reg, uint8_t val) "reg %d val 0x%2.2x"

[PATCH 12/22] adb: keep track of devices with pending data

Add a new pending variable to ADBBusState which is a bitmask indicating which
ADB devices have data to send. Update the bitmask every time that an ADB
request is executed.

Signed-off-by: Mark Cave-Ayland 
---
 hw/input/adb.c | 16 +++-
 include/hw/input/adb.h |  1 +
 2 files changed, 16 insertions(+), 1 deletion(-)

diff --git a/hw/input/adb.c b/hw/input/adb.c
index bb36ce6fad..c1adb21e6b 100644
--- a/hw/input/adb.c
+++ b/hw/input/adb.c
@@ -41,6 +41,7 @@ static void adb_device_reset(ADBDevice *d)
 int adb_request(ADBBusState *s, uint8_t *obuf, const uint8_t *buf, int len)
 {
 ADBDevice *d;
+ADBDeviceClass *adc;
 int devaddr, cmd, i;
 
 cmd = buf[0] & 0xf;
@@ -51,14 +52,27 @@ int adb_request(ADBBusState *s, uint8_t *obuf, const 
uint8_t *buf, int len)
 }
 return 0;
 }
+
+s->pending = 0;
+for (i = 0; i < s->nb_devices; i++) {
+d = s->devices[i];
+adc = ADB_DEVICE_GET_CLASS(d);
+
+if (adc->devhasdata(d)) {
+s->pending |= (1 << d->devaddr);
+}
+}
+
 devaddr = buf[0] >> 4;
 for (i = 0; i < s->nb_devices; i++) {
 d = s->devices[i];
+adc = ADB_DEVICE_GET_CLASS(d);
+
 if (d->devaddr == devaddr) {
-ADBDeviceClass *adc = ADB_DEVICE_GET_CLASS(d);
 return adc->devreq(d, obuf, buf, len);
 }
 }
+
 return ADB_RET_NOTPRESENT;
 }
 
diff --git a/include/hw/input/adb.h b/include/hw/input/adb.h
index 9b80204e43..f1bc358d8e 100644
--- a/include/hw/input/adb.h
+++ b/include/hw/input/adb.h
@@ -76,6 +76,7 @@ struct ADBBusState {
 /*< public >*/
 
 ADBDevice *devices[MAX_ADB_DEVICES];
+uint16_t pending;
 int nb_devices;
 int poll_index;
 
-- 
2.20.1

[PATCH 07/22] adb: create autopoll variables directly within ADBBusState

Rather than each ADB implementation requiring its own functions to manage
autopoll state, timers, and autopoll masks prepare to move this information
directly into ADBBusState.

Add external functions within adb.h to allow each ADB implementation to
manage the new autopoll variables.

Signed-off-by: Mark Cave-Ayland 
---
 hw/input/adb.c | 77 ++
 include/hw/input/adb.h | 13 +++
 2 files changed, 90 insertions(+)

diff --git a/hw/input/adb.c b/hw/input/adb.c
index 21a9b3aa96..bb36ce6fad 100644
--- a/hw/input/adb.c
+++ b/hw/input/adb.c
@@ -27,6 +27,7 @@
 #include "hw/qdev-properties.h"
 #include "migration/vmstate.h"
 #include "qemu/module.h"
+#include "qemu/timer.h"
 #include "adb-internal.h"
 
 /* error codes */
@@ -89,19 +90,92 @@ int adb_poll(ADBBusState *s, uint8_t *obuf, uint16_t 
poll_mask)
 return olen;
 }
 
+void adb_set_autopoll_enabled(ADBBusState *s, bool enabled)
+{
+if (s->autopoll_enabled != enabled) {
+s->autopoll_enabled = enabled;
+if (s->autopoll_enabled) {
+timer_mod(s->autopoll_timer,
+  qemu_clock_get_ms(QEMU_CLOCK_VIRTUAL) +
+  s->autopoll_rate_ms);
+} else {
+timer_del(s->autopoll_timer);
+}
+}
+}
+
+void adb_set_autopoll_rate_ms(ADBBusState *s, int rate_ms)
+{
+s->autopoll_rate_ms = rate_ms;
+
+if (s->autopoll_enabled) {
+timer_mod(s->autopoll_timer,
+  qemu_clock_get_ms(QEMU_CLOCK_VIRTUAL) +
+  s->autopoll_rate_ms);
+}
+}
+
+void adb_set_autopoll_mask(ADBBusState *s, uint16_t mask)
+{
+if (s->autopoll_mask != mask) {
+s->autopoll_mask = mask;
+if (s->autopoll_enabled && s->autopoll_mask) {
+timer_mod(s->autopoll_timer,
+  qemu_clock_get_ms(QEMU_CLOCK_VIRTUAL) +
+  s->autopoll_rate_ms);
+} else {
+timer_del(s->autopoll_timer);
+}
+}
+}
+
+static void adb_autopoll(void *opaque)
+{
+ADBBusState *s = opaque;
+
+s->autopoll_cb(s->autopoll_cb_opaque);
+
+timer_mod(s->autopoll_timer,
+  qemu_clock_get_ms(QEMU_CLOCK_VIRTUAL) +
+  s->autopoll_rate_ms);
+}
+
+void adb_register_autopoll_callback(ADBBusState *s, void (*cb)(void *opaque),
+void *opaque)
+{
+s->autopoll_cb = cb;
+s->autopoll_cb_opaque = opaque;
+}
+
 static const VMStateDescription vmstate_adb_bus = {
 .name = "adb_bus",
 .version_id = 0,
 .minimum_version_id = 0,
 .fields = (VMStateField[]) {
+VMSTATE_TIMER_PTR(autopoll_timer, ADBBusState),
+VMSTATE_BOOL(autopoll_enabled, ADBBusState),
+VMSTATE_UINT8(autopoll_rate_ms, ADBBusState),
+VMSTATE_UINT16(autopoll_mask, ADBBusState),
 VMSTATE_END_OF_LIST()
 }
 };
 
+static void adb_bus_reset(BusState *qbus)
+{
+ADBBusState *adb_bus = ADB_BUS(qbus);
+
+adb_bus->autopoll_enabled = false;
+adb_bus->autopoll_mask = 0x;
+adb_bus->autopoll_rate_ms = 20;
+}
+
 static void adb_bus_realize(BusState *qbus, Error **errp)
 {
 ADBBusState *adb_bus = ADB_BUS(qbus);
 
+adb_bus->autopoll_timer = timer_new_ms(QEMU_CLOCK_VIRTUAL, adb_autopoll,
+   adb_bus);
+
 vmstate_register(NULL, -1, &vmstate_adb_bus, adb_bus);
 }
 
@@ -109,6 +183,8 @@ static void adb_bus_unrealize(BusState *qbus)
 {
 ADBBusState *adb_bus = ADB_BUS(qbus);
 
+timer_del(adb_bus->autopoll_timer);
+
 vmstate_unregister(NULL, &vmstate_adb_bus, adb_bus);
 }
 
@@ -118,6 +194,7 @@ static void adb_bus_class_init(ObjectClass *klass, void 
*data)
 
 k->realize = adb_bus_realize;
 k->unrealize = adb_bus_unrealize;
+k->reset = adb_bus_reset;
 }
 
 static const TypeInfo adb_bus_type_info = {
diff --git a/include/hw/input/adb.h b/include/hw/input/adb.h
index 4d2c565f54..15b1874a3d 100644
--- a/include/hw/input/adb.h
+++ b/include/hw/input/adb.h
@@ -75,12 +75,25 @@ struct ADBBusState {
 ADBDevice *devices[MAX_ADB_DEVICES];
 int nb_devices;
 int poll_index;
+
+QEMUTimer *autopoll_timer;
+bool autopoll_enabled;
+uint8_t autopoll_rate_ms;
+uint16_t autopoll_mask;
+void (*autopoll_cb)(void *opaque);
+void *autopoll_cb_opaque;
 };
 
 int adb_request(ADBBusState *s, uint8_t *buf_out,
 const uint8_t *buf, int len);
 int adb_poll(ADBBusState *s, uint8_t *buf_out, uint16_t poll_mask);
 
+void adb_set_autopoll_enabled(ADBBusState *s, bool enabled);
+void adb_set_autopoll_rate_ms(ADBBusState *s, int rate_ms);
+void adb_set_autopoll_mask(ADBBusState *s, uint16_t mask);
+void adb_register_autopoll_callback(ADBBusState *s, void (*cb)(void *opaque),
+void *opaque);
+
 #define TYPE_ADB_KEYBOARD "adb-keyboard"
 #define TYPE_ADB_MOUSE "adb-mouse"
 
-- 
2.20.1

[PATCH 04/22] pmu: fix duplicate autopoll mask variable

It seems that during the initial work to introduce the via-pmu ADB support a
duplicate autopoll mask variable was accidentally left in place.

Remove the duplicate autopoll_mask variable and switch everything over to
use adb_poll_mask instead.

Signed-off-by: Mark Cave-Ayland 
---
 hw/misc/macio/pmu.c | 15 +++
 include/hw/misc/macio/pmu.h |  1 -
 2 files changed, 7 insertions(+), 9 deletions(-)

diff --git a/hw/misc/macio/pmu.c b/hw/misc/macio/pmu.c
index 9a9cd427e1..3af4ef1a04 100644
--- a/hw/misc/macio/pmu.c
+++ b/hw/misc/macio/pmu.c
@@ -173,11 +173,11 @@ static void pmu_cmd_set_adb_autopoll(PMUState *s, 
uint16_t mask)
 {
 trace_pmu_cmd_set_adb_autopoll(mask);
 
-if (s->autopoll_mask == mask) {
+if (s->adb_poll_mask == mask) {
 return;
 }
 
-s->autopoll_mask = mask;
+s->adb_poll_mask = mask;
 if (mask) {
 timer_mod(s->adb_poll_timer,
   qemu_clock_get_ms(QEMU_CLOCK_VIRTUAL) + 30);
@@ -272,9 +272,9 @@ static void pmu_cmd_adb_poll_off(PMUState *s,
 return;
 }
 
-if (s->has_adb && s->autopoll_mask) {
+if (s->has_adb && s->adb_poll_mask) {
 timer_del(s->adb_poll_timer);
-s->autopoll_mask = false;
+s->adb_poll_mask = 0;
 }
 }
 
@@ -696,8 +696,8 @@ static const VMStateDescription vmstate_pmu_adb = {
 
 static const VMStateDescription vmstate_pmu = {
 .name = "pmu",
-.version_id = 0,
-.minimum_version_id = 0,
+.version_id = 1,
+.minimum_version_id = 1,
 .fields = (VMStateField[]) {
 VMSTATE_STRUCT(mos6522_pmu.parent_obj, PMUState, 0, vmstate_mos6522,
MOS6522State),
@@ -713,7 +713,6 @@ static const VMStateDescription vmstate_pmu = {
 VMSTATE_UINT8(intbits, PMUState),
 VMSTATE_UINT8(intmask, PMUState),
 VMSTATE_UINT8(autopoll_rate_ms, PMUState),
-VMSTATE_UINT8(autopoll_mask, PMUState),
 VMSTATE_UINT32(tick_offset, PMUState),
 VMSTATE_TIMER_PTR(one_sec_timer, PMUState),
 VMSTATE_INT64(one_sec_target, PMUState),
@@ -733,7 +732,7 @@ static void pmu_reset(DeviceState *dev)
 s->intbits = 0;
 
 s->cmd_state = pmu_state_idle;
-s->autopoll_mask = 0;
+s->adb_poll_mask = 0;
 }
 
 static void pmu_realize(DeviceState *dev, Error **errp)
diff --git a/include/hw/misc/macio/pmu.h b/include/hw/misc/macio/pmu.h
index 7ef83dee4c..4f34b6f9e7 100644
--- a/include/hw/misc/macio/pmu.h
+++ b/include/hw/misc/macio/pmu.h
@@ -220,7 +220,6 @@ typedef struct PMUState {
 ADBBusState adb_bus;
 uint16_t adb_poll_mask;
 uint8_t autopoll_rate_ms;
-uint8_t autopoll_mask;
 QEMUTimer *adb_poll_timer;
 uint8_t adb_reply_size;
 uint8_t adb_reply[ADB_MAX_OUT_LEN];
-- 
2.20.1

[PATCH 14/22] adb: use adb_request() only for explicit requests

Currently adb_request() is called both for explicit ADB requests and internal
autopoll requests via adb_poll().

Move the current functionality into do_adb_request() to be used internally and
add a simple adb_request() wrapper for explicit requests.

Signed-off-by: Mark Cave-Ayland 
---
 hw/input/adb.c | 10 --
 1 file changed, 8 insertions(+), 2 deletions(-)

diff --git a/hw/input/adb.c b/hw/input/adb.c
index a7a482fdfa..b3ad7c5fca 100644
--- a/hw/input/adb.c
+++ b/hw/input/adb.c
@@ -38,7 +38,8 @@ static void adb_device_reset(ADBDevice *d)
 qdev_reset_all(DEVICE(d));
 }
 
-int adb_request(ADBBusState *s, uint8_t *obuf, const uint8_t *buf, int len)
+static int do_adb_request(ADBBusState *s, uint8_t *obuf, const uint8_t *buf,
+  int len)
 {
 ADBDevice *d;
 ADBDeviceClass *adc;
@@ -83,6 +84,11 @@ int adb_request(ADBBusState *s, uint8_t *obuf, const uint8_t 
*buf, int len)
 return ADB_RET_NOTPRESENT;
 }
 
+int adb_request(ADBBusState *s, uint8_t *obuf, const uint8_t *buf, int len)
+{
+return do_adb_request(s, obuf, buf, len);
+}
+
 /* XXX: move that to cuda ? */
 int adb_poll(ADBBusState *s, uint8_t *obuf, uint16_t poll_mask)
 {
@@ -98,7 +104,7 @@ int adb_poll(ADBBusState *s, uint8_t *obuf, uint16_t 
poll_mask)
 d = s->devices[s->poll_index];
 if ((1 << d->devaddr) & poll_mask) {
 buf[0] = ADB_READREG | (d->devaddr << 4);
-olen = adb_request(s, obuf + 1, buf, 1);
+olen = do_adb_request(s, obuf + 1, buf, 1);
 /* if there is data, we poll again the same device */
 if (olen > 0) {
 s->status |= ADB_STATUS_POLLREPLY;
-- 
2.20.1

[PATCH 11/22] adb: introduce new ADBDeviceHasData method to ADBDeviceClass

This is required later to allow devices to assert a service request (SRQ)
signal to indicate that it has data to send, without having to consume it.

Signed-off-by: Mark Cave-Ayland 
---
 hw/input/adb-kbd.c | 8 
 hw/input/adb-mouse.c   | 9 +
 include/hw/input/adb.h | 3 +++
 3 files changed, 20 insertions(+)

diff --git a/hw/input/adb-kbd.c b/hw/input/adb-kbd.c
index 027dd3e531..23760ecf7b 100644
--- a/hw/input/adb-kbd.c
+++ b/hw/input/adb-kbd.c
@@ -300,6 +300,13 @@ static int adb_kbd_request(ADBDevice *d, uint8_t *obuf,
 return olen;
 }
 
+static bool adb_kbd_has_data(ADBDevice *d)
+{
+KBDState *s = ADB_KEYBOARD(d);
+
+return s->count > 0;
+}
+
 /* This is where keyboard events enter this file */
 static void adb_keyboard_event(DeviceState *dev, QemuConsole *src,
InputEvent *evt)
@@ -382,6 +389,7 @@ static void adb_kbd_class_init(ObjectClass *oc, void *data)
 set_bit(DEVICE_CATEGORY_INPUT, dc->categories);
 
 adc->devreq = adb_kbd_request;
+adc->devhasdata = adb_kbd_has_data;
 dc->reset = adb_kbd_reset;
 dc->vmsd = &vmstate_adb_kbd;
 }
diff --git a/hw/input/adb-mouse.c b/hw/input/adb-mouse.c
index 78b6f5030c..e2359fd74d 100644
--- a/hw/input/adb-mouse.c
+++ b/hw/input/adb-mouse.c
@@ -197,6 +197,14 @@ static int adb_mouse_request(ADBDevice *d, uint8_t *obuf,
 return olen;
 }
 
+static bool adb_mouse_has_data(ADBDevice *d)
+{
+MouseState *s = ADB_MOUSE(d);
+
+return !(s->last_buttons_state == s->buttons_state &&
+ s->dx == 0 && s->dy == 0);
+}
+
 static void adb_mouse_reset(DeviceState *dev)
 {
 ADBDevice *d = ADB_DEVICE(dev);
@@ -252,6 +260,7 @@ static void adb_mouse_class_init(ObjectClass *oc, void 
*data)
 set_bit(DEVICE_CATEGORY_INPUT, dc->categories);
 
 adc->devreq = adb_mouse_request;
+adc->devhasdata = adb_mouse_has_data;
 dc->reset = adb_mouse_reset;
 dc->vmsd = &vmstate_adb_mouse;
 }
diff --git a/include/hw/input/adb.h b/include/hw/input/adb.h
index 15b1874a3d..9b80204e43 100644
--- a/include/hw/input/adb.h
+++ b/include/hw/input/adb.h
@@ -39,6 +39,8 @@ typedef struct ADBDevice ADBDevice;
 typedef int ADBDeviceRequest(ADBDevice *d, uint8_t *buf_out,
   const uint8_t *buf, int len);
 
+typedef bool ADBDeviceHasData(ADBDevice *d);
+
 #define TYPE_ADB_DEVICE "adb-device"
 #define ADB_DEVICE(obj) OBJECT_CHECK(ADBDevice, (obj), TYPE_ADB_DEVICE)
 
@@ -62,6 +64,7 @@ typedef struct ADBDeviceClass {
 /*< public >*/
 
 ADBDeviceRequest *devreq;
+ADBDeviceHasData *devhasdata;
 } ADBDeviceClass;
 
 #define TYPE_ADB_BUS "apple-desktop-bus"
-- 
2.20.1

[PATCH 03/22] cuda: convert ADB autopoll timer from ns to ms

This is in preparation for consolidating all of the ADB autopoll management
in one place.

Signed-off-by: Mark Cave-Ayland 
---
 hw/misc/macio/cuda.c | 15 ---
 1 file changed, 8 insertions(+), 7 deletions(-)

diff --git a/hw/misc/macio/cuda.c b/hw/misc/macio/cuda.c
index e0cc0aac5d..a407f2abc8 100644
--- a/hw/misc/macio/cuda.c
+++ b/hw/misc/macio/cuda.c
@@ -208,8 +208,9 @@ static void cuda_adb_poll(void *opaque)
 obuf[1] = 0x40; /* polled data */
 cuda_send_packet_to_host(s, obuf, olen + 2);
 }
-timer_mod(s->adb_poll_timer, qemu_clock_get_ns(QEMU_CLOCK_VIRTUAL) +
-  (NANOSECONDS_PER_SECOND / (1000 / s->autopoll_rate_ms)));
+
+timer_mod(s->adb_poll_timer, qemu_clock_get_ms(QEMU_CLOCK_VIRTUAL) +
+  s->autopoll_rate_ms);
 }
 
 /* description of commands */
@@ -236,8 +237,8 @@ static bool cuda_cmd_autopoll(CUDAState *s,
 s->autopoll = autopoll;
 if (autopoll) {
 timer_mod(s->adb_poll_timer,
-  qemu_clock_get_ns(QEMU_CLOCK_VIRTUAL) +
-  (NANOSECONDS_PER_SECOND / (1000 / s->autopoll_rate_ms)));
+  qemu_clock_get_ms(QEMU_CLOCK_VIRTUAL) +
+  s->autopoll_rate_ms);
 } else {
 timer_del(s->adb_poll_timer);
 }
@@ -262,8 +263,8 @@ static bool cuda_cmd_set_autorate(CUDAState *s,
 s->autopoll_rate_ms = in_data[0];
 if (s->autopoll) {
 timer_mod(s->adb_poll_timer,
-  qemu_clock_get_ns(QEMU_CLOCK_VIRTUAL) +
-  (NANOSECONDS_PER_SECOND / (1000 / s->autopoll_rate_ms)));
+  qemu_clock_get_ms(QEMU_CLOCK_VIRTUAL) +
+  s->autopoll_rate_ms);
 }
 return true;
 }
@@ -539,7 +540,7 @@ static void cuda_realize(DeviceState *dev, Error **errp)
 s->sr_delay_timer = timer_new_ns(QEMU_CLOCK_VIRTUAL, cuda_set_sr_int, s);
 s->sr_delay_ns = 20 * SCALE_US;
 
-s->adb_poll_timer = timer_new_ns(QEMU_CLOCK_VIRTUAL, cuda_adb_poll, s);
+s->adb_poll_timer = timer_new_ms(QEMU_CLOCK_VIRTUAL, cuda_adb_poll, s);
 s->adb_poll_mask = 0x;
 s->autopoll_rate_ms = 20;
 }
-- 
2.20.1

[PATCH 02/22] adb: fix adb-mouse read length and revert disable-reg3-direct-writes workaround

Commit 84051eb400 "adb: add property to disable direct reg 3 writes" introduced
a workaround for spurious writes to ADB register 3 when MacOS 9 enables
autopoll on the mouse device. Further analysis shows that the problem is that
only a partial request is sent, and since the len parameter is ignored then
stale data from the previous request is used causing the incorrect address
assignment.

Remove the disable-reg3-direct-writes workaround and instead check the length
parameter when the write is attempted, discarding the invalid request.

Signed-off-by: Mark Cave-Ayland 
---
 hw/input/adb-kbd.c | 26 +++
 hw/input/adb-mouse.c   | 48 --
 hw/input/adb.c |  7 --
 hw/ppc/mac_newworld.c  |  2 --
 include/hw/input/adb.h |  1 -
 5 files changed, 40 insertions(+), 44 deletions(-)

diff --git a/hw/input/adb-kbd.c b/hw/input/adb-kbd.c
index a6d5c9b7c9..027dd3e531 100644
--- a/hw/input/adb-kbd.c
+++ b/hw/input/adb-kbd.c
@@ -259,21 +259,19 @@ static int adb_kbd_request(ADBDevice *d, uint8_t *obuf,
 trace_adb_kbd_request_change_addr(d->devaddr);
 break;
 default:
-if (!d->disable_direct_reg3_writes) {
-d->devaddr = buf[1] & 0xf;
-
-/* we support handlers:
- * 1: Apple Standard Keyboard
- * 2: Apple Extended Keyboard (LShift = RShift)
- * 3: Apple Extended Keyboard (LShift != RShift)
- */
-if (buf[2] == 1 || buf[2] == 2 || buf[2] == 3) {
-d->handler = buf[2];
-}
-
-trace_adb_kbd_request_change_addr_and_handler(d->devaddr,
-  d->handler);
+d->devaddr = buf[1] & 0xf;
+/*
+ * we support handlers:
+ * 1: Apple Standard Keyboard
+ * 2: Apple Extended Keyboard (LShift = RShift)
+ * 3: Apple Extended Keyboard (LShift != RShift)
+ */
+if (buf[2] == 1 || buf[2] == 2 || buf[2] == 3) {
+d->handler = buf[2];
 }
+
+trace_adb_kbd_request_change_addr_and_handler(d->devaddr,
+  d->handler);
 break;
 }
 }
diff --git a/hw/input/adb-mouse.c b/hw/input/adb-mouse.c
index aeba41bddd..78b6f5030c 100644
--- a/hw/input/adb-mouse.c
+++ b/hw/input/adb-mouse.c
@@ -135,6 +135,16 @@ static int adb_mouse_request(ADBDevice *d, uint8_t *obuf,
 case 2:
 break;
 case 3:
+/*
+ * MacOS 9 has a bug in its ADB driver whereby after configuring
+ * the ADB bus devices it sends another write of invalid length
+ * to reg 3. Make sure we ignore it to prevent an address clash
+ * with the previous device.
+ */
+if (len != 3) {
+return 0;
+}
+
 switch (buf[2]) {
 case ADB_CMD_SELF_TEST:
 break;
@@ -145,27 +155,25 @@ static int adb_mouse_request(ADBDevice *d, uint8_t *obuf,
 trace_adb_mouse_request_change_addr(d->devaddr);
 break;
 default:
-if (!d->disable_direct_reg3_writes) {
-d->devaddr = buf[1] & 0xf;
-
-/* we support handlers:
- * 0x01: Classic Apple Mouse Protocol / 100 cpi operations
- * 0x02: Classic Apple Mouse Protocol / 200 cpi operations
- * we don't support handlers (at least):
- * 0x03: Mouse systems A3 trackball
- * 0x04: Extended Apple Mouse Protocol
- * 0x2f: Microspeed mouse
- * 0x42: Macally
- * 0x5f: Microspeed mouse
- * 0x66: Microspeed mouse
- */
-if (buf[2] == 1 || buf[2] == 2) {
-d->handler = buf[2];
-}
-
-trace_adb_mouse_request_change_addr_and_handler(
-d->devaddr, d->handler);
+d->devaddr = buf[1] & 0xf;
+/*
+ * we support handlers:
+ * 0x01: Classic Apple Mouse Protocol / 100 cpi operations
+ * 0x02: Classic Apple Mouse Protocol / 200 cpi operations
+ * we don't support handlers (at least):
+ * 0x03: Mouse systems A3 trackball
+ * 0x04: Extended Apple Mouse Protocol
+ * 0x2f: Microspeed mouse
+ * 0x42: Macally
+ * 0x5f: Microspeed mouse
+ * 0x66: Microspeed mouse
+ */
+if (buf

[PATCH 06/22] adb: introduce realize/unrealize and VMStateDescription for ADB bus

Signed-off-by: Mark Cave-Ayland 
---
 hw/input/adb.c | 32 
 1 file changed, 32 insertions(+)

diff --git a/hw/input/adb.c b/hw/input/adb.c
index d85278a7b7..21a9b3aa96 100644
--- a/hw/input/adb.c
+++ b/hw/input/adb.c
@@ -89,10 +89,42 @@ int adb_poll(ADBBusState *s, uint8_t *obuf, uint16_t 
poll_mask)
 return olen;
 }
 
+static const VMStateDescription vmstate_adb_bus = {
+.name = "adb_bus",
+.version_id = 0,
+.minimum_version_id = 0,
+.fields = (VMStateField[]) {
+VMSTATE_END_OF_LIST()
+}
+};
+
+static void adb_bus_realize(BusState *qbus, Error **errp)
+{
+ADBBusState *adb_bus = ADB_BUS(qbus);
+
+vmstate_register(NULL, -1, &vmstate_adb_bus, adb_bus);
+}
+
+static void adb_bus_unrealize(BusState *qbus)
+{
+ADBBusState *adb_bus = ADB_BUS(qbus);
+
+vmstate_unregister(NULL, &vmstate_adb_bus, adb_bus);
+}
+
+static void adb_bus_class_init(ObjectClass *klass, void *data)
+{
+BusClass *k = BUS_CLASS(klass);
+
+k->realize = adb_bus_realize;
+k->unrealize = adb_bus_unrealize;
+}
+
 static const TypeInfo adb_bus_type_info = {
 .name = TYPE_ADB_BUS,
 .parent = TYPE_BUS,
 .instance_size = sizeof(ADBBusState),
+.class_init = adb_bus_class_init,
 };
 
 const VMStateDescription vmstate_adb_device = {
-- 
2.20.1

[PATCH 00/22] ADB: fix autopoll issues and rework mac_via state machine

This patchset is something I have been chipping away at for a while since
spending some time over the Christmas holidays trying to boot the MacOS
toolbox ROM on the new q800 machine.

Initially I discovered that there were some problems when the MacOS ROM was
enumerating ADB devices due to multiple meanings of the vADBInt bit. After
fixing this there were still issues with keys being dropped during autopoll
which were eventually traced back to the autopoll timer re-firing before
the host had managed to read back the previous response.

At this point I noticed that CUDA/PMU/mac_via all had their own implementations
of ADB autopoll, and that it would make sense to consolidate the autopoll timer,
mask, interval and locking into the ADB bus. This would allow the logic to be
removed from each separate device and managed in just one place.

Finally I updated the trace-events to allow separate tracing of bus requests
and device responses which makes it easier to follow the ADB enumeration 
process.

The breakdown of the patchset is as follows:

- Patch 1 keeps checkpatch happy for the remainder of the patchset whilst patch
  2 is the proper fix for a spurious ADB register 3 write during enumeration
  caused by ignoring the request length which I had tried to work around 
earlier.

- Patches 3 to 10 are part of the autopoll consolidation process which moves the
  separate autopoll implementations into a single implementation within
  ADBBusState.

- Patches 11 to 13 update the ADB implementation to hold a status variable
  indicating the result of the last request and allow devices to indicate
  whether they have data to send. This extra information is required by the
  upcoming mac_via state machine changes.

- Patches 14 to 17 add a variable and functions to block and unblock ADB
  autopoll at bus level, adding the functions at the correct places within
  CUDA and PMU.

- Patches 18 and 19 rework the mac_via ADB state machine so that the bus
  can be enumerated correctly, and both explicit and autopoll requests work
  under both MacOS and Linux.

- Patch 20 enforces the blocking and unblocking of autopoll at the ADB
  level, including adding an assert() to prevent developers from trying to
  make an ADB request whilst autopoll is in progress.
  
- Patches 21 and 22 update the trace-events to separate out ADB device and
  ADB bus events.

The patch has been tested by myself and a couple of others during the 
development
process across the PPC g3beige/mac99 and 68K q800 machine so it should be quite
solid.

One thing to indicate is that the patchset bumps the VMState versions for the
affected devices but does not allow older versions to load. This is a conscious
decision given that for the mac_via device used in the q800 machine it would be
just about impossible to map this in a way that would work for all cases. 
Similarly
for the Mac PPC machines migration is already hit/miss due to timebase issues so
I don't see this as being a big loss.

To finish off I'd also like to say a big thank-you to both Laurent Vivier and
Finn Thain who both took time to answer my questions, dump information from a
real q800, and analyse it in very fine detail. Without them this patchset would
still be several months away.

Signed-off-by: Mark Cave-Ayland 


Mark Cave-Ayland (22):
  adb: coding style update to fix checkpatch errors
  adb: fix adb-mouse read length and revert disable-reg3-direct-writes
workaround
  cuda: convert ADB autopoll timer from ns to ms
  pmu: fix duplicate autopoll mask variable
  pmu: honour autopoll_rate_ms when rearming the ADB autopoll timer
  adb: introduce realize/unrealize and VMStateDescription for ADB bus
  adb: create autopoll variables directly within ADBBusState
  cuda: convert to use ADBBusState internal autopoll variables
  pmu: convert to use ADBBusState internal autopoll variables
  mac_via: convert to use ADBBusState internal autopoll variables
  adb: introduce new ADBDeviceHasData method to ADBDeviceClass
  adb: keep track of devices with pending data
  adb: add status field for holding information about the last ADB
request
  adb: use adb_request() only for explicit requests
  adb: add autopoll_blocked variable to block autopoll
  cuda: add adb_autopoll_block() and adb_autopoll_unblock() functions
  pmu: add adb_autopoll_block() and adb_autopoll_unblock() functions
  mac_via: move VIA1 portB write logic into mos6522_q800_via1_write()
  mac_via: rework ADB state machine to be compatible with both MacOS and
Linux
  adb: only call autopoll callbacks when autopoll is not blocked
  adb: use adb_device prefix for ADB device trace events
  adb: add ADB bus trace events

 hw/input/adb-kbd.c   |  42 ++--
 hw/input/adb-mouse.c |  65 +++---
 hw/input/adb.c   | 212 +--
 hw/input/trace-events|  27 ++-
 hw/misc/mac_via.c| 399 ++-
 hw/misc/macio/cuda.c |  60 +++---
 hw/misc/macio/pmu.c

[PATCH 08/22] cuda: convert to use ADBBusState internal autopoll variables

Signed-off-by: Mark Cave-Ayland 
---
 hw/misc/macio/cuda.c | 56 +++-
 include/hw/misc/macio/cuda.h |  4 ---
 2 files changed, 23 insertions(+), 37 deletions(-)

diff --git a/hw/misc/macio/cuda.c b/hw/misc/macio/cuda.c
index a407f2abc8..716866ea34 100644
--- a/hw/misc/macio/cuda.c
+++ b/hw/misc/macio/cuda.c
@@ -199,18 +199,16 @@ static void cuda_send_packet_to_host(CUDAState *s,
 static void cuda_adb_poll(void *opaque)
 {
 CUDAState *s = opaque;
+ADBBusState *adb_bus = &s->adb_bus;
 uint8_t obuf[ADB_MAX_OUT_LEN + 2];
 int olen;
 
-olen = adb_poll(&s->adb_bus, obuf + 2, s->adb_poll_mask);
+olen = adb_poll(adb_bus, obuf + 2, adb_bus->autopoll_mask);
 if (olen > 0) {
 obuf[0] = ADB_PACKET;
 obuf[1] = 0x40; /* polled data */
 cuda_send_packet_to_host(s, obuf, olen + 2);
 }
-
-timer_mod(s->adb_poll_timer, qemu_clock_get_ms(QEMU_CLOCK_VIRTUAL) +
-  s->autopoll_rate_ms);
 }
 
 /* description of commands */
@@ -226,23 +224,16 @@ static bool cuda_cmd_autopoll(CUDAState *s,
   const uint8_t *in_data, int in_len,
   uint8_t *out_data, int *out_len)
 {
-int autopoll;
+ADBBusState *adb_bus = &s->adb_bus;
+bool autopoll;
 
 if (in_len != 1) {
 return false;
 }
 
-autopoll = (in_data[0] != 0);
-if (autopoll != s->autopoll) {
-s->autopoll = autopoll;
-if (autopoll) {
-timer_mod(s->adb_poll_timer,
-  qemu_clock_get_ms(QEMU_CLOCK_VIRTUAL) +
-  s->autopoll_rate_ms);
-} else {
-timer_del(s->adb_poll_timer);
-}
-}
+autopoll = (in_data[0] != 0) ? true : false;
+
+adb_set_autopoll_enabled(adb_bus, autopoll);
 return true;
 }
 
@@ -250,6 +241,8 @@ static bool cuda_cmd_set_autorate(CUDAState *s,
   const uint8_t *in_data, int in_len,
   uint8_t *out_data, int *out_len)
 {
+ADBBusState *adb_bus = &s->adb_bus;
+
 if (in_len != 1) {
 return false;
 }
@@ -260,12 +253,7 @@ static bool cuda_cmd_set_autorate(CUDAState *s,
 return false;
 }
 
-s->autopoll_rate_ms = in_data[0];
-if (s->autopoll) {
-timer_mod(s->adb_poll_timer,
-  qemu_clock_get_ms(QEMU_CLOCK_VIRTUAL) +
-  s->autopoll_rate_ms);
-}
+adb_set_autopoll_rate_ms(adb_bus, in_data[0]);
 return true;
 }
 
@@ -273,11 +261,16 @@ static bool cuda_cmd_set_device_list(CUDAState *s,
  const uint8_t *in_data, int in_len,
  uint8_t *out_data, int *out_len)
 {
+ADBBusState *adb_bus = &s->adb_bus;
+uint16_t mask;
+
 if (in_len != 2) {
 return false;
 }
 
-s->adb_poll_mask = (((uint16_t)in_data[0]) << 8) | in_data[1];
+mask = (((uint16_t)in_data[0]) << 8) | in_data[1];
+
+adb_set_autopoll_mask(adb_bus, mask);
 return true;
 }
 
@@ -488,8 +481,8 @@ static const MemoryRegionOps mos6522_cuda_ops = {
 
 static const VMStateDescription vmstate_cuda = {
 .name = "cuda",
-.version_id = 5,
-.minimum_version_id = 5,
+.version_id = 6,
+.minimum_version_id = 6,
 .fields = (VMStateField[]) {
 VMSTATE_STRUCT(mos6522_cuda.parent_obj, CUDAState, 0, vmstate_mos6522,
MOS6522State),
@@ -498,13 +491,9 @@ static const VMStateDescription vmstate_cuda = {
 VMSTATE_INT32(data_in_size, CUDAState),
 VMSTATE_INT32(data_in_index, CUDAState),
 VMSTATE_INT32(data_out_index, CUDAState),
-VMSTATE_UINT8(autopoll, CUDAState),
-VMSTATE_UINT8(autopoll_rate_ms, CUDAState),
-VMSTATE_UINT16(adb_poll_mask, CUDAState),
 VMSTATE_BUFFER(data_in, CUDAState),
 VMSTATE_BUFFER(data_out, CUDAState),
 VMSTATE_UINT32(tick_offset, CUDAState),
-VMSTATE_TIMER_PTR(adb_poll_timer, CUDAState),
 VMSTATE_TIMER_PTR(sr_delay_timer, CUDAState),
 VMSTATE_END_OF_LIST()
 }
@@ -513,11 +502,13 @@ static const VMStateDescription vmstate_cuda = {
 static void cuda_reset(DeviceState *dev)
 {
 CUDAState *s = CUDA(dev);
+ADBBusState *adb_bus = &s->adb_bus;
 
 s->data_in_size = 0;
 s->data_in_index = 0;
 s->data_out_index = 0;
-s->autopoll = 0;
+
+adb_set_autopoll_enabled(adb_bus, false);
 }
 
 static void cuda_realize(DeviceState *dev, Error **errp)
@@ -526,6 +517,7 @@ static void cuda_realize(DeviceState *dev, Error **errp)
 SysBusDevice *sbd;
 MOS6522State *ms;
 DeviceState *d;
+ADBBusState *adb_bus = &s->adb_bus;
 struct tm tm;
 
 /* Pass IRQ from 6522 */
@@ -540,9 +532,7 @@ static void cuda_realize(DeviceState *dev, Error **errp)
 s->sr_delay_timer = timer_new_ns(QEMU_CLOCK_VIRTUAL, cuda_set_sr_int, s);
 s->sr_delay_ns = 20 * SCALE_US;
 
-s->adb_poll_timer = timer_new_ms

[PATCH 01/22] adb: coding style update to fix checkpatch errors

This will help ensure that style guidelines are being maintained during
subsequent changes.

Signed-off-by: Mark Cave-Ayland 
---
 hw/input/adb.c | 9 +
 1 file changed, 5 insertions(+), 4 deletions(-)

diff --git a/hw/input/adb.c b/hw/input/adb.c
index b1ac4a3852..bf1bc30d19 100644
--- a/hw/input/adb.c
+++ b/hw/input/adb.c
@@ -44,14 +44,14 @@ int adb_request(ADBBusState *s, uint8_t *obuf, const 
uint8_t *buf, int len)
 
 cmd = buf[0] & 0xf;
 if (cmd == ADB_BUSRESET) {
-for(i = 0; i < s->nb_devices; i++) {
+for (i = 0; i < s->nb_devices; i++) {
 d = s->devices[i];
 adb_device_reset(d);
 }
 return 0;
 }
 devaddr = buf[0] >> 4;
-for(i = 0; i < s->nb_devices; i++) {
+for (i = 0; i < s->nb_devices; i++) {
 d = s->devices[i];
 if (d->devaddr == devaddr) {
 ADBDeviceClass *adc = ADB_DEVICE_GET_CLASS(d);
@@ -69,9 +69,10 @@ int adb_poll(ADBBusState *s, uint8_t *obuf, uint16_t 
poll_mask)
 uint8_t buf[1];
 
 olen = 0;
-for(i = 0; i < s->nb_devices; i++) {
-if (s->poll_index >= s->nb_devices)
+for (i = 0; i < s->nb_devices; i++) {
+if (s->poll_index >= s->nb_devices) {
 s->poll_index = 0;
+}
 d = s->devices[s->poll_index];
 if ((1 << d->devaddr) & poll_mask) {
 buf[0] = ADB_READREG | (d->devaddr << 4);
-- 
2.20.1

Re: [PATCH v2 5/5] mac_oldworld: Map macio to expected address at reset


On Sun, 14 Jun 2020, Mark Cave-Ayland wrote:

On 13/06/2020 14:36, BALATON Zoltan wrote:


Add a reset function that maps macio to the address expected by the
firmware of the board at startup.

Signed-off-by: BALATON Zoltan 
---
 hw/ppc/mac.h  | 12 
 hw/ppc/mac_oldworld.c | 17 +++--
 2 files changed, 27 insertions(+), 2 deletions(-)

diff --git a/hw/ppc/mac.h b/hw/ppc/mac.h
index 6af87d1fa0..35a5f21163 100644
--- a/hw/ppc/mac.h
+++ b/hw/ppc/mac.h
@@ -57,6 +57,18 @@
 #define OLDWORLD_IDE1_IRQ  0xe
 #define OLDWORLD_IDE1_DMA_IRQ  0x3

+/* g3beige machine */
+#define TYPE_HEATHROW_MACHINE MACHINE_TYPE_NAME("g3beige")
+#define HEATHROW_MACHINE(obj) OBJECT_CHECK(HeathrowMachineState, (obj), \
+   TYPE_HEATHROW_MACHINE)
+
+typedef struct HeathrowMachineState {
+/*< private >*/
+MachineState parent;
+
+PCIDevice *macio_pci;
+} HeathrowMachineState;
+
 /* New World IRQs */
 #define NEWWORLD_CUDA_IRQ  0x19
 #define NEWWORLD_PMU_IRQ   0x19
diff --git a/hw/ppc/mac_oldworld.c b/hw/ppc/mac_oldworld.c
index 9138752ccb..fa9527410d 100644
--- a/hw/ppc/mac_oldworld.c
+++ b/hw/ppc/mac_oldworld.c
@@ -73,6 +73,15 @@ static uint64_t translate_kernel_address(void *opaque, 
uint64_t addr)
 return (addr & 0x0fff) + KERNEL_LOAD_ADDR;
 }

+static void ppc_heathrow_reset(MachineState *machine)
+{
+HeathrowMachineState *m = HEATHROW_MACHINE(machine);
+
+qemu_devices_reset();
+pci_default_write_config(m->macio_pci, PCI_COMMAND, PCI_COMMAND_MEMORY, 2);
+pci_default_write_config(m->macio_pci, PCI_BASE_ADDRESS_0, 0xf300, 4);
+}
+
 static void ppc_heathrow_cpu_reset(void *opaque)
 {
 PowerPCCPU *cpu = opaque;
@@ -91,6 +100,7 @@ const MemoryRegionOps machine_id_reg_ops = {

 static void ppc_heathrow_init(MachineState *machine)
 {
+HeathrowMachineState *hm = HEATHROW_MACHINE(machine);
 ram_addr_t ram_size = machine->ram_size;
 const char *kernel_filename = machine->kernel_filename;
 const char *kernel_cmdline = machine->kernel_cmdline;
@@ -298,7 +308,8 @@ static void ppc_heathrow_init(MachineState *machine)
 ide_drive_get(hd, ARRAY_SIZE(hd));

 /* MacIO */
-macio = OLDWORLD_MACIO(pci_create(pci_bus, -1, TYPE_OLDWORLD_MACIO));
+hm->macio_pci = pci_create(pci_bus, -1, TYPE_OLDWORLD_MACIO);
+macio = OLDWORLD_MACIO(hm->macio_pci);
 dev = DEVICE(macio);
 qdev_prop_set_uint64(dev, "frequency", tbfreq);
 object_property_set_link(OBJECT(macio), OBJECT(pic_dev), "pic",
@@ -450,6 +461,7 @@ static void heathrow_class_init(ObjectClass *oc, void *data)

 mc->desc = "Heathrow based PowerMAC";
 mc->init = ppc_heathrow_init;
+mc->reset = ppc_heathrow_reset;
 mc->block_default_type = IF_IDE;
 mc->max_cpus = MAX_CPUS;
 #ifndef TARGET_PPC64
@@ -466,9 +478,10 @@ static void heathrow_class_init(ObjectClass *oc, void 
*data)
 }

 static const TypeInfo ppc_heathrow_machine_info = {
-.name  = MACHINE_TYPE_NAME("g3beige"),
+.name  = TYPE_HEATHROW_MACHINE,
 .parent= TYPE_MACHINE,
 .class_init= heathrow_class_init,
+.instance_size = sizeof(HeathrowMachineState),
 .interfaces = (InterfaceInfo[]) {
 { TYPE_FW_PATH_PROVIDER },
 { }


This doesn't feel right to me - either the PROM should be configuring the BARs 
as it
requires before trying to use the macio device, or the macio device has a fixed
mapping. Possibly the latter could be true given that things are so early in 
the boot
process?


It looks suspicious but unless there's something in the ROM before it 
starts accessig macio @ 0xf300 that I've missed I don't know how it 
would get there. I haven't check all the disassembly but logging PCI 
accesses that shows grackle config regs and unassigned mem writes did not 
show any signs of the ROM mapping it there so unless this should be done 
by a reg somewhere we implement but don't do the mapping it should be 
there from the beginning.



Are there any hints in the macio "reg" and "address" properties suggesting that 
this
might be the case?


I haven't got a device tree that I know coming from a real machine, the 
ones I've found show macio mapped to 0xf300 but that's after OF 
started, don't know how it got there from a device tree.


Regards,
BALATON Zoltan

Re: [PATCH v2 4/5] mac_oldworld: Rename ppc_heathrow_reset reset to ppc_heathrow_cpu_reset


On Sun, 14 Jun 2020, Mark Cave-Ayland wrote:

On 13/06/2020 14:36, BALATON Zoltan wrote:


This function resets a CPU not the whole machine so reflect that in
its name.

Signed-off-by: BALATON Zoltan 
---
 hw/ppc/mac_oldworld.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/hw/ppc/mac_oldworld.c b/hw/ppc/mac_oldworld.c
index 4dd872c1a3..9138752ccb 100644
--- a/hw/ppc/mac_oldworld.c
+++ b/hw/ppc/mac_oldworld.c
@@ -73,7 +73,7 @@ static uint64_t translate_kernel_address(void *opaque, 
uint64_t addr)
 return (addr & 0x0fff) + KERNEL_LOAD_ADDR;
 }

-static void ppc_heathrow_reset(void *opaque)
+static void ppc_heathrow_cpu_reset(void *opaque)
 {
 PowerPCCPU *cpu = opaque;

@@ -127,7 +127,7 @@ static void ppc_heathrow_init(MachineState *machine)

 /* Set time-base frequency to 16.6 Mhz */
 cpu_ppc_tb_init(env,  TBFREQ);
-qemu_register_reset(ppc_heathrow_reset, cpu);
+qemu_register_reset(ppc_heathrow_cpu_reset, cpu);
 }

 /* allocate RAM */


Technically this is a board level reset which just happens to pass the CPU for 
the
opaque, so I'm not quite sold on this one (as an example look at mac_newworld.c 
where
using the ELF load address for the PROM would require a dynamic NIP which is 
most
conveniently accessed via a MachineState).


The mac_newworld also registers a per CPU reset function like this one. 
This could be done in the machine level reset I add in next patch but 
there could be multiple CPUs and I don't know how to access those from 
MachineState so I've left this CPU reset functions alone which could be 
cleaned up later.


Ideally I should not need a machine reset to set the initial BAR mapping 
but otherwise the sequence of registered reset funcs are not guaranteed 
and the PCI device is reset during qemu_devices_reset() which clears the 
BARs so it won't stay mapped otherwise. I could not find an easier way to 
map this BAR.


Regards,
BALATON Zoltan

Re: [PATCH v4 5/6] i386: Hyper-V VMBus ACPI DSDT entry

2020-06-14 Thread Jon Doron

On 28/05/2020, Jon Doron wrote:

On 28/05/2020, Igor Mammedov wrote:

On Thu, 28 May 2020 08:26:42 +0300
Jon Doron wrote:

On 22/05/2020, Igor Mammedow wrote:

On Thu, 21 May 2020 18:02:07 +0200
Paolo Bonzini wrote:

We don't generally detect ISA IRQ conflicts though, do we?

But it seems like the current patch does match what's Microsoft HyperV
is publishing in it's APCI tables.

I dont think it's correct for us to "fix" Microsoft emulation even if
it's wrong, since that's what Windows probably expects to see...

Sounds like a plan, I'll try to come up with the test results
(at least for Windows 10 guest which is what I have setup) and update
this thread with the results.

-- Jon.

Paolo

Hi guys,

Sorry for the delay...

So first ill clarify what was the test, the test was to see the device
"Microsoft Hyper-V Virtual Machine Bus" in Windows Device Manager under
"System devices" with a state of "working properly".

It seems like it's ok to drop all the _PS* and _STA.

It seems to be functioning with single IRQ as well, it is worth noting
that even when i dropped the entire _CRS (so no IRQs resources are
required, the device was still showing that it's functioning, but I
suspect this might affect the child devices like hv-net and hv-scsi).

With that said I did run into a small issue I set-up Win10 1903 (aka
19H1) and it seems like VMBus now requires to have the following
features enabled:

HV_VP_RUNTIME_AVAILABLE
HV_TIME_REF_COUNT_AVAILABLE
HV_SYNIC_AVAILABLE
HV_SYNTIMERS_AVAILABLE
HV_APIC_ACCESS_AVAILABLE
HV_HYPERCALL_AVAILABLE
HV_VP_INDEX_AVAILABLE

So notice that previously only SYNIC and VPINDEX was needed, now you
need the whole thing so you need to run qemu with something like

-cpu
host,hv-relaxed,hv_spinlocks=0x1fff,hv_time,hv-vapic,hv-vpindex,hv-synic,hv-runtime,hv-stimer

The validation was done in winhv!WinHvpCheckPartitionPrivileges .

Paolo I noticed you have done a PULL request, would you like to wait on
it and we will submit a version with a single IRQ (selectable by user
property) and go with Igor's suggestion dropping _PS* and _STA (though
like I said before I prefer to mimic the original HyperV with it's
bugs, but I'll leave this decision to you).

Cheers,
-- Jon.

Re: [PATCH v3] mac_oldworld: Add machine ID register


On Sun, 14 Jun 2020, Mark Cave-Ayland wrote:

On 13/06/2020 18:57, BALATON Zoltan wrote:


The G3 beige machine has a machine ID register that is accessed by the
firmware to deternine the board config. Add basic emulation of it.

Signed-off-by: BALATON Zoltan 
---
v3: add empty write function in case anything tries to write reg

hw/ppc/mac_oldworld.c | 21 +
 1 file changed, 21 insertions(+)

diff --git a/hw/ppc/mac_oldworld.c b/hw/ppc/mac_oldworld.c
index 3812adc441..acaf468458 100644
--- a/hw/ppc/mac_oldworld.c
+++ b/hw/ppc/mac_oldworld.c
@@ -80,6 +80,22 @@ static void ppc_heathrow_reset(void *opaque)
 cpu_reset(CPU(cpu));
 }

+static uint64_t machine_id_read(void *opaque, hwaddr addr, unsigned size)
+{
+return (addr == 0 && size == 2 ? 0x3d8c : 0);
+}
+
+static void machine_id_write(void *opaque, hwaddr addr,
+ uint64_t val, unsigned size)
+{
+return;
+}
+
+const MemoryRegionOps machine_id_reg_ops = {
+.read = machine_id_read,
+.write = machine_id_write,
+};
+
 static void ppc_heathrow_init(MachineState *machine)
 {
 ram_addr_t ram_size = machine->ram_size;
@@ -93,6 +109,7 @@ static void ppc_heathrow_init(MachineState *machine)
 char *filename;
 int linux_boot, i;
 MemoryRegion *bios = g_new(MemoryRegion, 1);
+MemoryRegion *machine_id = g_new(MemoryRegion, 1);
 uint32_t kernel_base, initrd_base, cmdline_base = 0;
 int32_t kernel_size, initrd_size;
 PCIBus *pci_bus;
@@ -227,6 +244,10 @@ static void ppc_heathrow_init(MachineState *machine)
 }
 }

+memory_region_init_io(machine_id, OBJECT(machine), &machine_id_reg_ops,
+  NULL, "machine_id", 2);
+memory_region_add_subregion(get_system_memory(), 0xff04, machine_id);
+
 /* XXX: we register only 1 output pin for heathrow PIC */
 pic_dev = qdev_create(NULL, TYPE_HEATHROW);
 qdev_init_nofail(pic_dev);


I'm guessing this supersedes the version from the v2 patchset? Given that you're


Yes, I've realized that a write method is needed otherwise it will crash 
if something writes the reg. I've assumed it would check for NULL but 
seems it doesn't. I've found that out when adding similar code for a (yet 
unsubmitted) dummy screamer reg which was written so I've corrected this 
and resent only this patch. I've added the screamer reg to see if it would 
go farther but it seems it's missing i2c so cannot find RAM. I have a 
sketch to implement i2c in cuda but it does not work yet.



introducing a HeathrowMachineState in patch 5, I'd be inclined to store the
MemoryRegions there to prevent these references leaking after init(). A 
constant for
the address of the register would also be good here too.


Yes, this could be included in MachineState just I've done this before 
that and haven't thought about it. I might move it there. I'm not sure 
about the constant as this value is only used at this one place and for 
those I prefer writing the value directly as it's easier to read (no need 
to look up constant value) so I'd only use a constant for values needed 
more than once but could add one for this.


Regards,
BALATON Zoltan

Re: [PATCH v2 3/5] grackle: Set revision in PCI config to match hardware


On Sun, 14 Jun 2020, Mark Cave-Ayland wrote:

On 13/06/2020 14:36, BALATON Zoltan wrote:


Signed-off-by: BALATON Zoltan 
---
 hw/pci-host/grackle.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/hw/pci-host/grackle.c b/hw/pci-host/grackle.c
index 4b3af0c704..48d11f13ab 100644
--- a/hw/pci-host/grackle.c
+++ b/hw/pci-host/grackle.c
@@ -130,7 +130,7 @@ static void grackle_pci_class_init(ObjectClass *klass, void 
*data)
 k->realize   = grackle_pci_realize;
 k->vendor_id = PCI_VENDOR_ID_MOTOROLA;
 k->device_id = PCI_DEVICE_ID_MOTOROLA_MPC106;
-k->revision  = 0x00;
+k->revision  = 0x40;
 k->class_id  = PCI_CLASS_BRIDGE_HOST;
 /*
  * PCI-facing part of the host bridge, not usable without the


Out of curiosity does the BIOS you are using require this, or is it purely for
cosmetic purposes? I'm sure I've seen device trees with several different 
revisions
here...


Don't know, got it from here:

https://github.com/dingusdev/dingusppc/blob/master/devices/mpc106.h

Regards,
BALATON Zoltan

Re: [PATCH RFC 00/22] Support of Virtual CPU Hotplug for ARMv8 Arch

2020-06-14 Thread Marc Zyngier


Hi Salil,

On 2020-06-13 22:36, Salil Mehta wrote:

This patch-set introduces the virtual cpu hotplug support for ARMv8
architecture in QEMU. Idea is to be able to hotplug and hot-unplug the 
vcpus
while guest VM is running and no reboot is required. This does *not* 
makes any
assumption of the physical cpu hotplug availability within the host 
system but
rather tries to solve the problem at virtualizer/QEMU layer and by 
introducing
cpu hotplug hooks and event handling within the guest kernel. No 
changes are

required within the host kernel/KVM.

Motivation:
This allows scaling the guest VM compute capacity on-demand which would 
be

useful for the following example scenarios,
1. Vertical Pod Autoscaling[3][4] in the cloud: Part of the 
orchestration
   framework which could adjust resource requests (CPU and Mem 
requests) for

   the containers in a pod, based on usage.
2. Pay-as-you-grow Business Model: Infrastructure provider could 
allocate and
   restrict the total number of compute resources available to the 
guest VM
   according to the SLA(Service Level Agreement). VM owner could 
request for

   more compute to be hot-plugged for some cost.

Terminology:

(*) Present cpus: Total cpus with which guest has/will boot and are 
available
  to guest for use and can be onlined. Qemu 
parameter(-smp)
(*) Disabled cpus: Possible cpus which will not be available for the 
guest to
   use. These can be hotplugged and made present. These 
can be

   thought of as un-plugged vcpus. These will be included as
   part of sizing.
(*) Posssible cpus: Total vcpus which could ever exist in VM. This 
includes
booted cpus plus any cpus which could be later 
plugged.

- Qemu parameter(-maxcpus)
- Possible vcpus = Present vcpus (+) Disabled vcpus


Limitations of ARMv8 Architecture:

A. Physical Limitation to CPU Hotplug:
1. ARMv8 architecture does not support the concept of the physical cpu 
hotplug.
   The closest thing which is recomended to achieve the cpu hotplug on 
ARM is

   to bring down power state of the cpu using PSCI.


It isn't so much that the ARMv8 architecture doesn't support CPU 
hotplug. It is that CPU hotplug is largely out of the scope of the ARMv8 
architecture, which is a CPU architecture and not a system architecture. 
Yes, the lack of a comprehensive system architecture is *very* annoying, 
but let's put the blame where it belongs... ;-)



2. Other ARM components like GIC etc. have not been designed to realize
   physical cpu hotplug capability as of now.

B. Limitations of GIC to Support Virtual CPU Hotplug:
1. GIC requires various resources(related to GICR/redistributor, 
GICC/cpu
   interface etc) like memory regions to be fixed at the VM init time 
and these

   could not be changed later on after VM has inited.
2. Associations between GICC(GIC cpu interface) and vcpu get fixed at 
the VM
   init time and GIC does not allows to change this association once 
GIC has

   initialized.


There isn't an association, really. the GIC CPU interface is part of the 
CPU itself, and not an external entity. KVM doesn't split the two 
either. It is the association between the CPU and its redistributor that 
is being done. There is no architectural way to set this up this, so KVM 
just statically configures these based on the number of vcpus and the 
number/size of redistributor ranges.




C. Known Limitation of the KVM:
1. As of now KVM allows to create VCPUs but does not allows to delete 
the
   already created vcpus. QEMU already provides an interface to manage 
created

   vcpus at KVM level and then to re-use them.
2. Inconsistency in interpretation of the MPIDR generated by KVM for 
vcpus
   vis-a-vis SMT/threads. This does not looks to be compliant to the 
MPIDR
   format(SMT is present) as mentioned in the ARMv8 spec. (Please 
correct my

   understanding if I am wrong here?)


I'm unsure of which part of the architecture KVM doesn't follow when 
assigning a MPIDR to a vcpu. By having MPIDR_EL1.MT to 0, KVM tells the 
guest OS that vcpus having the same Aff3-1 fields are mostly 
independent.


This is because:
- we make no placement guarantee whatsoever (this is userspace's 
business)
- ARMv8.2 CPUs designed by ARM (as opposed to architecture licensees) 
always set this bit to 1 as they can hypothetically be coupled to SMT 
CPUs in a big-little system. This makes MT totally meaningless.
- the one SMT implementation available in the wild (ThunderX-2) is 
broken enough that you really should consider turning SMT off (see 
CAVIUM_TX2_ERRATUM_219)
- KVM actively prevents the sharing of resources such as TLBs across 
vcpus


Given the above, I fail to see the point in setting the SMT bit to 
anything but 0.





Workaround to the problems mentioned in Section B & C1:
1. We pre-size the GIC with possible vcpus at VM init time
2. Pre-create all possible vcpus at KVM and associate

Re: [PATCH v3] mac_oldworld: Add machine ID register

On 13/06/2020 18:57, BALATON Zoltan wrote:

> The G3 beige machine has a machine ID register that is accessed by the
> firmware to deternine the board config. Add basic emulation of it.
> 
> Signed-off-by: BALATON Zoltan 
> ---
> v3: add empty write function in case anything tries to write reg
> 
> hw/ppc/mac_oldworld.c | 21 +
>  1 file changed, 21 insertions(+)
> 
> diff --git a/hw/ppc/mac_oldworld.c b/hw/ppc/mac_oldworld.c
> index 3812adc441..acaf468458 100644
> --- a/hw/ppc/mac_oldworld.c
> +++ b/hw/ppc/mac_oldworld.c
> @@ -80,6 +80,22 @@ static void ppc_heathrow_reset(void *opaque)
>  cpu_reset(CPU(cpu));
>  }
> 
> +static uint64_t machine_id_read(void *opaque, hwaddr addr, unsigned size)
> +{
> +return (addr == 0 && size == 2 ? 0x3d8c : 0);
> +}
> +
> +static void machine_id_write(void *opaque, hwaddr addr,
> + uint64_t val, unsigned size)
> +{
> +return;
> +}
> +
> +const MemoryRegionOps machine_id_reg_ops = {
> +.read = machine_id_read,
> +.write = machine_id_write,
> +};
> +
>  static void ppc_heathrow_init(MachineState *machine)
>  {
>  ram_addr_t ram_size = machine->ram_size;
> @@ -93,6 +109,7 @@ static void ppc_heathrow_init(MachineState *machine)
>  char *filename;
>  int linux_boot, i;
>  MemoryRegion *bios = g_new(MemoryRegion, 1);
> +MemoryRegion *machine_id = g_new(MemoryRegion, 1);
>  uint32_t kernel_base, initrd_base, cmdline_base = 0;
>  int32_t kernel_size, initrd_size;
>  PCIBus *pci_bus;
> @@ -227,6 +244,10 @@ static void ppc_heathrow_init(MachineState *machine)
>  }
>  }
> 
> +memory_region_init_io(machine_id, OBJECT(machine), &machine_id_reg_ops,
> +  NULL, "machine_id", 2);
> +memory_region_add_subregion(get_system_memory(), 0xff04, machine_id);
> +
>  /* XXX: we register only 1 output pin for heathrow PIC */
>  pic_dev = qdev_create(NULL, TYPE_HEATHROW);
>  qdev_init_nofail(pic_dev);

I'm guessing this supersedes the version from the v2 patchset? Given that you're
introducing a HeathrowMachineState in patch 5, I'd be inclined to store the
MemoryRegions there to prevent these references leaking after init(). A 
constant for
the address of the register would also be good here too.


ATB,

Mark.

Re: [PATCH v2 5/5] mac_oldworld: Map macio to expected address at reset

On 13/06/2020 14:36, BALATON Zoltan wrote:

> Add a reset function that maps macio to the address expected by the
> firmware of the board at startup.
> 
> Signed-off-by: BALATON Zoltan 
> ---
>  hw/ppc/mac.h  | 12 
>  hw/ppc/mac_oldworld.c | 17 +++--
>  2 files changed, 27 insertions(+), 2 deletions(-)
> 
> diff --git a/hw/ppc/mac.h b/hw/ppc/mac.h
> index 6af87d1fa0..35a5f21163 100644
> --- a/hw/ppc/mac.h
> +++ b/hw/ppc/mac.h
> @@ -57,6 +57,18 @@
>  #define OLDWORLD_IDE1_IRQ  0xe
>  #define OLDWORLD_IDE1_DMA_IRQ  0x3
>  
> +/* g3beige machine */
> +#define TYPE_HEATHROW_MACHINE MACHINE_TYPE_NAME("g3beige")
> +#define HEATHROW_MACHINE(obj) OBJECT_CHECK(HeathrowMachineState, (obj), \
> +   TYPE_HEATHROW_MACHINE)
> +
> +typedef struct HeathrowMachineState {
> +/*< private >*/
> +MachineState parent;
> +
> +PCIDevice *macio_pci;
> +} HeathrowMachineState;
> +
>  /* New World IRQs */
>  #define NEWWORLD_CUDA_IRQ  0x19
>  #define NEWWORLD_PMU_IRQ   0x19
> diff --git a/hw/ppc/mac_oldworld.c b/hw/ppc/mac_oldworld.c
> index 9138752ccb..fa9527410d 100644
> --- a/hw/ppc/mac_oldworld.c
> +++ b/hw/ppc/mac_oldworld.c
> @@ -73,6 +73,15 @@ static uint64_t translate_kernel_address(void *opaque, 
> uint64_t addr)
>  return (addr & 0x0fff) + KERNEL_LOAD_ADDR;
>  }
>  
> +static void ppc_heathrow_reset(MachineState *machine)
> +{
> +HeathrowMachineState *m = HEATHROW_MACHINE(machine);
> +
> +qemu_devices_reset();
> +pci_default_write_config(m->macio_pci, PCI_COMMAND, PCI_COMMAND_MEMORY, 
> 2);
> +pci_default_write_config(m->macio_pci, PCI_BASE_ADDRESS_0, 0xf300, 
> 4);
> +}
> +
>  static void ppc_heathrow_cpu_reset(void *opaque)
>  {
>  PowerPCCPU *cpu = opaque;
> @@ -91,6 +100,7 @@ const MemoryRegionOps machine_id_reg_ops = {
>  
>  static void ppc_heathrow_init(MachineState *machine)
>  {
> +HeathrowMachineState *hm = HEATHROW_MACHINE(machine);
>  ram_addr_t ram_size = machine->ram_size;
>  const char *kernel_filename = machine->kernel_filename;
>  const char *kernel_cmdline = machine->kernel_cmdline;
> @@ -298,7 +308,8 @@ static void ppc_heathrow_init(MachineState *machine)
>  ide_drive_get(hd, ARRAY_SIZE(hd));
>  
>  /* MacIO */
> -macio = OLDWORLD_MACIO(pci_create(pci_bus, -1, TYPE_OLDWORLD_MACIO));
> +hm->macio_pci = pci_create(pci_bus, -1, TYPE_OLDWORLD_MACIO);
> +macio = OLDWORLD_MACIO(hm->macio_pci);
>  dev = DEVICE(macio);
>  qdev_prop_set_uint64(dev, "frequency", tbfreq);
>  object_property_set_link(OBJECT(macio), OBJECT(pic_dev), "pic",
> @@ -450,6 +461,7 @@ static void heathrow_class_init(ObjectClass *oc, void 
> *data)
>  
>  mc->desc = "Heathrow based PowerMAC";
>  mc->init = ppc_heathrow_init;
> +mc->reset = ppc_heathrow_reset;
>  mc->block_default_type = IF_IDE;
>  mc->max_cpus = MAX_CPUS;
>  #ifndef TARGET_PPC64
> @@ -466,9 +478,10 @@ static void heathrow_class_init(ObjectClass *oc, void 
> *data)
>  }
>  
>  static const TypeInfo ppc_heathrow_machine_info = {
> -.name  = MACHINE_TYPE_NAME("g3beige"),
> +.name  = TYPE_HEATHROW_MACHINE,
>  .parent= TYPE_MACHINE,
>  .class_init= heathrow_class_init,
> +.instance_size = sizeof(HeathrowMachineState),
>  .interfaces = (InterfaceInfo[]) {
>  { TYPE_FW_PATH_PROVIDER },
>  { }

This doesn't feel right to me - either the PROM should be configuring the BARs 
as it
requires before trying to use the macio device, or the macio device has a fixed
mapping. Possibly the latter could be true given that things are so early in 
the boot
process?

Are there any hints in the macio "reg" and "address" properties suggesting that 
this
might be the case?


ATB,

Mark.

Re: [PATCH v2 4/5] mac_oldworld: Rename ppc_heathrow_reset reset to ppc_heathrow_cpu_reset

On 13/06/2020 14:36, BALATON Zoltan wrote:

> This function resets a CPU not the whole machine so reflect that in
> its name.
> 
> Signed-off-by: BALATON Zoltan 
> ---
>  hw/ppc/mac_oldworld.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/hw/ppc/mac_oldworld.c b/hw/ppc/mac_oldworld.c
> index 4dd872c1a3..9138752ccb 100644
> --- a/hw/ppc/mac_oldworld.c
> +++ b/hw/ppc/mac_oldworld.c
> @@ -73,7 +73,7 @@ static uint64_t translate_kernel_address(void *opaque, 
> uint64_t addr)
>  return (addr & 0x0fff) + KERNEL_LOAD_ADDR;
>  }
>  
> -static void ppc_heathrow_reset(void *opaque)
> +static void ppc_heathrow_cpu_reset(void *opaque)
>  {
>  PowerPCCPU *cpu = opaque;
>  
> @@ -127,7 +127,7 @@ static void ppc_heathrow_init(MachineState *machine)
>  
>  /* Set time-base frequency to 16.6 Mhz */
>  cpu_ppc_tb_init(env,  TBFREQ);
> -qemu_register_reset(ppc_heathrow_reset, cpu);
> +qemu_register_reset(ppc_heathrow_cpu_reset, cpu);
>  }
>  
>  /* allocate RAM */

Technically this is a board level reset which just happens to pass the CPU for 
the
opaque, so I'm not quite sold on this one (as an example look at mac_newworld.c 
where
using the ELF load address for the PROM would require a dynamic NIP which is 
most
conveniently accessed via a MachineState).


ATB,

Mark.

Re: [PATCH v2 3/5] grackle: Set revision in PCI config to match hardware