Re: [PATCH 2/4] tests/qtest: Use qtest_get_arch_bits()

2023-10-10 Thread Ani Sinha
r than this, Reviewed-by: Ani Sinha > >> Signed-off-by: Philippe Mathieu-Daudé >> --- >> tests/qtest/arm-cpu-features.c | 49 -- >> tests/qtest/bios-tables-test.c | 16 +-- >> 2 files changed, 30 insertions(+), 35 deletions(-) > > Thomas >

Re: [PATCH v2 4/6] python/machine: use socketpair() for console connections

2023-07-27 Thread Ani Sinha
> On 27-Jul-2023, at 11:22 AM, Ani Sinha wrote: > > > >> On 26-Jul-2023, at 10:51 PM, John Snow wrote: >> >> >> >> On Wed, Jul 26, 2023, 6:50 AM Ani Sinha wrote: >> >> >>> On 25-Jul-2023, at 11:33 PM, John Snow wrote: &

Re: [PATCH v2 4/6] python/machine: use socketpair() for console connections

2023-07-27 Thread Ani Sinha
> On 26-Jul-2023, at 10:51 PM, John Snow wrote: > > > > On Wed, Jul 26, 2023, 6:50 AM Ani Sinha wrote: > > > > On 25-Jul-2023, at 11:33 PM, John Snow wrote: > > > > Create a socketpair for the console output. This should help eliminate > &

Re: [PATCH v2 3/6] python/console_socket: accept existing FD in initializer

2023-07-26 Thread Ani Sinha
> On 25-Jul-2023, at 11:33 PM, John Snow wrote: > > Useful if we want to use ConsoleSocket() for a socket created by > socketpair(). > > Signed-off-by: John Snow Reviewed-by: Ani Sinha > --- > python/qemu/machine/console_socket.py | 29 +++-

Re: [PATCH v2 4/6] python/machine: use socketpair() for console connections

2023-07-26 Thread Ani Sinha
QEMU under "server,nowait". > > Signed-off-by: John Snow Thanks for doing this. I recall we spoke about this late last year in the context of fixing my bios-bits avocado test and adding a console output there. Except the concern below, Reviewed-by: Ani Sinha > ---

Re: [PATCH v2 2/6] python/machine: close sock_pair in cleanup path

2023-07-26 Thread Ani Sinha
be handled by the garbage collector, but that can happen at >> unpredictable times. Nicer to just clean them up synchronously on the >> exit path, here. >> >> Signed-off-by: John Snow Reviewed-by: Ani Sinha >> --- >> python/qemu/machine/machine.py | 5 + >> 1 fil

Re: [PATCH v2 1/6] python/machine: move socket setup out of _base_args property

2023-07-26 Thread Ani Sinha
> On 25-Jul-2023, at 11:33 PM, John Snow wrote: > > This property isn't meant to do much else besides return a list of > strings, so move this setup back out into _pre_launch(). > > Signed-off-by: John Snow Reviewed-by: Ani Sinha > --- > python/qemu/machine/machi

Re: [PATCH 4/4] pci: Compare function number and ARI next function number

2023-07-11 Thread Ani Sinha
> On 01-Jul-2023, at 12:31 PM, Akihiko Odaki wrote: > > The function number must be lower than the next function number > advertised with ARI. > > Signed-off-by: Akihiko Odaki > --- > hw/pci/pci.c | 15 +++ > 1 file changed, 15 insertions(+) > > diff --git a/hw/pci/pci.c

Re: [PATCH v6 2/2] pcie: Specify 0 for ARI next function numbers

2023-07-10 Thread Ani Sinha
here > > Fixes: 2503461691 ("pcie: Add some SR/IOV API documentation in > docs/pcie_sriov.txt") > Fixes: 44c2c09488 ("hw/nvme: Add support for SR-IOV") > Fixes: 3a977deebe ("Intrdocue igb device emulation") > Signed-off-by: Akihiko Odaki modulo the abo

Re: [PATCH v6 1/2] pcie: Use common ARI next function number

2023-07-10 Thread Ani Sinha
> On 10-Jul-2023, at 1:38 PM, Akihiko Odaki wrote: > > Currently the only implementers of ARI is SR-IOV devices, and they > behave similar. Share the ARI next function number. > > Signed-off-by: Akihiko Odaki Reviewed-by: Ani Sinha > --- > docs/pcie_sriov.txt |

Re: [PATCH v5 2/2] pcie: Specify 0 for ARI next function numbers

2023-07-10 Thread Ani Sinha
> On 10-Jul-2023, at 3:14 PM, Michael S. Tsirkin wrote: > > On Mon, Jul 10, 2023 at 02:49:55PM +0530, Ani Sinha wrote: >> >> >>> On 10-Jul-2023, at 2:46 PM, Michael S. Tsirkin wrote: >>> >>> On Mon, Jul 10, 2023 at 01:21:50PM +0530, Ani Sin

Re: [PATCH v5 2/2] pcie: Specify 0 for ARI next function numbers

2023-07-10 Thread Ani Sinha
> On 10-Jul-2023, at 2:46 PM, Michael S. Tsirkin wrote: > > On Mon, Jul 10, 2023 at 01:21:50PM +0530, Ani Sinha wrote: >> >> >>> On 05-Jul-2023, at 7:54 AM, Akihiko Odaki wrote: >>> >>> The current implementers of ARI are all SR-IOV

Re: [PATCH v5 2/2] pcie: Specify 0 for ARI next function numbers

2023-07-10 Thread Ani Sinha
> On 10-Jul-2023, at 1:23 PM, Akihiko Odaki wrote: > > On 2023/07/10 16:51, Ani Sinha wrote: >>> On 05-Jul-2023, at 7:54 AM, Akihiko Odaki wrote: >>> >>> The current implementers of ARI are all SR-IOV devices. The ARI next >>> function numb

Re: [PATCH v5 2/2] pcie: Specify 0 for ARI next function numbers

2023-07-10 Thread Ani Sinha
> On 05-Jul-2023, at 7:54 AM, Akihiko Odaki wrote: > > The current implementers of ARI are all SR-IOV devices. The ARI next > function number field is undefined for VF according to PCI Express Base > Specification Revision 5.0 Version 1.0 section 9.3.7.7. The PF should > end the linked list

Re: [PATCH 0/3] pci: Fix ARI next function numbers

2023-07-02 Thread Ani Sinha
> On 02-Jul-2023, at 2:03 PM, Akihiko Odaki wrote: > > The ARI next function number field is undefined for VF. The PF should > end the linked list formed with the field by specifying 0. > > Supersedes: <20230701070133.24877-1-akihiko.od...@daynix.com> > ("[PATCH 0/4] pci: Compare function

Re: [PATCH 1/4] docs: Fix next function numbers in SR/IOV documentation

2023-07-01 Thread Ani Sinha
> On 01-Jul-2023, at 12:31 PM, Akihiko Odaki wrote: > > The next function numbers are expected to form a linked list ending with > 0. > > Fixes: 2503461691 ("pcie: Add some SR/IOV API documentation in > docs/pcie_sriov.txt") > Signed-off-by: Akihiko Odaki > --- > docs/pcie_sriov.txt | 5

[PATCH v2 2/2] tests/lcitool: Add mtools and xorriso and remove genisoimage as dependencies

2023-05-04 Thread Ani Sinha
for existence of only xorrisofs. CC: m...@redhat.com CC: berra...@redhat.com Signed-off-by: Ani Sinha --- .gitlab-ci.d/cirrus/freebsd-13.vars| 2 +- .gitlab-ci.d/cirrus/macos-12.vars | 2 +- tests/docker/dockerfiles/alpine.docker | 3 ++- tests/docker

Re: [PATCH 06/17] sphinx/qapidoc: Do not emit TODO sections into user manuals

2023-04-28 Thread Ani Sinha
ommand effectively bypasses QAPI completely due to its > # "additional arguments" business. It shouldn't have been added to > # the schema in this form. It should be qapified properly, or > # replaced by a properly qapified command. > > Likewise. >

Re: [PATCH 07/17] qapi: Tidy up a slightly awkward TODO comment

2023-04-28 Thread Ani Sinha
t TODO sections into > user manuals) lets me move it into the doc comment as a TODO section. > > Signed-off-by: Markus Armbruster > Reviewed-by: Ani Sinha > --- > qapi/migration.json | 5 +++-- > 1 file changed, 3 insertions(+), 2 deletions(-) > > diff --git a/qapi/mi

Re: [PATCH] virtio-blk: Fix clean up of host notifiers for single MR transaction.

2021-12-09 Thread Ani Sinha
l refers to the first > loop variable within the second loop body. > > Fixes: d0267da61489 ("virtio-blk: Configure all host notifiers in a > single MR transaction") > Signed-off-by: Mark Mielke Reviewed-by: Ani Sinha > --- > hw/block/dataplane/virtio-blk.c | 2 +