Re: [Qemu-devel] d_off field in struct dirent and 32-on-64 emulation

[Florian Weimer]

* Dmitry V. Levin:

> On Thu, Dec 27, 2018 at 06:18:19PM +0100, Florian Weimer wrote:
>> We have a bit of an interesting problem with respect to the d_off
>> field in struct dirent.
>> 
>> When running a 64-bit kernel on certain file systems, notably ext4,
>> this field uses the full 63 bits even for small directories (strace -v
>> output, wrapped here for readability):
>> 
>> getdents(3, [
>>   {d_ino=1494304, d_off=3901177228673045825, d_reclen=40,
>> d_name="authorized_keys", d_type=DT_REG},
>>   {d_ino=1494277, d_off=7491915799041650922, d_reclen=24,
>> d_name=".", d_type=DT_DIR},
>>   {d_ino=1314655, d_off=9223372036854775807, d_reclen=24,
>> d_name="..", d_type=DT_DIR}
>> ], 32768) = 88
>> 
>> When running in 32-bit compat mode, this value is somehow truncated to
>> 31 bits, for both the getdents and the getdents64 (!) system call (at
>> least on i386).
>
> Why getdents64 system call is affected by this truncation,
> isn't it a kernel bug that has to be fixed in the kernel instead?

It's required because POSIX specifies that telldir and seekdir use
long int (and not off_t) as the seek offset.  If the kernel does not
truncate while keeping a useful value, these functions would turn
unusable.

Re: [Qemu-devel] [PATCH for-4.0 v4 4/4] i386: allow to load initrd below 4G for recent linux

[Li Zhijian]

On 12/28/2018 4:31 AM, Eduardo Habkost wrote:

On Fri, Dec 21, 2018 at 11:10:30AM -0500, Michael S. Tsirkin wrote:

On Thu, Dec 06, 2018 at 10:32:13AM +0800, Li Zhijian wrote:
  
  /* highest address for loading the initrd */

-if (protocol >= 0x203) {
+if (protocol >= 0x20c &&
+lduw_p(header+0x236) & XLF_CAN_BE_LOADED_ABOVE_4G) {
+/*
+ * Although kernel allows initrd loading to above 4G,
+ * it just makes it as large as possible while still staying below 4G
+ * since current BIOS always loads initrd below pcms->below_4g_mem_size
+ */
+initrd_max = UINT32_MAX;
+} else if (protocol >= 0x203) {
  initrd_max = ldl_p(header+0x22c);
  } else {
  initrd_max = 0x37ff;


I still have trouble understanding the above.
Anyone else wants to comment / help rephrase the comment
and commit log so it's readable?


The comment seems to contradict what I see on the code:

| Although kernel allows initrd loading to above 4G,

Sounds correct.


| it just makes it as large as possible while still staying below 4G

I'm not a native English speaker, but I believe "it" here should
be interpreted as "the kernel", which would be incorrect.  It's
this QEMU function that limits initrd_max to a uint32 value, not
the kernel.


| since current BIOS always loads initrd below pcms->below_4g_mem_size

I don't know why the BIOS is mentioned here.  The
below_4g_mem_size limit comes from these 2 lines inside
load_linux():

 if (initrd_max >= pcms->below_4g_mem_size - pcmc->acpi_data_size) {
 initrd_max = pcms->below_4g_mem_size - pcmc->acpi_data_size - 1;
 }
In addition to that, initrd_max is uint32_t simply because QEMU
doesn't support the 64-bit boot protocol (specifically the
ext_ramdisk_image field),


Thanks for explaining this :), i'm not clear before.




so all talk about below_4g_mem_size
seems to be just a distraction.

All that said, I miss one piece of information here: is
XLF_CAN_BE_LOADED_ABOVE_4G really supposed to override
header+0x22c?  linux/Documentation/x86/boot.txt isn't clear about
that.  Is there any reference that can help us confirm this?


Good question.

Since i'm not familiar with boot protocol, at the beginning, i also CCed to 
LKML for helps
https://lkml.org/lkml/2018/11/10/82

Ingo said:
> If XLF_CAN_BE_LOADED_ABOVE_4G is not > set, then you most likely 
are on a 32-bit kernel and there are more > fundamental limits (even 
if you were to load it above the 2 GB mark, you > would be limited by 
the size of kernel memory.) > > So, in case you are wondering: the 
bootloader that broke when setting > the initrd_max field above 2 GB 
was, of course, Grub. > > So just use XLF_CAN_BE_LOADED_ABOVE_4G. 
There is no need for a new flag > or new field. That's nice, and 
that's the best solution!


that make me to believe that if XLF_CAN_BE_LOADED_ABOVE_4G is set, BELOW_4G is 
allowed too.

if above is credible, might be we can update the comments like:
---
QEMU doesn't support the 64-bit boot protocol (specifically the
ext_ramdisk_image field).

In addition, kernel allows to load initrd above 4G if 
XLF_CAN_BE_LOADED_ABOVE_4G is set,
so we believe that load initrd below 4G is allowed too.

For simplicity, so just set initrd_max to UINT32_MAX is enough and safe.
---
 
Thanks

Zhijian

Re: [Qemu-devel] d_off field in struct dirent and 32-on-64 emulation

[Andreas Dilger]

On Dec 27, 2018, at 10:41 AM, Peter Maydell  wrote:
> 
> On Thu, 27 Dec 2018 at 17:19, Florian Weimer  wrote:
>> We have a bit of an interesting problem with respect to the d_off
>> field in struct dirent.
>> 
>> When running a 64-bit kernel on certain file systems, notably ext4,
>> this field uses the full 63 bits even for small directories (strace -v
>> output, wrapped here for readability):
>> 
>> getdents(3, [
>>  {d_ino=1494304, d_off=3901177228673045825, d_reclen=40, 
>> d_name="authorized_keys", d_type=DT_REG},
>>  {d_ino=1494277, d_off=7491915799041650922, d_reclen=24, d_name=".", 
>> d_type=DT_DIR},
>>  {d_ino=1314655, d_off=9223372036854775807, d_reclen=24, d_name="..", 
>> d_type=DT_DIR}
>> ], 32768) = 88
>> 
>> When running in 32-bit compat mode, this value is somehow truncated to
>> 31 bits, for both the getdents and the getdents64 (!) system call (at
>> least on i386).
> 
> Yes -- look for hash2pos() and friends in fs/ext4/dir.c.
> The ext4 code in the kernel uses a 32 bit hash if (a) the kernel
> is 32 bit (b) this is a compat syscall (b) some other bit of
> the kernel asked it to via the FMODE_32BITHASH flag (currently only
> NFS does that I think).
> 
> As you note, this causes breakage for userspace programs which
> need to implement an API/ABI with 32-bit offset but which only
> have access to the kernel's 64-bit offset API/ABI.

This is (IMHO) a bit of an oxymoron, isn't it?  Applications using
the 64-bit API, but storing the value in a 32-bit field?  The same
problem would exist for filesystems with 64-bit inodes or 64-bit
file offsets trying to store these values in 32-bit variables.
It might work most of the time, but it can also break randomly.

> I think the best fix for this would be for the kernel to either
> (a) consistently use a 32-bit hash or (b) to provide an API
> so that userspace can use the FMODE_32BITHASH flag the way
> that kernel-internal users already can.

It would be relatively straight forward to add a "32bitapi" mount
option to return a 32-bit directory hash to userspace for operations
on that mountpoint (ext4 doesn't have 64-bit inode numbers yet).
However, I can't think of an easy way to do this on a per-process
basis without just having it call the 32-bit API directly.

> I couldn't think of or find any existing way for userspace
> to get the right results here, which is why
> 32-bit-guest-on-64-bit-host QEMU doesn't work on these filesystems
> (depending on what exactly the guest's libc etc do).
> 
>> the 32-bit getdents system call emulation in a 64-bit qemu-user
>> process would just silently truncate the d_off field as part of
>> the translation, not reporting an error.
>> [...]
>> This truncation has always been a bug; it breaks telldir/seekdir
>> at least in some cases.
> 
> Yes; you can't fit a quart into a pint pot, so if the guest
> only handles 32-bit offsets then truncation is about all we
> can do. This works fine if offsets are offsets, assuming the
> directory isn't so enormous it would have broken the guest
> anyway. I'm not aware of any issues with this other than the
> oddball ext4 offsets-are-hashes situation -- could you expand
> on the telldir/seekdir issue? (I suppose we should probably
> make QEMU's syscall emulation layer return "no more entries"
> rather than entries with truncated hashes.)

For ext4 at least, you could just shift the high 32-bit part of
the 64-bit hash down into a 32-bit value in telldir(), and
shift it back up when seekdir() is called.

Cheers, Andreas







signature.asc
Description: Message signed with OpenPGP

Re: [Qemu-devel] [Spice-devel] Always get Invalid password while trying to connect to spice server

[Niccolò Belli]

On mercoledì 26 dicembre 2018 13:38:28 CET, Frediano Ziglio wrote:
Yes, this looks like a format string error in the upper (not 
into spice) layer.


This potentially is a security problem.


Considering the spice server is exposed to the internet this is definitely 
worth investigating.


The specific '%' character could be the issue, can you try 
others ('!', '@' and

so on) ?


I tried several other special characters and they all seems to work, expect 
for "Password&&" which gets converted to "Password" (if I type 
"Password" it works).


Niccolo'

Re: [Qemu-devel] [PATCH v3 1/2] intel-iommu: differentiate host address width from IOVA address width.

[Yu Zhang]

On Thu, Dec 27, 2018 at 01:14:11PM -0200, Eduardo Habkost wrote:
> On Wed, Dec 26, 2018 at 01:30:00PM +0800, Yu Zhang wrote:
> > On Tue, Dec 25, 2018 at 11:56:19AM -0500, Michael S. Tsirkin wrote:
> > > On Sat, Dec 22, 2018 at 09:11:26AM +0800, Yu Zhang wrote:
> > > > On Fri, Dec 21, 2018 at 02:02:28PM -0500, Michael S. Tsirkin wrote:
> > > > > On Sat, Dec 22, 2018 at 01:37:58AM +0800, Yu Zhang wrote:
> > > > > > On Fri, Dec 21, 2018 at 12:04:49PM -0500, Michael S. Tsirkin wrote:
> > > > > > > On Sat, Dec 22, 2018 at 12:09:44AM +0800, Yu Zhang wrote:
> > > > > > > > Well, my understanding of the vt-d spec is that the address 
> > > > > > > > limitation in
> > > > > > > > DMAR are referring to the same concept of CPUID.MAXPHYSADDR. I 
> > > > > > > > do not think
> > > > > > > > there's any different in the native scenario. :)
> > > > > > > 
> > > > > > > I think native machines exist on which the two values are 
> > > > > > > different.
> > > > > > > Is that true?
> > > > > > 
> > > > > > I think the answer is not. My understanding is that HAW(host 
> > > > > > address wdith) is
> > > > > > the maximum physical address width a CPU can detects(by 
> > > > > > cpuid.0x8008).
> > > > > > 
> > > > > > I agree there are some addresses the CPU does not touch, but they 
> > > > > > are still in
> > > > > > the physical address space, and there's only one physical address 
> > > > > > space...
> > > > > > 
> > > > > > B.R.
> > > > > > Yu
> > > > > 
> > > > > Ouch I thought we are talking about the virtual address size.
> > > > > I think I did have a box where VTD's virtual address size was
> > > > > smaller than CPU's.
> > > > > For physical one - we just need to make it as big as max supported
> > > > > memory right?
> > > > 
> > > > Well, my understanding of the physical one is the maximum physical 
> > > > address
> > > > width. Sorry, this explain seems nonsense... I mean, it's not just about
> > > > the max supported memory, but also covers MMIO. It shall be detectable
> > > > from cpuid, or ACPI's DMAR table, instead of calculated by the max 
> > > > memory
> > > > size. One common usage of this value is to tell the paging structure 
> > > > entries(
> > > > CPU's or IOMMU's) which bits shall be reserved. There are also some 
> > > > registers
> > > > e.g. apic base reg etc, whose contents are physical addresses, 
> > > > therefore also
> > > > need to follow the similar requirement for the reserved bits.
> > > > 
> > > > So I think the correct direction might be to define this property in the
> > > > machine status level, instead of the CPU level. Is this reasonable to 
> > > > you?
> > > 
> > > At that level yes. But isn't this already specified by "pci-hole64-end"?
> > 
> > But this value is set by guest firmware? Will PCI hotplug change this 
> > address?
> > 
> > @Eduardo, do you have any plan to calculate the phys-bits by 
> > "pci-hole64-end"?
> > Or introduce another property, say "max-phys-bits" in machine status?
> 
> I agree it may make sense to make the machine code control
> phys-bits instead of the CPU object.  A machine property sounds
> like the simplest solution.
> 
> But I don't think we can have a meaningful discussion about
> implementation if we don't agree about the command-line
> interface.  We must decide what will happen to the CPU and iommu
> physical address width in cases like:

Thanks, Eduardo.

What about we just use "-machine phys-bits=52", and remove the
"phys-bits" from CPU parameter?

> 
>   $QEMU -device intel-iommu
>   $QEMU -cpu ...,phys-bits=50 -device intel-iommu
>   $QEMU -cpu ...,host-phys-bits=on -device intel-iommu
>   $QEMU -machine phys-bits=50 -device intel-iommu
>   $QEMU -machine phys-bits=50 -cpu ...,phys-bits=48 -device intel-iommu
> 
> -- 
> Eduardo
> 

B.R.
Yu

Re: [Qemu-devel] d_off field in struct dirent and 32-on-64 emulation

[Dmitry V. Levin]

On Thu, Dec 27, 2018 at 06:18:19PM +0100, Florian Weimer wrote:
> We have a bit of an interesting problem with respect to the d_off
> field in struct dirent.
> 
> When running a 64-bit kernel on certain file systems, notably ext4,
> this field uses the full 63 bits even for small directories (strace -v
> output, wrapped here for readability):
> 
> getdents(3, [
>   {d_ino=1494304, d_off=3901177228673045825, d_reclen=40, 
> d_name="authorized_keys", d_type=DT_REG},
>   {d_ino=1494277, d_off=7491915799041650922, d_reclen=24, d_name=".", 
> d_type=DT_DIR},
>   {d_ino=1314655, d_off=9223372036854775807, d_reclen=24, d_name="..", 
> d_type=DT_DIR}
> ], 32768) = 88
> 
> When running in 32-bit compat mode, this value is somehow truncated to
> 31 bits, for both the getdents and the getdents64 (!) system call (at
> least on i386).

Why getdents64 system call is affected by this truncation,
isn't it a kernel bug that has to be fixed in the kernel instead?


-- 
ldv


signature.asc
Description: PGP signature

Re: [Qemu-devel] [PATCH v2 00/52] Audio 5.1 patches

[Programmingkid]

> On Dec 27, 2018, at 8:33 AM, Kővágó Zoltán  wrote:
> 
> Hi,
> 
> I've pushed it to my github (modulo some random fixes not yet on the
> mailing list):
> https://github.com/DirtYiCE/qemu/tree/audio-51-2018
> 
> I don't have a mac so I have no idea whether it works or not.
> 
> Regards,
> Zoltan
> 
> On 2018-12-26 12:24, Programmingkid wrote:
>> 
>>> On Dec 23, 2018, at 3:52 PM, qemu-devel-requ...@nongnu.org wrote:
>>> 
>>> Message: 4
>>> Date: Sun, 23 Dec 2018 21:51:36 +0100
>>> From: "=?UTF-8?q?K=C5=91v=C3=A1g=C3=B3=2C=20Zolt=C3=A1n?="
>>> 
>>> To: qemu-devel@nongnu.org
>>> Cc: Gerd Hoffmann 
>>> Subject: [Qemu-devel] [PATCH v2 00/52] Audio 5.1 patches
>>> Message-ID: 
>>> Content-Type: text/plain; charset=UTF-8
>>> 
>>> Hi,
>>> 
>>> I've updated my audio patchset to the current git master. Other than that 
>>> not
>>> much happened since my last update [1], fixed a few small problems that I
>>> noticed while rebasing my patches.
>>> 
>>> Please review.
>> 
>> 
>> 
>> Hi I would like to run your patches. Do you have a repository that I may 
>> clone? 
>> 
>> Also have you been able to test these patches using a Mac OS X guest yet? 
>> 
>> Thank you.
>> 
> 

Hi, thanks for the link. This is what I did:

 - git clone https://github.com/DirtYiCE/qemu.git
 - git checkout audio-51-2018
 - ./configure --target-list=ppc-softmmu
 - make -j 4

The result was unfortunately some errors:

  CC  audio/coreaudio.o
audio/coreaudio.c:413:49: error: unknown type name 'HWVocieOut'; did you mean
  'HWVoiceOut'?
COREAUDIO_WRAPPER_FUNC(get_buffer_out, void *, (HWVocieOut *hw, size_t *size),
^~
HWVoiceOut


audio/coreaudio.c:578:29: error: passing 'struct audio_pcm_info' to parameter of
  incompatible type 'struct audio_pcm_info *'; take the address with &
coreaudio_get_flags(hw->info, as);
^~~~
&

Re: [Qemu-devel] [PATCH v2 00/52] Audio 5.1 patches

[Philippe Mathieu-Daudé]

Hi John,

On 12/26/18 12:24 PM, Programmingkid wrote:
>> On Dec 23, 2018, at 3:52 PM, qemu-devel-requ...@nongnu.org wrote:
>>
>> Message: 4
>> Date: Sun, 23 Dec 2018 21:51:36 +0100
>> From: "=?UTF-8?q?K=C5=91v=C3=A1g=C3=B3=2C=20Zolt=C3=A1n?="
>>  
>> To: qemu-devel@nongnu.org
>> Cc: Gerd Hoffmann 
>> Subject: [Qemu-devel] [PATCH v2 00/52] Audio 5.1 patches
>> Message-ID: 

^ [*]

>> Content-Type: text/plain; charset=UTF-8
>>
> 
> 
> Hi I would like to run your patches. Do you have a repository that I may 
> clone? 

Usually you can take series posted to the list via patchew, using the
following pattern:

https://github.com/patchew-project/qemu/releases/tag/patchew/$MESSAGE_ID

using the cover mail message ID without the angle brackets < >.

Here this would be:

https://github.com/patchew-project/qemu/releases/tag/patchew/cover.1545598229.git.dirty.ice...@gmail.com

but sadly patchew failed at applying this series :/

Re: [Qemu-devel] Qemu the right way -[Subthread Cores]

[liebrecht]

For the record I have no crashes with
-cpu host It works perfectly. Although I can only see 2 cpus in windows 
with 4 showing up in devicemanager.


The first link you sent was actually the first thing I tried and I was 
already aware of that one.

It made no difference whatsoever.
My bios is latest on the rackserver , but it does not have the maximum 
core option in the bios.


Let me update the os to latest patches. I can vaguely remeber a similar 
problem running wi7 pro natively. I think out of the box you get win7 
home cpu limits and only after updates do you have pro lqarger cpu count 
activated. I may remeber wrong, but I will do that first and report 
back.



Since I do not have networking sorted out yet I cannot update win7 pro, 
and it

might be the updates which are needed for allowing more than two cpus.

hm, brief search on my side resulted in this tip:

https://answers.microsoft.com/en-us/windows/forum/windows_7-hardware/windows-7-professional-x64-only-showing-2-of-8/0155f525-df73-4642-a828-21b80d1564b0

--
Some recommendations (in Windows, make sure you are running as 
Administrator):


- Run MSConfig -> Change to Boot tab -> Advanced Options -> "Number of
Processors", make sure there is no check mark.
- Delete processor entries listed in Device Manager, then reboot.

-

(I don't think BIOS options from this answer really apply directly to 
qemu case)


also, if win (or some applications inside it) keep crashing with -cpu 
host, you

can try to reload host (Linux) kvm module with additional option:

"options kvm ignore_msrs=1" line (without quotes) should be added to
 /etc/modprobe.d/kvm.conf

from
https://www.passmark.com/forum/performancetest/4748-startup-error-number-4-on-qemu-bsod

Re: [Qemu-devel] [PATCH v2 52/52] usbaudio: change playback counters to 64 bit

[Kővágó Zoltán]

Hi,

On 2018-12-25 11:50, Philippe Mathieu-Daudé wrote:
> On 12/23/18 9:52 PM, Kővágó, Zoltán wrote:
>> With stereo playback, they need about 375 minutes of continuous audio
>> playback to overflow, which is usually not a problem (as stopping and
>> later resuming playback resets the counters).  But with 7.1 audio, they
>> only need about 95 minutes to overflow.
>>
>> After the overflow, the buf->prod % USBAUDIO_PACKET_SIZE(channels)
>> assertion no longer holds true, which will result in overflowing the
>> buffer.  With 64 bit variables, it would take about 762000 years to
>> overflow.
>>
>> Signed-off-by: Kővágó, Zoltán 
>> ---
>>  hw/usb/dev-audio.c | 12 +++-
>>  1 file changed, 7 insertions(+), 5 deletions(-)
>>
>> diff --git a/hw/usb/dev-audio.c b/hw/usb/dev-audio.c
>> index 29475a2b70..45ffc3ebb3 100644
>> --- a/hw/usb/dev-audio.c
>> +++ b/hw/usb/dev-audio.c
>> @@ -577,9 +577,9 @@ static const USBDesc desc_audio_multi = {
>>  
>>  struct streambuf {
>>  uint8_t *data;
>> -uint32_t size;
>> -uint32_t prod;
>> -uint32_t cons;
>> +size_t size;
>> +uint64_t prod;
>> +uint64_t cons;
> 
> OK.
> 
>>  };
>>  
>>  static void streambuf_init(struct streambuf *buf, uint32_t size,
>> @@ -600,12 +600,14 @@ static void streambuf_fini(struct streambuf *buf)
>>  
>>  static int streambuf_put(struct streambuf *buf, USBPacket *p, uint32_t 
>> channels)
>>  {
>> -uint32_t free = buf->size - (buf->prod - buf->cons);
>> +uint64_t free = buf->size - (buf->prod - buf->cons);
> 
> I'd use ssize_t here.
>

Hm, I agree with the signed part, but I'm not sure about the size_t
part. Granted, there's a big problem if buf->prod - buf->cons can't be
representated on 32 bits, but still I'd rather use int64_t in this case
and prevent this potential truncation on 32-bit platforms.

>>  
>>  if (free < USBAUDIO_PACKET_SIZE(channels)) {
>>  return 0;
>>  }
>>  
>> +/* can happen if prod overflows */
>> +assert(buf->prod % USBAUDIO_PACKET_SIZE(channels) == 0);
>>  usb_packet_copy(p, buf->data + (buf->prod % buf->size),
>>  USBAUDIO_PACKET_SIZE(channels));
>>  buf->prod += USBAUDIO_PACKET_SIZE(channels);
>> @@ -614,7 +616,7 @@ static int streambuf_put(struct streambuf *buf, 
>> USBPacket *p, uint32_t channels)
>>  
>>  static uint8_t *streambuf_get(struct streambuf *buf, size_t *len)
>>  {
>> -uint32_t used = buf->prod - buf->cons;
>> +uint64_t used = buf->prod - buf->cons;
>>  uint8_t *data;
>>  
>>  if (!used) {
> 
> Eventually here:
> 
> ssize_t used = buf->prod - buf->cons;
> 
> if (used <= 0) {
> return NULL;
> }
> 

Regards,
Zoltan

Re: [Qemu-devel] Qemu the right way.

[liebrecht]

I resolved it by removing the nic driver detected  by windows and 
rebooted.
It seems llike the first thing to do after the startup string is 
complete is to remove all drivers and then let windows find them again 
according to what is available from the startup string switches.


The nic problem is solved.
Thanks all for the kind help

On 2018-12-26 22:13, Andrew Randrianasulu wrote:

re:

The network switch used above fails with
qemu-system-x86_64: -nic: invalid option

Cant figure out why as it is what is used in the manual as is!



May be because your qemu is not as new as documentation (documentation 
describe

current stable qemu - v 3.1.0) ?

I tried this line

qemu-system-x86_64 -nic user,ipv6=off,model=e1000,mac=52:54:98:76:54:32 
-cdrom
~/Downloads/ISO/slax-English-US-7.0.8-x86_64.iso -m 1999 -enable-kvm 
-cpu

host -smp 4

and it worked for me (obviosly with Linux guest), browser in this 
specific
live-cd was too old for youtube, but at least it showed previews and 
error

messages.

My qemu is self-compiled and sort-of behind the times:

qemu-system-x86_64 --version
QEMU emulator version 3.0.50 (v3.0.0-1559-g179f9ac887-dirty)
Copyright (c) 2003-2018 Fabrice Bellard and the QEMU Project developers

Re: [Qemu-devel] [PATCH 0/2] tests: Reorganize MIPS TCG directories and files

[Philippe Mathieu-Daudé]

Hi Aleksandar,

On 12/27/18 2:12 PM, Aleksandar Markovic wrote:
> From: Aleksandar Markovic 
> 
> Reorganize MIPS TCG directories and files. The file movement is done
> using "git mv" command, so "git blame" will still display the original
> information, regardles of the new names and locations of involved
> files.
> 
> Aleksandar Markovic (2):
>   tests: tcg: mips: Move source files to new location
>   tests: tcg: mips: Remove old directories after reorganization

It seems the list ate your patch 1/2...

See https://lists.gnu.org/archive/html/qemu-devel/2018-12/msg06009.html

Regards,

Phil.

Re: [Qemu-devel] [PATCH 0/6] target/mips: Amend MXU support

[Aleksandar Markovic]

> From: Aleksandar Markovic 
> Subject: [PATCH 0/6] target/mips: Amend MXU support
> 
> From: Aleksandar Markovic 
> 
> Various updates to MXU ASE support.
> 
> Aleksandar Markovic (6):
>  target/mips: MXU: Add missing opcodes/decoding for LX* instructions
>  target/mips: MXU: Add generic naming for optn2 constants
>  target/mips: MXU: Improve textual description
>  target/mips: MXU: Add handlers for logic instructions
>  target/mips: MXU: Add handlers for max/min instructions
>  target/mips: MXU: Add handlers for an align instruction

If there is no objection, to get things going a little, I am going to integrate 
patches 1, 2, and 3 into next MIPS pull request (scheduled shortly), while it 
looks other patches need more time for review.

(patch 1 is about "pool 17", issues around "pool 16" will be covered in a 
separate patch in v2)

Thanks to everyone,
Aleksandar

Re: [Qemu-devel] [PATCH v2 09/12] tests/tcg/mips: Test R5900 three-operand MADDU1

[Aleksandar Markovic]

> From: Fredrik Noring 
> Subject: [PATCH v2 09/12] tests/tcg/mips: Test R5900 three-operand MADDU1

Reviewed-by: Aleksandar Markovic 

This patch is selected for integration in the next MIPS pull request scheduled 
shortly.

THANKS FOR ALL EFFORTS!

Re: [Qemu-devel] [PATCH v2 07/12] tests/tcg/mips: Test R5900 three-operand MADD1

[Aleksandar Markovic]

> From: Fredrik Noring 
> Subject: [PATCH v2 07/12] tests/tcg/mips: Test R5900 three-operand MADD1

Reviewed-by: Aleksandar Markovic 

This patch is selected for integration in the next MIPS pull request scheduled 
shortly.

Re: [Qemu-devel] [PATCH v2 08/12] tests/tcg/mips: Test R5900 three-operand MADDU

[Aleksandar Markovic]

> From: Fredrik Noring 
> Subject: [PATCH v2 08/12] tests/tcg/mips: Test R5900 three-operand MADDU

Reviewed-by: Aleksandar Markovic 

This patch is selected for integration in the next MIPS pull request scheduled 
shortly.

Re: [Qemu-devel] [PATCH v2 06/12] tests/tcg/mips: Test R5900 three-operand MADD

[Aleksandar Markovic]

> From: Fredrik Noring 
> Subject: [PATCH v2 06/12] tests/tcg/mips: Test R5900 three-operand MADD

Reviewed-by: Aleksandar Markovic 

This patch is selected for integration in the next MIPS pull request scheduled 
shortly.

Re: [Qemu-devel] [PATCH v2 05/12] target/mips: Support R5900 three-operand MADD1 and MADDU1

[Aleksandar Markovic]

> From: Fredrik Noring 
> Subject: [PATCH v2 05/12] target/mips: Support R5900 three-operand MADD1 and 
> MADDU1

Reviewed-by: Aleksandar Markovic 

This patch is selected for integration in the next MIPS pull request scheduled 
shortly.

Re: [Qemu-devel] [PATCH v2 04/12] target/mips: Support Toshiba specific three-operand MADD and MADDU

[Aleksandar Markovic]

> From: Fredrik Noring 
> Subject: [PATCH v2 04/12] target/mips: Support Toshiba specific three-operand 
> MADD and MADDU
>
> From: Philippe Mathieu-Daudé 

Reviewed-by: Aleksandar Markovic 

This patch is selected for integration in the next MIPS pull request scheduled 
shortly.

Re: [Qemu-devel] [RFC PATCH 1/1] hw/core: add qom getter for kernel-irqchip property

[Eduardo Habkost]

On Tue, Dec 25, 2018 at 01:20:05PM +0800, Peter Xu wrote:
> On Mon, Dec 24, 2018 at 06:52:35AM -0500, Wainer dos Santos Moschetta wrote:
> > Allows to access the kernel-irqchip property of a Machine
> > Class object via QOM get method.
> > 
> > Before this patch the property cannot be read although it is
> > listed by qom-list:
> > 
> > qemu-system-x86_64 -M q35,accel=kvm,kernel-irqchip=split (...)
> > -> {"execute": "qom-list", "arguments": {"path": "/machine"}}
> > <- {"return": [{"name": "type", "type": "string"}, (...) , {"name": 
> > "kernel-irqchip", "type": "on|off|split"} (...)}
> > -> {"execute": "qom-get", "arguments": {"path": "/machine", "property": 
> > "kernel-irqchip"}}
> > <- {"error": {"class": "GenericError", "desc": "Insufficient permission to 
> > perform this operation"}}
> > 
> > It is implemented the machine_get_kernel_irqchip() method,
> > which evaluates the kernel_irqchip_allowed, *_required, and
> > *_split fields to determine the value of kernel-irqchip. Note: we
> > assume there is not inconsistency on the value of those fields.
> > 
> > Then with this change in place, it works as expected:
> > 
> > qemu-system-x86_64 -M q35,accel=kvm,kernel-irqchip=split (...)
> > -> {"execute": "qom-get", "arguments": {"path": "/machine", "property": 
> > "kernel-irqchip"}}
> > <- {"return": "split"}
> > 
> > Signed-off-by: Wainer dos Santos Moschetta 
> > ---
> >  hw/core/machine.c | 17 -
> >  1 file changed, 16 insertions(+), 1 deletion(-)
> > 
> > diff --git a/hw/core/machine.c b/hw/core/machine.c
> > index c51423b647..f61003f8f2 100644
> > --- a/hw/core/machine.c
> > +++ b/hw/core/machine.c
> > @@ -37,6 +37,21 @@ static void machine_set_accel(Object *obj, const char 
> > *value, Error **errp)
> >  ms->accel = g_strdup(value);
> >  }
> >  
> > +static void machine_get_kernel_irqchip(Object *obj, Visitor *v,
> > +   const char *name, void *opaque,
> > +   Error **errp)
> > +{
> > +MachineState *ms = MACHINE(obj);
> > +OnOffSplit mode;
> > +
> > +if (ms->kernel_irqchip_split) {
> > +mode = ON_OFF_SPLIT_SPLIT;
> > +} else {
> > +mode = (ms->kernel_irqchip_allowed && ms->kernel_irqchip_required) 
> > ?
> > +ON_OFF_SPLIT_ON : ON_OFF_SPLIT_OFF;
> 
> Hi, Wainer,
> 
> The new interface seems to be a good thing, though the implementation
> might be incorrect here.  AFAIU these parameters only decide "how we
> want to choose the kernel-irqchip parameter" rather than the real
> result, which could depend on more (e.g., whether KVM is used).
> 
> IMHO you should simply fetch the results from kvm_irqchip_in_kernel()
> and kvm_irqchip_is_split() where the real results are stored.

Agreed.  Knowing the actual values of kvm_irqchip_*() would be
even more useful for test code (this way we would be testing all
the KVM irqchip initialization code, not just a few lines of
property getter/seter code).

-- 
Eduardo

Re: [Qemu-devel] [PATCH for-4.0 v4 4/4] i386: allow to load initrd below 4G for recent linux

[Eduardo Habkost]

On Fri, Dec 21, 2018 at 11:10:30AM -0500, Michael S. Tsirkin wrote:
> On Thu, Dec 06, 2018 at 10:32:13AM +0800, Li Zhijian wrote:
> > a new field xloadflags was added to recent x86 linux, and BIT 1:
> > XLF_CAN_BE_LOADED_ABOVE_4G is used to tell bootload that where initrd can be
> > loaded safely.
> > 
> > Current QEMU/BIOS always loads initrd below below_4g_mem_size which is 
> > always
> > less than 4G, so here limiting initrd_max to 4G - 1 simply is enough if
> > this bit is set.
> > 
> > CC: Paolo Bonzini 
> > CC: Richard Henderson 
> > CC: Eduardo Habkost 
> > CC: "Michael S. Tsirkin" 
> > CC: Marcel Apfelbaum 
> > Signed-off-by: Li Zhijian 
> > 
> > ---
> > V3: correct grammar and check XLF_CAN_BE_LOADED_ABOVE_4G first (Michael S. 
> > Tsirkin)
> > 
> > Signed-off-by: Li Zhijian 
> > ---
> >  hw/i386/pc.c | 10 +-
> >  1 file changed, 9 insertions(+), 1 deletion(-)
> > 
> > diff --git a/hw/i386/pc.c b/hw/i386/pc.c
> > index 3b10726..baa99c0 100644
> > --- a/hw/i386/pc.c
> > +++ b/hw/i386/pc.c
> > @@ -904,7 +904,15 @@ static void load_linux(PCMachineState *pcms,
> >  #endif
> >  
> >  /* highest address for loading the initrd */
> > -if (protocol >= 0x203) {
> > +if (protocol >= 0x20c &&
> > +lduw_p(header+0x236) & XLF_CAN_BE_LOADED_ABOVE_4G) {
> > +/*
> > + * Although kernel allows initrd loading to above 4G,
> > + * it just makes it as large as possible while still staying below 
> > 4G
> > + * since current BIOS always loads initrd below 
> > pcms->below_4g_mem_size
> > + */
> > +initrd_max = UINT32_MAX;
> > +} else if (protocol >= 0x203) {
> >  initrd_max = ldl_p(header+0x22c);
> >  } else {
> >  initrd_max = 0x37ff;
> 
> 
> I still have trouble understanding the above.
> Anyone else wants to comment / help rephrase the comment
> and commit log so it's readable?


The comment seems to contradict what I see on the code:

| Although kernel allows initrd loading to above 4G,

Sounds correct.


| it just makes it as large as possible while still staying below 4G

I'm not a native English speaker, but I believe "it" here should
be interpreted as "the kernel", which would be incorrect.  It's
this QEMU function that limits initrd_max to a uint32 value, not
the kernel.


| since current BIOS always loads initrd below pcms->below_4g_mem_size

I don't know why the BIOS is mentioned here.  The
below_4g_mem_size limit comes from these 2 lines inside
load_linux():

if (initrd_max >= pcms->below_4g_mem_size - pcmc->acpi_data_size) {
initrd_max = pcms->below_4g_mem_size - pcmc->acpi_data_size - 1;
}
In addition to that, initrd_max is uint32_t simply because QEMU
doesn't support the 64-bit boot protocol (specifically the
ext_ramdisk_image field), so all talk about below_4g_mem_size
seems to be just a distraction.

All that said, I miss one piece of information here: is
XLF_CAN_BE_LOADED_ABOVE_4G really supposed to override
header+0x22c?  linux/Documentation/x86/boot.txt isn't clear about
that.  Is there any reference that can help us confirm this?

-- 
Eduardo

Re: [Qemu-devel] [PATCH 5/6] target/mips: MXU: Add handlers for max/min instructions

[Aleksandar Markovic]

> From: Janeczek, Craig 

> > +/* return resulting byte to its original position */
> > +tcg_gen_shri_i32(t0, t0, 24);
> 
> Should be a shift of 16 here
> tcg_gen_shri_i32(t0, t0, 16);

You are right, for this and the next three hints. Will be fixed in v2.

Thanks,
Aleksandar

Re: [Qemu-devel] [PATCH 1/6] target/mips: MXU: Add missing opcodes/decoding for LX* instructions

[Aleksandar Markovic]

> From: Janeczek, Craig 
>
> Yes, both the comment and enum should be updated.

OK, this will be fixed in v2.

Thanks,
Aleksandar

Re: [Qemu-devel] [PATCH 1/6] target/mips: MXU: Add missing opcodes/decoding for LX* instructions

[Janeczek, Craig via Qemu-devel]

Yes, both the comment and enum should be updated.

-Original Message-
From: Aleksandar Markovic  
Sent: Thursday, December 27, 2018 2:23 PM
To: Janeczek, Craig ; Stefan Markovic 
; Aleksandar Markovic ; 
qemu-devel@nongnu.org
Subject: Re: [PATCH 1/6] target/mips: MXU: Add missing opcodes/decoding for LX* 
instructions

> From: Janeczek, Craig 
> Sent: Thursday, December 27, 2018 7:50 PM
> To: Aleksandar Markovic; Stefan Markovic; Aleksandar Markovic; 
> qemu-devel@nongnu.org
> Subject: RE: [PATCH 1/6] target/mips: MXU: Add missing opcodes/decoding for 
> LX* instructions
> 
> Yes built a binary testing these instructions and ran it against HW along 
> with a qemu binary with your > patches. The opcodes align with what I 
> mentioned in the email.
> 

I truly appreciate your help.

Just to clarify details, beside correcting comments, does this mean that this 
code segment:

/*
 * MXU pool 16
 */
enum {
OPC_MXU_D32SARW  = 0x00,
OPC_MXU_S32ALN   = 0x01,
OPC_MXU_S32ALNI  = 0x02,
OPC_MXU_S32NOR   = 0x03,
OPC_MXU_S32AND   = 0x04,
OPC_MXU_S32OR= 0x05,
OPC_MXU_S32XOR   = 0x06,
OPC_MXU_S32LUI   = 0x07,
};

should be corrected to be:

/*
 * MXU pool 16
 */
enum {
OPC_MXU_D32SARW  = 0x00,
OPC_MXU_S32ALN   = 0x01,
OPC_MXU_S32ALNI  = 0x02,
OPC_MXU_S32LUI   = 0x03,
OPC_MXU_S32NOR   = 0x04,
OPC_MXU_S32AND   = 0x05,
OPC_MXU_S32OR= 0x06,
OPC_MXU_S32XOR   = 0x07,
};

and all things will line up for "pool 16"?

Sincerely,
Aleksandar

> -Original Message-
> From: Aleksandar Markovic 
> Subject: Re: [PATCH 1/6] target/mips: MXU: Add missing opcodes/decoding for 
> LX* instructions
> 
> > > @@ -1663,12 +1663,21 @@ enum {
> > >*  │   20..18
> > >*  ├─ 100111 ─ OPC_MXU__POOL16 ─┬─ 000 ─ OPC_MXU_D32SARW
> > >*  │├─ 001 ─ OPC_MXU_S32ALN
> > > - *  ├─ 101000 ─ OPC_MXU_LXB  ├─ 010 ─ OPC_MXU_S32ALNI
> > > - *  ├─ 101001 ─├─ 011 ─ OPC_MXU_S32NOR
> > > - *  ├─ 101010 ─ OPC_MXU_S16LDD   ├─ 100 ─ OPC_MXU_S32AND
> > > - *  ├─ 101011 ─ OPC_MXU_S16STD   ├─ 101 ─ OPC_MXU_S32OR
> > > - *  ├─ 101100 ─ OPC_MXU_S16LDI   ├─ 110 ─ OPC_MXU_S32XOR
> > > - *  ├─ 101101 ─ OPC_MXU_S16SDI   └─ 111 ─ OPC_MXU_S32LUI
> > > + *  │├─ 010 ─ OPC_MXU_S32ALNI
> > > + *  │├─ 011 ─ OPC_MXU_S32NOR
> > > + *  │├─ 100 ─ OPC_MXU_S32AND
> > > + *  │├─ 101 ─ OPC_MXU_S32OR
> > > + *  │├─ 110 ─ OPC_MXU_S32XOR
> > > + *  │└─ 111 ─ OPC_MXU_S32LUI
> > The opcodes for pool 16 do not look correct. I think the minor bits should 
> > look like the following.
> >
> > ┬─ 000 ─ OPC_MXU_D32SARW
> > ├─ 001 ─ OPC_MXU_S32ALN
> > ├─ 010 ─ OPC_MXU_S32ALNI
> > ├─ 011 ─ OPC_MXU_S32LUI
> > ├─ 100 ─ OPC_MXU_S32NOR
> > ├─ 101 ─ OPC_MXU_S32AND
> > ├─ 110 ─ OPC_MXU_S32OR
> > └─ 111 ─ OPC_MXU_S32XOR
> >
> 
> Hi, Craig!
> 
> My primary source for opcodes was the latest Ingenic documentation, from 
> Ingenic's site: (dated June > 2017)
> 
> ftp://ftp.ingenic.com/SOC/M200/X1000_M200_XBurst_ISA_MXU_PM.pdf
> 
> and on page 109 there is a table in the middle of the page that contains 
> codes that are in agreement > with what is currently in QEMU.
> 
> However, I searched more, and in a repository that seems to be derived from 
> Android NDK r9d binutils > tree, in file
> 
> https://github.com/apportable/binutils/blob/master/opcodes/mxu-opc.c
> 
> opcodes are as you said.
> 
> I guess the definitive answer would be to involve tests on hardware, no?
> 
> Thanks for bringing this up!
> 
> Aleksandar
> 
> 
> > > + *  │
> > > + *  │   7..5
> > > + *  ├─ 101000 ─ OPC_MXU__POOL17 ─┬─ 000 ─ OPC_MXU_LXB
> > > + *  │├─ 001 ─ OPC_MXU_LXH
> > > + *  ├─ 101001 ─├─ 011 ─ OPC_MXU_LXW
> > > + *  ├─ 101010 ─ OPC_MXU_S16LDD   ├─ 100 ─ OPC_MXU_LXBU
> > > + *  ├─ 101011 ─ OPC_MXU_S16STD   └─ 101 ─ OPC_MXU_LXHU
> > > + *  ├─ 101100 ─ OPC_MXU_S16LDI
> > > + *  ├─ 101101 ─ OPC_MXU_S16SDI
> > >*  ├─ 101110 ─ OPC_MXU_S32M2I
> > >*  ├─ 10 ─ OPC_MXU_S32I2M
> > >*  ├─ 11 ─ OPC_MXU_D32SLL

Re: [Qemu-devel] [PATCH 1/6] target/mips: MXU: Add missing opcodes/decoding for LX* instructions

[Aleksandar Markovic]

> From: Janeczek, Craig 
> Sent: Thursday, December 27, 2018 7:50 PM
> To: Aleksandar Markovic; Stefan Markovic; Aleksandar Markovic; 
> qemu-devel@nongnu.org
> Subject: RE: [PATCH 1/6] target/mips: MXU: Add missing opcodes/decoding for 
> LX* instructions
> 
> Yes built a binary testing these instructions and ran it against HW along 
> with a qemu binary with your > patches. The opcodes align with what I 
> mentioned in the email.
> 

I truly appreciate your help.

Just to clarify details, beside correcting comments, does this mean that this 
code segment:

/*
 * MXU pool 16
 */
enum {
OPC_MXU_D32SARW  = 0x00,
OPC_MXU_S32ALN   = 0x01,
OPC_MXU_S32ALNI  = 0x02,
OPC_MXU_S32NOR   = 0x03,
OPC_MXU_S32AND   = 0x04,
OPC_MXU_S32OR= 0x05,
OPC_MXU_S32XOR   = 0x06,
OPC_MXU_S32LUI   = 0x07,
};

should be corrected to be:

/*
 * MXU pool 16
 */
enum {
OPC_MXU_D32SARW  = 0x00,
OPC_MXU_S32ALN   = 0x01,
OPC_MXU_S32ALNI  = 0x02,
OPC_MXU_S32LUI   = 0x03,
OPC_MXU_S32NOR   = 0x04,
OPC_MXU_S32AND   = 0x05,
OPC_MXU_S32OR= 0x06,
OPC_MXU_S32XOR   = 0x07,
};

and all things will line up for "pool 16"?

Sincerely,
Aleksandar

> -Original Message-
> From: Aleksandar Markovic 
> Subject: Re: [PATCH 1/6] target/mips: MXU: Add missing opcodes/decoding for 
> LX* instructions
> 
> > > @@ -1663,12 +1663,21 @@ enum {
> > >*  │   20..18
> > >*  ├─ 100111 ─ OPC_MXU__POOL16 ─┬─ 000 ─ OPC_MXU_D32SARW
> > >*  │├─ 001 ─ OPC_MXU_S32ALN
> > > - *  ├─ 101000 ─ OPC_MXU_LXB  ├─ 010 ─ OPC_MXU_S32ALNI
> > > - *  ├─ 101001 ─├─ 011 ─ OPC_MXU_S32NOR
> > > - *  ├─ 101010 ─ OPC_MXU_S16LDD   ├─ 100 ─ OPC_MXU_S32AND
> > > - *  ├─ 101011 ─ OPC_MXU_S16STD   ├─ 101 ─ OPC_MXU_S32OR
> > > - *  ├─ 101100 ─ OPC_MXU_S16LDI   ├─ 110 ─ OPC_MXU_S32XOR
> > > - *  ├─ 101101 ─ OPC_MXU_S16SDI   └─ 111 ─ OPC_MXU_S32LUI
> > > + *  │├─ 010 ─ OPC_MXU_S32ALNI
> > > + *  │├─ 011 ─ OPC_MXU_S32NOR
> > > + *  │├─ 100 ─ OPC_MXU_S32AND
> > > + *  │├─ 101 ─ OPC_MXU_S32OR
> > > + *  │├─ 110 ─ OPC_MXU_S32XOR
> > > + *  │└─ 111 ─ OPC_MXU_S32LUI
> > The opcodes for pool 16 do not look correct. I think the minor bits should 
> > look like the following.
> >
> > ┬─ 000 ─ OPC_MXU_D32SARW
> > ├─ 001 ─ OPC_MXU_S32ALN
> > ├─ 010 ─ OPC_MXU_S32ALNI
> > ├─ 011 ─ OPC_MXU_S32LUI
> > ├─ 100 ─ OPC_MXU_S32NOR
> > ├─ 101 ─ OPC_MXU_S32AND
> > ├─ 110 ─ OPC_MXU_S32OR
> > └─ 111 ─ OPC_MXU_S32XOR
> >
> 
> Hi, Craig!
> 
> My primary source for opcodes was the latest Ingenic documentation, from 
> Ingenic's site: (dated June > 2017)
> 
> ftp://ftp.ingenic.com/SOC/M200/X1000_M200_XBurst_ISA_MXU_PM.pdf
> 
> and on page 109 there is a table in the middle of the page that contains 
> codes that are in agreement > with what is currently in QEMU.
> 
> However, I searched more, and in a repository that seems to be derived from 
> Android NDK r9d binutils > tree, in file
> 
> https://github.com/apportable/binutils/blob/master/opcodes/mxu-opc.c
> 
> opcodes are as you said.
> 
> I guess the definitive answer would be to involve tests on hardware, no?
> 
> Thanks for bringing this up!
> 
> Aleksandar
> 
> 
> > > + *  │
> > > + *  │   7..5
> > > + *  ├─ 101000 ─ OPC_MXU__POOL17 ─┬─ 000 ─ OPC_MXU_LXB
> > > + *  │├─ 001 ─ OPC_MXU_LXH
> > > + *  ├─ 101001 ─├─ 011 ─ OPC_MXU_LXW
> > > + *  ├─ 101010 ─ OPC_MXU_S16LDD   ├─ 100 ─ OPC_MXU_LXBU
> > > + *  ├─ 101011 ─ OPC_MXU_S16STD   └─ 101 ─ OPC_MXU_LXHU
> > > + *  ├─ 101100 ─ OPC_MXU_S16LDI
> > > + *  ├─ 101101 ─ OPC_MXU_S16SDI
> > >*  ├─ 101110 ─ OPC_MXU_S32M2I
> > >*  ├─ 10 ─ OPC_MXU_S32I2M
> > >*  ├─ 11 ─ OPC_MXU_D32SLL

Re: [Qemu-devel] [PATCH 1/6] target/mips: MXU: Add missing opcodes/decoding for LX* instructions

[Janeczek, Craig via Qemu-devel]

Yes built a binary testing these instructions and ran it against HW along with 
a qemu binary with your patches. The opcodes align with what I mentioned in the 
email.

-Original Message-
From: Aleksandar Markovic  
Sent: Thursday, December 27, 2018 1:44 PM
To: Janeczek, Craig ; Stefan Markovic 
; Aleksandar Markovic ; 
qemu-devel@nongnu.org
Subject: Re: [PATCH 1/6] target/mips: MXU: Add missing opcodes/decoding for LX* 
instructions

> > @@ -1663,12 +1663,21 @@ enum {
> >*  │   20..18
> >*  ├─ 100111 ─ OPC_MXU__POOL16 ─┬─ 000 ─ OPC_MXU_D32SARW
> >*  │├─ 001 ─ OPC_MXU_S32ALN
> > - *  ├─ 101000 ─ OPC_MXU_LXB  ├─ 010 ─ OPC_MXU_S32ALNI
> > - *  ├─ 101001 ─├─ 011 ─ OPC_MXU_S32NOR
> > - *  ├─ 101010 ─ OPC_MXU_S16LDD   ├─ 100 ─ OPC_MXU_S32AND
> > - *  ├─ 101011 ─ OPC_MXU_S16STD   ├─ 101 ─ OPC_MXU_S32OR
> > - *  ├─ 101100 ─ OPC_MXU_S16LDI   ├─ 110 ─ OPC_MXU_S32XOR
> > - *  ├─ 101101 ─ OPC_MXU_S16SDI   └─ 111 ─ OPC_MXU_S32LUI
> > + *  │├─ 010 ─ OPC_MXU_S32ALNI
> > + *  │├─ 011 ─ OPC_MXU_S32NOR
> > + *  │├─ 100 ─ OPC_MXU_S32AND
> > + *  │├─ 101 ─ OPC_MXU_S32OR
> > + *  │├─ 110 ─ OPC_MXU_S32XOR
> > + *  │└─ 111 ─ OPC_MXU_S32LUI
> The opcodes for pool 16 do not look correct. I think the minor bits should 
> look like the following.
> 
> ┬─ 000 ─ OPC_MXU_D32SARW
> ├─ 001 ─ OPC_MXU_S32ALN
> ├─ 010 ─ OPC_MXU_S32ALNI
> ├─ 011 ─ OPC_MXU_S32LUI
> ├─ 100 ─ OPC_MXU_S32NOR
> ├─ 101 ─ OPC_MXU_S32AND
> ├─ 110 ─ OPC_MXU_S32OR
> └─ 111 ─ OPC_MXU_S32XOR
> 

Hi, Craig!

My primary source for opcodes was the latest Ingenic documentation, from 
Ingenic's site: (dated June 2017)

ftp://ftp.ingenic.com/SOC/M200/X1000_M200_XBurst_ISA_MXU_PM.pdf

and on page 109 there is a table in the middle of the page that contains codes 
that are in agreement with what is currently in QEMU.

However, I searched more, and in a repository that seems to be derived from 
Android NDK r9d binutils tree, in file

https://github.com/apportable/binutils/blob/master/opcodes/mxu-opc.c

opcodes are as you said.

I guess the definitive answer would be to involve tests on hardware, no?

Thanks for bringing this up!

Aleksandar


> > + *  │
> > + *  │   7..5
> > + *  ├─ 101000 ─ OPC_MXU__POOL17 ─┬─ 000 ─ OPC_MXU_LXB
> > + *  │├─ 001 ─ OPC_MXU_LXH
> > + *  ├─ 101001 ─├─ 011 ─ OPC_MXU_LXW
> > + *  ├─ 101010 ─ OPC_MXU_S16LDD   ├─ 100 ─ OPC_MXU_LXBU
> > + *  ├─ 101011 ─ OPC_MXU_S16STD   └─ 101 ─ OPC_MXU_LXHU
> > + *  ├─ 101100 ─ OPC_MXU_S16LDI
> > + *  ├─ 101101 ─ OPC_MXU_S16SDI
> >*  ├─ 101110 ─ OPC_MXU_S32M2I
> >*  ├─ 10 ─ OPC_MXU_S32I2M
> >*  ├─ 11 ─ OPC_MXU_D32SLL

Re: [Qemu-devel] [PATCH] smbus_eeprom: Limit data writes to 255 bytes

[Philippe Mathieu-Daudé]

Hi Michael,

On Thu, Dec 27, 2018 at 12:53 PM Michael Hanselmann  wrote:
 The "eeprom_write_data" function in "smbus_eeprom.c" had no provisions
 to limit the length of data written. If a caller were able to manipulate
 the "len" parameter they could potentially write before or after the
 target buffer.

You forgot to sign your commit:
"Signed-off-by: Michael Hanselmann "

(See 
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/SubmittingPatches?id=f6f94e2ab1b33f0082ac22d71f66385a60d8157f#n297)

> ---
>  hw/i2c/smbus_eeprom.c | 1 +
>  1 file changed, 1 insertion(+)
>
> diff --git a/hw/i2c/smbus_eeprom.c b/hw/i2c/smbus_eeprom.c
> index f18aa3de35..74fa1c328c 100644
> --- a/hw/i2c/smbus_eeprom.c
> +++ b/hw/i2c/smbus_eeprom.c
> @@ -76,6 +76,7 @@ static void eeprom_write_data(SMBusDevice *dev, uint8_t 
> cmd, uint8_t *buf, int l
> It is a block write without a length byte.  Fortunately we
> get the full block anyway.  */
>  /* TODO: Should this set the current location?  */
> +len &= 0xff;
>  if (cmd + len > 256)

Corey Minyard sent a cleanup series [1] because this device model is
known to be unsafe and need rewrite.
There is a particular patch [2] which add the SMBUS_EEPROM_SIZE definition.
He also provided a intent at cleaning this problem here [3] where
Peter suggested to split it in fewer patches.

Regards,

Phil.

[1] https://lists.gnu.org/archive/html/qemu-devel/2018-11/msg05293.html
[2] https://lists.gnu.org/archive/html/qemu-devel/2018-11/msg05295.html
[3] https://lists.gnu.org/archive/html/qemu-devel/2018-11/msg05298.html

>  n = 256 - cmd;
>  else
> --
> 2.11.0
>
>

Re: [Qemu-devel] [RFC PATCH 05/13] tests/tcg/mips: enable mips64 system tests (WIP)

[Aleksandar Markovic]

Sorry, my last message involving this thread was sent in error. It was meant to 
be a a response to another, unrelated, message. Please discard it.

Aleksandar

Re: [Qemu-devel] [RFC PATCH 05/13] tests/tcg/mips: enable mips64 system tests (WIP)

[Aleksandar Markovic]

> > @@ -1663,12 +1663,21 @@ enum {
> >*  │   20..18
> >*  ├─ 100111 ─ OPC_MXU__POOL16 ─┬─ 000 ─ OPC_MXU_D32SARW
> >*  │├─ 001 ─ OPC_MXU_S32ALN
> > - *  ├─ 101000 ─ OPC_MXU_LXB  ├─ 010 ─ OPC_MXU_S32ALNI
> > - *  ├─ 101001 ─├─ 011 ─ OPC_MXU_S32NOR
> > - *  ├─ 101010 ─ OPC_MXU_S16LDD   ├─ 100 ─ OPC_MXU_S32AND
> > - *  ├─ 101011 ─ OPC_MXU_S16STD   ├─ 101 ─ OPC_MXU_S32OR
> > - *  ├─ 101100 ─ OPC_MXU_S16LDI   ├─ 110 ─ OPC_MXU_S32XOR
> > - *  ├─ 101101 ─ OPC_MXU_S16SDI   └─ 111 ─ OPC_MXU_S32LUI
> > + *  │├─ 010 ─ OPC_MXU_S32ALNI
> > + *  │├─ 011 ─ OPC_MXU_S32NOR
> > + *  │├─ 100 ─ OPC_MXU_S32AND
> > + *  │├─ 101 ─ OPC_MXU_S32OR
> > + *  │├─ 110 ─ OPC_MXU_S32XOR
> > + *  │└─ 111 ─ OPC_MXU_S32LUI
> The opcodes for pool 16 do not look correct. I think the minor bits should 
> look like the following.
> 
> ┬─ 000 ─ OPC_MXU_D32SARW
> ├─ 001 ─ OPC_MXU_S32ALN
> ├─ 010 ─ OPC_MXU_S32ALNI
> ├─ 011 ─ OPC_MXU_S32LUI
> ├─ 100 ─ OPC_MXU_S32NOR
> ├─ 101 ─ OPC_MXU_S32AND
> ├─ 110 ─ OPC_MXU_S32OR
> └─ 111 ─ OPC_MXU_S32XOR
> 

Hi, Craig!

My primary source for opcodes was the latest Ingenic documentation, from
Ingenic's site: (dated June 2017)

ftp://ftp.ingenic.com/SOC/M200/X1000_M200_XBurst_ISA_MXU_PM.pdf

and on page 109 there is a table in the middle of the page that contains
codes that are in agreement with what is currently in QEMU.

However, I searched more, and in a repository that seems to be derived from
Android NDK r9d binutils tree, in file

https://github.com/apportable/binutils/blob/master/opcodes/mxu-opc.c

opcodes are as you said.

I guess the definitive answer would be to involve tests on hardware, no?

Thanks for bringing this up!

Aleksandar


> > + *  │
> > + *  │   7..5
> > + *  ├─ 101000 ─ OPC_MXU__POOL17 ─┬─ 000 ─ OPC_MXU_LXB
> > + *  │├─ 001 ─ OPC_MXU_LXH
> > + *  ├─ 101001 ─├─ 011 ─ OPC_MXU_LXW
> > + *  ├─ 101010 ─ OPC_MXU_S16LDD   ├─ 100 ─ OPC_MXU_LXBU
> > + *  ├─ 101011 ─ OPC_MXU_S16STD   └─ 101 ─ OPC_MXU_LXHU
> > + *  ├─ 101100 ─ OPC_MXU_S16LDI
> > + *  ├─ 101101 ─ OPC_MXU_S16SDI
> >*  ├─ 101110 ─ OPC_MXU_S32M2I
> >*  ├─ 10 ─ OPC_MXU_S32I2M
> >*  ├─ 11 ─ OPC_MXU_D32SLL

Re: [Qemu-devel] [PATCH 1/6] target/mips: MXU: Add missing opcodes/decoding for LX* instructions

[Aleksandar Markovic]

> > @@ -1663,12 +1663,21 @@ enum {
> >*  │   20..18
> >*  ├─ 100111 ─ OPC_MXU__POOL16 ─┬─ 000 ─ OPC_MXU_D32SARW
> >*  │├─ 001 ─ OPC_MXU_S32ALN
> > - *  ├─ 101000 ─ OPC_MXU_LXB  ├─ 010 ─ OPC_MXU_S32ALNI
> > - *  ├─ 101001 ─├─ 011 ─ OPC_MXU_S32NOR
> > - *  ├─ 101010 ─ OPC_MXU_S16LDD   ├─ 100 ─ OPC_MXU_S32AND
> > - *  ├─ 101011 ─ OPC_MXU_S16STD   ├─ 101 ─ OPC_MXU_S32OR
> > - *  ├─ 101100 ─ OPC_MXU_S16LDI   ├─ 110 ─ OPC_MXU_S32XOR
> > - *  ├─ 101101 ─ OPC_MXU_S16SDI   └─ 111 ─ OPC_MXU_S32LUI
> > + *  │├─ 010 ─ OPC_MXU_S32ALNI
> > + *  │├─ 011 ─ OPC_MXU_S32NOR
> > + *  │├─ 100 ─ OPC_MXU_S32AND
> > + *  │├─ 101 ─ OPC_MXU_S32OR
> > + *  │├─ 110 ─ OPC_MXU_S32XOR
> > + *  │└─ 111 ─ OPC_MXU_S32LUI
> The opcodes for pool 16 do not look correct. I think the minor bits should 
> look like the following.
> 
> ┬─ 000 ─ OPC_MXU_D32SARW
> ├─ 001 ─ OPC_MXU_S32ALN
> ├─ 010 ─ OPC_MXU_S32ALNI
> ├─ 011 ─ OPC_MXU_S32LUI
> ├─ 100 ─ OPC_MXU_S32NOR
> ├─ 101 ─ OPC_MXU_S32AND
> ├─ 110 ─ OPC_MXU_S32OR
> └─ 111 ─ OPC_MXU_S32XOR
> 

Hi, Craig!

My primary source for opcodes was the latest Ingenic documentation, from
Ingenic's site: (dated June 2017)

ftp://ftp.ingenic.com/SOC/M200/X1000_M200_XBurst_ISA_MXU_PM.pdf

and on page 109 there is a table in the middle of the page that contains
codes that are in agreement with what is currently in QEMU.

However, I searched more, and in a repository that seems to be derived from
Android NDK r9d binutils tree, in file

https://github.com/apportable/binutils/blob/master/opcodes/mxu-opc.c

opcodes are as you said.

I guess the definitive answer would be to involve tests on hardware, no?

Thanks for bringing this up!

Aleksandar


> > + *  │
> > + *  │   7..5
> > + *  ├─ 101000 ─ OPC_MXU__POOL17 ─┬─ 000 ─ OPC_MXU_LXB
> > + *  │├─ 001 ─ OPC_MXU_LXH
> > + *  ├─ 101001 ─├─ 011 ─ OPC_MXU_LXW
> > + *  ├─ 101010 ─ OPC_MXU_S16LDD   ├─ 100 ─ OPC_MXU_LXBU
> > + *  ├─ 101011 ─ OPC_MXU_S16STD   └─ 101 ─ OPC_MXU_LXHU
> > + *  ├─ 101100 ─ OPC_MXU_S16LDI
> > + *  ├─ 101101 ─ OPC_MXU_S16SDI
> >*  ├─ 101110 ─ OPC_MXU_S32M2I
> >*  ├─ 10 ─ OPC_MXU_S32I2M
> >*  ├─ 11 ─ OPC_MXU_D32SLL

Re: [Qemu-devel] d_off field in struct dirent and 32-on-64 emulation

[Florian Weimer]

* Adhemerval Zanella:

> Also for glibc standpoint, although reverting it back to use getdents 
> syscall for non-LFS mode might fix this issue for architectures that
> provides non-LFS getdents syscall it won't be a fix for architectures 
> that still provides off_t different than off64_t *and* only provides 
> getdents64 syscall.
>
> Currently we only have nios2 and csky (unfortunately).  But since generic 
> definition for off_t and off64_t still assumes non-LFS support, all new
> 32-bits ports potentially might carry the issue.

For csky, we could still change the type of the non-standard d_off
field to long long int.  This way, only telldir would have to fail
when truncation is necessary, as mentioned below:

>> There is another annoying aspect: The standards expose d_off through
>> the telldir function, and that returns long int on all architectures
>> (not off_t, so unchanged by _FILE_OFFSET_BITS).  That's mostly a
>> userspace issue and thus needing different steps to resolve (possibly
>> standards action).

Re: [Qemu-devel] d_off field in struct dirent and 32-on-64 emulation

[Adhemerval Zanella]

On 27/12/2018 15:18, Florian Weimer wrote:
> We have a bit of an interesting problem with respect to the d_off
> field in struct dirent.
> 
> When running a 64-bit kernel on certain file systems, notably ext4,
> this field uses the full 63 bits even for small directories (strace -v
> output, wrapped here for readability):
> 
> getdents(3, [
>   {d_ino=1494304, d_off=3901177228673045825, d_reclen=40, 
> d_name="authorized_keys", d_type=DT_REG},
>   {d_ino=1494277, d_off=7491915799041650922, d_reclen=24, d_name=".", 
> d_type=DT_DIR},
>   {d_ino=1314655, d_off=9223372036854775807, d_reclen=24, d_name="..", 
> d_type=DT_DIR}
> ], 32768) = 88
> 
> When running in 32-bit compat mode, this value is somehow truncated to
> 31 bits, for both the getdents and the getdents64 (!) system call (at
> least on i386).
> 
> In an effort to simplify support for future architectures which only
> have the getdents64 system call, we changed glibc 2.28 to use the
> getdents64 system call unconditionally, and perform translation if
> necessary.  This translation is noteworthy because it includes
> overflow checking for the d_ino and d_off members of struct dirent.
> We did not initially observe a regression because the kernel performs
> consistent d_off truncation (with the ext4 file system; small
> directories do not show this issue on XFS), so the overflow check does
> not fire.
> 
> However, both qemu-user and the 9p file system can run in such a way
> that the kernel is entered from a 64-bit process, but the actual usage
> is from a 32-bit process:
> 
>   
> 
> I think diagrammatically, this looks like this:
> 
>   guest process  (32-bit)
> | getdents64, 32-bit UAPI
>   qemu-user (64-bit)
> | getdents, 64-bit UAPI
>   host kernel (64-bit)
> 
> Or:
> 
>   guest process 
> | getdents64, 32-bit UAPI
>   guest kernel (64-bit)
> | 9p over virtio (64-bit d_off in struct p9_dirent)
>   qemu
> | getdents, 64-bit UAPI
>   host kernel (64-bit)
> 
> Back when we still called getdents, in the first case, the 32-bit
> getdents system call emulation in a 64-bit qemu-user process would
> just silently truncate the d_off field as part of the translation, not
> reporting an error.  The second case is more complicated, and I have
> not figured out where the truncation happens.
> 
> This truncation has always been a bug; it breaks telldir/seekdir at
> least in some cases.  But use of telldir/seekdir is comparatively
> rare.  In contrast, now that we detect d_off overflow in glibc,
> readdir will always fail in the sketched configurations, which is bad.
> (glibc exposes the d_off field to applications, and it cannot know
> whether the application will use it or not, so there is no direct way
> to restrict the overflow error to the telldir/seekdir use case.)
> 
> We could switch glibc to call getdents again if the system call is
> available.  But that merely relies on the existence of the truncation
> bug somewhere else in the file system stack.  This is why I don't
> think it's the right solution, just the path of least resistance.
> 
> I don't want to reimplement the ext4 truncation behavior in glibc (it
> doesn't look like a straightforward truncation), and it wouldn't work
> for the second scenario where we see the 9p file system in the 32-bit
> glibc, not the ext4 file system.  So that's not a good solution.

Also for glibc standpoint, although reverting it back to use getdents 
syscall for non-LFS mode might fix this issue for architectures that
provides non-LFS getdents syscall it won't be a fix for architectures 
that still provides off_t different than off64_t *and* only provides 
getdents64 syscall.

Currently we only have nios2 and csky (unfortunately).  But since generic 
definition for off_t and off64_t still assumes non-LFS support, all new
32-bits ports potentially might carry the issue.

> 
> There is another annoying aspect: The standards expose d_off through
> the telldir function, and that returns long int on all architectures
> (not off_t, so unchanged by _FILE_OFFSET_BITS).  That's mostly a
> userspace issue and thus needing different steps to resolve (possibly
> standards action).
> 
> Any suggestions how to solve this?  Why does the kernel return
> different d_off values for 32-bit and 64-bit processes even when using
> getdents64, for the same directory?
> 

Re: [Qemu-devel] d_off field in struct dirent and 32-on-64 emulation

[Florian Weimer]

* Andy Lutomirski:

>> On Dec 27, 2018, at 10:18 AM, Florian Weimer  wrote:
>> 
>> We have a bit of an interesting problem with respect to the d_off
>> field in struct dirent.
>> 
>> When running a 64-bit kernel on certain file systems, notably ext4,
>> this field uses the full 63 bits even for small directories (strace -v
>> output, wrapped here for readability):
>> 
>> getdents(3, [
>>  {d_ino=1494304, d_off=3901177228673045825, d_reclen=40,
>> d_name="authorized_keys", d_type=DT_REG},
>>  {d_ino=1494277, d_off=7491915799041650922, d_reclen=24, d_name=".",
>> d_type=DT_DIR},
>>  {d_ino=1314655, d_off=9223372036854775807, d_reclen=24,
>> d_name="..", d_type=DT_DIR}
>> ], 32768) = 88
>> 
>> When running in 32-bit compat mode, this value is somehow truncated to
>> 31 bits, for both the getdents and the getdents64 (!) system call (at
>> least on i386).
>
> I imagine you’re encountering this bug:
>
> https://lkml.org/lkml/2018/10/18/859

It's definitely in this area.  However, the original collision problem
with 32-bit hashes is also real, so I can see the desire to use more
bits.

> Presumably the right fix involves modifying the relevant VFS file
> operations to indicate the relevant ABI to the implementations.

Not sure.  How does NFS solve this problem when access happens from a
32-bit process and the rest (client kernel, transport, server kernel)
is 64-bit all the way?

> I would guess that 9p is triggering the “not really in the syscall you
> think you’re in” issue.

I think the issue is more like the networking case for 9p.  In this
scenario, the server shouldn't have to care whether the client process
is in 32-bit mode or 64-bit mode.  But maybe the only solution is to
pass through some sort of flag, as Peter Maydell has just suggested.

Re: [Qemu-devel] d_off field in struct dirent and 32-on-64 emulation

[Peter Maydell]

On Thu, 27 Dec 2018 at 17:19, Florian Weimer  wrote:
> We have a bit of an interesting problem with respect to the d_off
> field in struct dirent.
>
> When running a 64-bit kernel on certain file systems, notably ext4,
> this field uses the full 63 bits even for small directories (strace -v
> output, wrapped here for readability):
>
> getdents(3, [
>   {d_ino=1494304, d_off=3901177228673045825, d_reclen=40, 
> d_name="authorized_keys", d_type=DT_REG},
>   {d_ino=1494277, d_off=7491915799041650922, d_reclen=24, d_name=".", 
> d_type=DT_DIR},
>   {d_ino=1314655, d_off=9223372036854775807, d_reclen=24, d_name="..", 
> d_type=DT_DIR}
> ], 32768) = 88
>
> When running in 32-bit compat mode, this value is somehow truncated to
> 31 bits, for both the getdents and the getdents64 (!) system call (at
> least on i386).

Yes -- look for hash2pos() and friends in fs/ext4/dir.c.
The ext4 code in the kernel uses a 32 bit hash if (a) the kernel
is 32 bit (b) this is a compat syscall (b) some other bit of
the kernel asked it to via the FMODE_32BITHASH flag (currently only
NFS does that I think).

As you note, this causes breakage for userspace programs which
need to implement an API/ABI with 32-bit offset but which only
have access to the kernel's 64-bit offset API/ABI.

I think the best fix for this would be for the kernel to either
(a) consistently use a 32-bit hash or (b) to provide an API
so that userspace can use the FMODE_32BITHASH flag the way
that kernel-internal users already can.

I couldn't think of or find any existing way for userspace
to get the right results here, which is why
32-bit-guest-on-64-bit-host QEMU doesn't work on these filesystems
(depending on what exactly the guest's libc etc do).

> the 32-bit getdents system call emulation in a 64-bit qemu-user
> process would just silently truncate the d_off field as part of
> the translation, not reporting an error.
> [...]
> This truncation has always been a bug; it breaks telldir/seekdir
> at least in some cases.

Yes; you can't fit a quart into a pint pot, so if the guest
only handles 32-bit offsets then truncation is about all we
can do. This works fine if offsets are offsets, assuming the
directory isn't so enormous it would have broken the guest
anyway. I'm not aware of any issues with this other than the
oddball ext4 offsets-are-hashes situation -- could you expand
on the telldir/seekdir issue? (I suppose we should probably
make QEMU's syscall emulation layer return "no more entries"
rather than entries with truncated hashes.)

thanks
-- PMM

Re: [Qemu-devel] d_off field in struct dirent and 32-on-64 emulation

[Andy Lutomirski]

> On Dec 27, 2018, at 10:18 AM, Florian Weimer  wrote:
> 
> We have a bit of an interesting problem with respect to the d_off
> field in struct dirent.
> 
> When running a 64-bit kernel on certain file systems, notably ext4,
> this field uses the full 63 bits even for small directories (strace -v
> output, wrapped here for readability):
> 
> getdents(3, [
>  {d_ino=1494304, d_off=3901177228673045825, d_reclen=40, 
> d_name="authorized_keys", d_type=DT_REG},
>  {d_ino=1494277, d_off=7491915799041650922, d_reclen=24, d_name=".", 
> d_type=DT_DIR},
>  {d_ino=1314655, d_off=9223372036854775807, d_reclen=24, d_name="..", 
> d_type=DT_DIR}
> ], 32768) = 88
> 
> When running in 32-bit compat mode, this value is somehow truncated to
> 31 bits, for both the getdents and the getdents64 (!) system call (at
> least on i386).

I imagine you’re encountering this bug:

https://lkml.org/lkml/2018/10/18/859

Presumably the right fix involves modifying the relevant VFS file operations to 
indicate the relevant ABI to the implementations.

I would guess that 9p is triggering the “not really in the syscall you think 
you’re in” issue.

Re: [Qemu-devel] [PATCH] scripts/qemugdb: support coroutine backtrace in coredumps

[Vladimir Sementsov-Ogievskiy]

23.04.2018 16:28, Pedro Alves wrote:
> On 04/23/2018 02:37 AM, Simon Marchi wrote:
>> On 2018-04-09 10:08 PM, Stefan Hajnoczi wrote:
>>> I wonder what the point of select-frame is then...
>>>
>>> I have CCed the GDB mailing list.  Maybe someone can help us.  Context:
>>>
>>> QEMU implements coroutines using jmpbuf.  We'd like to print coroutine
>>> call stacks in GDB and have a script that works when a process is being
>>> debugged (it sets the registers).
>>>
>>> Now we'd like to extend the script to work on core dumps where it's not
>>> possible to set registers (since there is no process being debugged).
>>>
>>> Is there a way to backtrace an arbitrary call stack in a core dump?
>>
>> Not that I know of.  The "frame  " form of the frame
>> command sounds like it should be usable to achieve that, but it doesn't
>> seem to work in that way.  I really wonder if it's working as it was
>> intended initially.  I guess using that form of the frame command should
>> override/mask the real current values of $sp and $pc?
> 
> Yeah, "frame " has a lot of problems.
> 
> This series was working toward sorting out the "frame" command:
> 
>https://sourceware.org/ml/gdb-patches/2015-09/msg00248.html
> 
> Follow the urls there for more background.
> 
> To me, the important questions to answer are here:
>   https://sourceware.org/ml/gdb-patches/2015-09/msg00658.html
> 
> Unfortunately, I don't think the series moved past that point.
> 
> Thanks,
> Pedro Alves
> 


Hi Pedro!

Hmm, returned to this topic. I've spent this day digging in gdb code, and found 
it much
more difficult than qemu)..

I've failed to find something like

create_frame_with_registers, or create_thread_with_registers.. Looks like 
registers comes
from some register caches, backed by different sources of registers or 
something like this.

So, I'd like to ask several questions:

1. Any news on the topic since April?

2. Can you propose a simple (maybe hacky) way (with or without patching gdb) to 
achieve the behavior like

set $rsp = ...
set $rbp = ...
set $rip = ...

bt #prints bt, starting from the frame corresponding to register values set
fr 5 #goes to frame in this bt, and allow to examine local variables

for debugging core-dumps?

***

May be, we can allow set registers while debugging core-dump? Why we can't set 
them? We have
same register caches, and anyway we can move between threads and frames and 
registers are changed...

May be, we can somehow add separate thread with given registers from user, like 
they are created from
coredump file..

Anything else?

***

For me, still, the simplest way is to add additional note segments to coredump 
file, to specify needed frames..
But it is not very comfortable, to recreate and reopen core file, when found 
new coroutine.

-- 
Best regards,
Vladimir

Re: [Qemu-devel] [PATCH 5/6] target/mips: MXU: Add handlers for max/min instructions

[Janeczek, Craig via Qemu-devel]

On 17.12.18. 21:04, Aleksandar Markovic wrote:
> From: Aleksandar Markovic 
>
> Add translation handlers for max/min MXU instructions.
>
> Signed-off-by: Aleksandar Markovic 
> ---
>   target/mips/translate.c | 356 +---
>   1 file changed, 335 insertions(+), 21 deletions(-)


Reviewed-by: Stefan Markovic 


> diff --git a/target/mips/translate.c b/target/mips/translate.c index 
> c74a831a17..339de8c32b 100644
> --- a/target/mips/translate.c
> +++ b/target/mips/translate.c
> @@ -24815,6 +24815,338 @@ static void gen_mxu_S32XOR(DisasContext *ctx)
>   }
>   
>   
> +/*
> + *   MXU instruction category max/min
> + *   
> + *
> + * S32MAX D16MAX Q8MAX
> + * S32MIN D16MIN Q8MIN
> + */
> +
> +/*
> + *  S32MAX XRa, XRb, XRc
> + *Update XRa with the maximum of signed 32-bit integers contained
> + *in XRb and XRc.
> + *
> + *  S32MIN XRa, XRb, XRc
> + *Update XRa with the minimum of signed 32-bit integers contained
> + *in XRb and XRc.
> + *
> + *   1 0 9 8 7 6 5 4 3 2 1 0 9 8 7 6 5 4 3 2 1 0 9 8 7 6 5 4 3 2 1 0
> + *  +---+-+-+---+---+---+---+
> + *  |  SPECIAL2 |0 0 0 0 0| opc |  XRc  |  XRb  |  XRa  |MXU__POOL00|
> + *  +---+-+-+---+---+---+---+
> + */
> +static void gen_mxu_S32MAX_S32MIN(DisasContext *ctx) {
> +uint32_t pad, opc, XRc, XRb, XRa;
> +
> +pad = extract32(ctx->opcode, 21, 5);
> +opc = extract32(ctx->opcode, 18, 3);
> +XRc = extract32(ctx->opcode, 14, 4);
> +XRb = extract32(ctx->opcode, 10, 4);
> +XRa = extract32(ctx->opcode,  6, 4);
> +
> +if (unlikely(pad != 0)) {
> +/* opcode padding incorrect -> do nothing */
> +} else if (unlikely(XRa == 0)) {
> +/* destination is zero register -> do nothing */
> +} else if (unlikely((XRb == 0) && (XRc == 0))) {
> +/* both operands zero registers -> just set destination to zero */
> +tcg_gen_movi_i32(mxu_gpr[XRa - 1], 0);
> +} else if (unlikely((XRb == 0) || (XRc == 0))) {
> +/* exactly one operand is zero register - find which one is not...*/
> +uint32_t XRx = XRb ? XRb : XRc;
> +/* ...and do max/min operation with one operand 0 */
> +if (opc == OPC_MXU_S32MAX) {
> +tcg_gen_smax_i32(mxu_gpr[XRa - 1], mxu_gpr[XRx - 1], 0);
> +} else {
> +tcg_gen_smin_i32(mxu_gpr[XRa - 1], mxu_gpr[XRx - 1], 0);
> +}
> +} else if (unlikely(XRb == XRc)) {
> +/* both operands same -> just set destination to one of them */
> +tcg_gen_mov_i32(mxu_gpr[XRa - 1], mxu_gpr[XRb - 1]);
> +} else {
> +/* the most general case */
> +if (opc == OPC_MXU_S32MAX) {
> +tcg_gen_smax_i32(mxu_gpr[XRa - 1], mxu_gpr[XRb - 1],
> +   mxu_gpr[XRc - 1]);
> +} else {
> +tcg_gen_smin_i32(mxu_gpr[XRa - 1], mxu_gpr[XRb - 1],
> +   mxu_gpr[XRc - 1]);
> +}
> +}
> +}
> +
> +/*
> + *  D16MAX
> + *Update XRa with the 16-bit-wise maximums of signed integers
> + *contained in XRb and XRc.
> + *
> + *  D16MIN
> + *Update XRa with the 16-bit-wise minimums of signed integers
> + *contained in XRb and XRc.
> + *
> + *   1 0 9 8 7 6 5 4 3 2 1 0 9 8 7 6 5 4 3 2 1 0 9 8 7 6 5 4 3 2 1 0
> + *  +---+-+-+---+---+---+---+
> + *  |  SPECIAL2 |0 0 0 0 0| opc |  XRc  |  XRb  |  XRa  |MXU__POOL00|
> + *  +---+-+-+---+---+---+---+
> + */
> +static void gen_mxu_D16MAX_D16MIN(DisasContext *ctx) {
> +uint32_t pad, opc, XRc, XRb, XRa;
> +
> +pad = extract32(ctx->opcode, 21, 5);
> +opc = extract32(ctx->opcode, 18, 3);
> +XRc = extract32(ctx->opcode, 14, 4);
> +XRb = extract32(ctx->opcode, 10, 4);
> +XRa = extract32(ctx->opcode,  6, 4);
> +
> +if (unlikely(pad != 0)) {
> +/* opcode padding incorrect -> do nothing */
> +} else if (unlikely(XRc == 0)) {
> +/* destination is zero register -> do nothing */
> +} else if (unlikely((XRb == 0) && (XRa == 0))) {
> +/* both operands zero registers -> just set destination to zero */
> +tcg_gen_movi_i32(mxu_gpr[XRc - 1], 0);
> +} else if (unlikely((XRb == 0) || (XRa == 0))) {
> +/* exactly one operand is zero register - find which one is not...*/
> +uint32_t XRx = XRb ? XRb : XRc;
> +/* ...and do half-word-wise max/min with one operand 0 */
> +TCGv_i32 t0 = tcg_temp_new();
> +TCGv_i32 t1 = tcg_const_i32(0);
> +
> +/* the left half-word first */
> +tcg_gen_andi_i32(t0, mxu_gpr[XRx - 1], 0x);
> +if (opc == OPC_MXU_D16MAX) {
> +tcg_gen_smax_i32(mxu_gpr[XRa - 1], t0, t1);
> +} else {
> +  

[Qemu-devel] d_off field in struct dirent and 32-on-64 emulation

[Florian Weimer]

We have a bit of an interesting problem with respect to the d_off
field in struct dirent.

When running a 64-bit kernel on certain file systems, notably ext4,
this field uses the full 63 bits even for small directories (strace -v
output, wrapped here for readability):

getdents(3, [
  {d_ino=1494304, d_off=3901177228673045825, d_reclen=40, 
d_name="authorized_keys", d_type=DT_REG},
  {d_ino=1494277, d_off=7491915799041650922, d_reclen=24, d_name=".", 
d_type=DT_DIR},
  {d_ino=1314655, d_off=9223372036854775807, d_reclen=24, d_name="..", 
d_type=DT_DIR}
], 32768) = 88

When running in 32-bit compat mode, this value is somehow truncated to
31 bits, for both the getdents and the getdents64 (!) system call (at
least on i386).

In an effort to simplify support for future architectures which only
have the getdents64 system call, we changed glibc 2.28 to use the
getdents64 system call unconditionally, and perform translation if
necessary.  This translation is noteworthy because it includes
overflow checking for the d_ino and d_off members of struct dirent.
We did not initially observe a regression because the kernel performs
consistent d_off truncation (with the ext4 file system; small
directories do not show this issue on XFS), so the overflow check does
not fire.

However, both qemu-user and the 9p file system can run in such a way
that the kernel is entered from a 64-bit process, but the actual usage
is from a 32-bit process:

  

I think diagrammatically, this looks like this:

  guest process  (32-bit)
| getdents64, 32-bit UAPI
  qemu-user (64-bit)
| getdents, 64-bit UAPI
  host kernel (64-bit)

Or:

  guest process 
| getdents64, 32-bit UAPI
  guest kernel (64-bit)
| 9p over virtio (64-bit d_off in struct p9_dirent)
  qemu
| getdents, 64-bit UAPI
  host kernel (64-bit)

Back when we still called getdents, in the first case, the 32-bit
getdents system call emulation in a 64-bit qemu-user process would
just silently truncate the d_off field as part of the translation, not
reporting an error.  The second case is more complicated, and I have
not figured out where the truncation happens.

This truncation has always been a bug; it breaks telldir/seekdir at
least in some cases.  But use of telldir/seekdir is comparatively
rare.  In contrast, now that we detect d_off overflow in glibc,
readdir will always fail in the sketched configurations, which is bad.
(glibc exposes the d_off field to applications, and it cannot know
whether the application will use it or not, so there is no direct way
to restrict the overflow error to the telldir/seekdir use case.)

We could switch glibc to call getdents again if the system call is
available.  But that merely relies on the existence of the truncation
bug somewhere else in the file system stack.  This is why I don't
think it's the right solution, just the path of least resistance.

I don't want to reimplement the ext4 truncation behavior in glibc (it
doesn't look like a straightforward truncation), and it wouldn't work
for the second scenario where we see the 9p file system in the 32-bit
glibc, not the ext4 file system.  So that's not a good solution.

There is another annoying aspect: The standards expose d_off through
the telldir function, and that returns long int on all architectures
(not off_t, so unchanged by _FILE_OFFSET_BITS).  That's mostly a
userspace issue and thus needing different steps to resolve (possibly
standards action).

Any suggestions how to solve this?  Why does the kernel return
different d_off values for 32-bit and 64-bit processes even when using
getdents64, for the same directory?

Re: [Qemu-devel] [PATCH 1/6] target/mips: MXU: Add missing opcodes/decoding for LX* instructions

[Janeczek, Craig via Qemu-devel]

On 17.12.18. 21:04, Aleksandar Markovic wrote:
> From: Aleksandar Markovic 
>
> Add missing opcodes and decoding engine for LXB, LXH, LXW, LXBU, and 
> LXHU instructions. They were for some reason forgotten in previous 
> commits. The MXU opcode list and decoding engine should be now 
> complete.
>
> Signed-off-by: Aleksandar Markovic 
> ---
>   target/mips/translate.c | 140 +---
>   1 file changed, 102 insertions(+), 38 deletions(-)


Reviewed-by: Stefan Markovic 


> diff --git a/target/mips/translate.c b/target/mips/translate.c index 
> e9c23a594b..e0c8d8c2f7 100644
> --- a/target/mips/translate.c
> +++ b/target/mips/translate.c
> @@ -1663,12 +1663,21 @@ enum {
>*  │   20..18
>*  ├─ 100111 ─ OPC_MXU__POOL16 ─┬─ 000 ─ OPC_MXU_D32SARW
>*  │├─ 001 ─ OPC_MXU_S32ALN
> - *  ├─ 101000 ─ OPC_MXU_LXB  ├─ 010 ─ OPC_MXU_S32ALNI
> - *  ├─ 101001 ─├─ 011 ─ OPC_MXU_S32NOR
> - *  ├─ 101010 ─ OPC_MXU_S16LDD   ├─ 100 ─ OPC_MXU_S32AND
> - *  ├─ 101011 ─ OPC_MXU_S16STD   ├─ 101 ─ OPC_MXU_S32OR
> - *  ├─ 101100 ─ OPC_MXU_S16LDI   ├─ 110 ─ OPC_MXU_S32XOR
> - *  ├─ 101101 ─ OPC_MXU_S16SDI   └─ 111 ─ OPC_MXU_S32LUI
> + *  │├─ 010 ─ OPC_MXU_S32ALNI
> + *  │├─ 011 ─ OPC_MXU_S32NOR
> + *  │├─ 100 ─ OPC_MXU_S32AND
> + *  │├─ 101 ─ OPC_MXU_S32OR
> + *  │├─ 110 ─ OPC_MXU_S32XOR
> + *  │└─ 111 ─ OPC_MXU_S32LUI
The opcodes for pool 16 do not look correct. I think the minor bits should look 
like the following.

┬─ 000 ─ OPC_MXU_D32SARW
├─ 001 ─ OPC_MXU_S32ALN
├─ 010 ─ OPC_MXU_S32ALNI
├─ 011 ─ OPC_MXU_S32LUI
├─ 100 ─ OPC_MXU_S32NOR
├─ 101 ─ OPC_MXU_S32AND
├─ 110 ─ OPC_MXU_S32OR
└─ 111 ─ OPC_MXU_S32XOR

> + *  │
> + *  │   7..5
> + *  ├─ 101000 ─ OPC_MXU__POOL17 ─┬─ 000 ─ OPC_MXU_LXB
> + *  │├─ 001 ─ OPC_MXU_LXH
> + *  ├─ 101001 ─├─ 011 ─ OPC_MXU_LXW
> + *  ├─ 101010 ─ OPC_MXU_S16LDD   ├─ 100 ─ OPC_MXU_LXBU
> + *  ├─ 101011 ─ OPC_MXU_S16STD   └─ 101 ─ OPC_MXU_LXHU
> + *  ├─ 101100 ─ OPC_MXU_S16LDI
> + *  ├─ 101101 ─ OPC_MXU_S16SDI
>*  ├─ 101110 ─ OPC_MXU_S32M2I
>*  ├─ 10 ─ OPC_MXU_S32I2M
>*  ├─ 11 ─ OPC_MXU_D32SLL
> @@ -1678,15 +1687,15 @@ enum {
>*  ├─ 110100 ─ OPC_MXU_Q16SLL   ├─ 010 ─ OPC_MXU_D32SARV
>*  ├─ 110101 ─ OPC_MXU_Q16SLR   ├─ 011 ─ OPC_MXU_Q16SLLV
>*  │├─ 100 ─ OPC_MXU_Q16SLRV
> - *  ├─ 110110 ─ OPC_MXU__POOL17 ─┴─ 101 ─ OPC_MXU_Q16SARV
> + *  ├─ 110110 ─ OPC_MXU__POOL18 ─┴─ 101 ─ OPC_MXU_Q16SARV
>*  │
>*  ├─ 110111 ─ OPC_MXU_Q16SAR
>*  │   23..22
> - *  ├─ 111000 ─ OPC_MXU__POOL18 ─┬─ 00 ─ OPC_MXU_Q8MUL
> + *  ├─ 111000 ─ OPC_MXU__POOL19 ─┬─ 00 ─ OPC_MXU_Q8MUL
>*  │└─ 01 ─ OPC_MXU_Q8MULSU
>*  │
>*  │   20..18
> - *  ├─ 111001 ─ OPC_MXU__POOL19 ─┬─ 000 ─ OPC_MXU_Q8MOVZ
> + *  ├─ 111001 ─ OPC_MXU__POOL20 ─┬─ 000 ─ OPC_MXU_Q8MOVZ
>*  │├─ 001 ─ OPC_MXU_Q8MOVN
>*  │├─ 010 ─ OPC_MXU_D16MOVZ
>*  │├─ 011 ─ OPC_MXU_D16MOVN
> @@ -1694,7 +1703,7 @@ enum {
>*  │└─ 101 ─ OPC_MXU_S32MOV
>*  │
>*  │   23..22
> - *  ├─ 111010 ─ OPC_MXU__POOL20 ─┬─ 00 ─ OPC_MXU_Q8MAC
> + *  ├─ 111010 ─ OPC_MXU__POOL21 ─┬─ 00 ─ OPC_MXU_Q8MAC
>*  │└─ 10 ─ OPC_MXU_Q8MACSU
>*  ├─ 111011 ─ OPC_MXU_Q16SCOP
>*  ├─ 00 ─ OPC_MXU_Q8MADL
> @@ -1750,7 +1759,7 @@ enum {
>   OPC_MXU_S8SDI= 0x25,
>   OPC_MXU__POOL15  = 0x26,
>   OPC_MXU__POOL16  = 0x27,
> -OPC_MXU_LXB  = 0x28,
> +OPC_MXU__POOL17  = 0x28,
>   /* not assigned 0x29 */
>   OPC_MXU_S16LDD   = 0x2A,
>   OPC_MXU_S16STD   = 0x2B,
> @@ -1764,11 +1773,11 @@ enum {
>   OPC_MXU_D32SAR   = 0x33,
>   OPC_MXU_Q16SLL   = 0x34,
>   OPC_MXU_Q16SLR   = 0x35,
> -OPC_MXU__POOL17  = 0x36,
> +OPC_MXU__POOL18  = 0x36,
>   OPC_MXU_Q16SAR   = 0x37,
> -OPC_MXU__POOL18  = 0x38,
> -OPC_MXU__POOL19  = 0x39,
> -OPC_MXU__POOL20  = 0x3A,
> +OPC_MXU__POOL19  = 0x38,
> +OPC_MXU__POOL20  = 0x39,
> +OPC_MXU__POOL21  = 0x3A,
>   OPC_MXU_Q16SCOP  = 0x3B,
>   OPC_MXU_Q8MADL   = 0x3C,
>   OPC_MXU_S32SFL   = 0x3D,
> @@ -1940,6 

Re: [Qemu-devel] [PATCH] atomic.h: Set ATOMIC_REG_SIZE=8 for MIPS n32

[Aleksandar Markovic]

> On 12/5/18 11:11 PM, Paul Burton wrote:
> ATOMIC_REG_SIZE is currently defined as the default sizeof(void *) for
> all MIPS host builds, including those using the n32 ABI. n32 is the
> MIPS64 ILP32 ABI and as such tcg/mips/tcg-target.h defines
> TCG_TARGET_REG_BITS as 64 for n32 builds. If we attempt to build QEMU
> for an n32 host with support for a 64b target architecture then
> TCG_OVERSIZED_GUEST is 0 and accel/tcg/cputlb.c attempts to use atomic_*
> functions. This fails because ATOMIC_REG_SIZE is 4, causing the calls to
> QEMU_BUILD_BUG_ON(sizeof(*ptr) > ATOMIC_REG_SIZE) in the various
> atomic_* functions to generate errors.
>
> Fix this by defining ATOMIC_REG_SIZE as 8 for all MIPS64 builds, which
> will cover both n32 (ILP32) & n64 (LP64) ABIs in much the same was as we
> already do for x86_64/x32.
>
> Signed-off-by: Paul Burton 

I am going to include this patch in next mips pull request scheduled for
today or tomorrow.

Aleksandar

Re: [Qemu-devel] vfio failure with intel 760p 128GB nvme

[Dongli Zhang]

Hi Alex,

On 12/27/2018 10:20 PM, Alex Williamson wrote:
> On Thu, 27 Dec 2018 20:30:48 +0800
> Dongli Zhang  wrote:
> 
>> Hi Alex,
>>
>> On 12/02/2018 09:29 AM, Dongli Zhang wrote:
>>> Hi Alex,
>>>
>>> On 12/02/2018 03:29 AM, Alex Williamson wrote:  
 On Sat, 1 Dec 2018 10:52:21 -0800 (PST)
 Dongli Zhang  wrote:
  
> Hi,
>
> I obtained below error when assigning an intel 760p 128GB nvme to guest 
> via
> vfio on my desktop:
>
> qemu-system-x86_64: -device vfio-pci,host=:01:00.0: vfio 
> :01:00.0: failed to add PCI capability 0x11[0x50]@0xb0: table & pba 
> overlap, or they don't fit in BARs, or don't align
>
>
> This is because the msix table is overlapping with pba. According to below
> 'lspci -vv' from host, the distance between msix table offset and pba 
> offset is
> only 0x100, although there are 22 entries supported (22 entries need 
> 0x160).
> Looks qemu supports at most 0x800.
>
> # sudo lspci -vv
> ... ...
> 01:00.0 Non-Volatile memory controller: Intel Corporation Device f1a6 
> (rev 03) (prog-if 02 [NVM Express])
>   Subsystem: Intel Corporation Device 390b
> ... ...
>   Capabilities: [b0] MSI-X: Enable- Count=22 Masked-
>   Vector table: BAR=0 offset=2000
>   PBA: BAR=0 offset=2100
>
>
>
> A patch below could workaround the issue and passthrough nvme 
> successfully.
>
> diff --git a/hw/vfio/pci.c b/hw/vfio/pci.c
> index 5c7bd96..54fc25e 100644
> --- a/hw/vfio/pci.c
> +++ b/hw/vfio/pci.c
> @@ -1510,6 +1510,11 @@ static void vfio_msix_early_setup(VFIOPCIDevice 
> *vdev, Error **errp)
>  msix->pba_offset = pba & ~PCI_MSIX_FLAGS_BIRMASK;
>  msix->entries = (ctrl & PCI_MSIX_FLAGS_QSIZE) + 1;
>  
> +if (msix->table_bar == msix->pba_bar &&
> +msix->table_offset + msix->entries * PCI_MSIX_ENTRY_SIZE > 
> msix->pba_offset) {
> +msix->entries = (msix->pba_offset - msix->table_offset) / 
> PCI_MSIX_ENTRY_SIZE;
> +}
> +
>  /*
>   * Test the size of the pba_offset variable and catch if it extends 
> outside
>   * of the specified BAR. If it is the case, we need to apply a 
> hardware
>
>
> Would you please help confirm if this can be regarded as bug in qemu, or 
> issue
> with nvme hardware? Should we fix thin in qemu, or we should never use 
> such buggy
> hardware with vfio?  

 It's a hardware bug, is there perhaps a firmware update for the device
 that resolves it?  It's curious that a vector table size of 0x100 gives
 us 16 entries and 22 in hex is 0x16 (table size would be reported as
 0x15 for the N-1 algorithm).  I wonder if there's a hex vs decimal
 mismatch going on.  We don't really know if the workaround above is
 correct, are there really 16 entries or maybe does the PBA actually
 start at a different offset?  We wouldn't want to generically assume
 one or the other.  I think we need Intel to tell us in which way their
 hardware is broken and whether it can or is already fixed in a firmware
 update.  Thanks,  
>>>
>>> Thank you very much for the confirmation.
>>>
>>> Just realized looks this would make trouble to my desktop as well when 17
>>> vectors are used.
>>>
>>> I will report to intel and confirm how this can happen and if there is any
>>> firmware update available for this issue.
>>>   
>>
>> I found there is similar issue reported to kvm:
>>
>> https://bugzilla.kernel.org/show_bug.cgi?id=202055
>>
>>
>> I confirmed with my env again. By default, the msi-x count is 16.
>>
>>  Capabilities: [b0] MSI-X: Enable+ Count=16 Masked-
>>  Vector table: BAR=0 offset=2000
>>  PBA: BAR=0 offset=2100
>>
>>
>> The count is still 16 after the device is assigned to vfio (Enable- now):
>>
>> # echo :01:00.0 > /sys/bus/pci/devices/\:01\:00.0/driver/unbind
>> # echo "8086 f1a6" > /sys/bus/pci/drivers/vfio-pci/new_id
>>
>> Capabilities: [b0] MSI-X: Enable- Count=16 Masked-
>>  Vector table: BAR=0 offset=2000
>>  PBA: BAR=0 offset=2100
>>
>>
>> After I boot qemu with "-device vfio-pci,host=:01:00.0", count becomes 
>> 22.
>>
>> Capabilities: [b0] MSI-X: Enable- Count=22 Masked-
>>  Vector table: BAR=0 offset=2000
>>  PBA: BAR=0 offset=2100
>>
>>
>>
>> Another interesting observation is, vfio-based userspace nvme also changes 
>> count
>> from 16 to 22.
>>
>> I reboot host and the count is reset to 16. Then I boot VM with "-drive
>> file=nvme://:01:00.0/1,if=none,id=nvmedrive0 -device
>> virtio-blk,drive=nvmedrive0,id=nvmevirtio0". As userspace nvme uses different
>> vfio path, it boots successfully without issue.
>>
>> However, the count becomes 22 then:
>>
>> Capabilities: [b0] MSI-X: Enable- Count=22 Masked-
>> 

Re: [Qemu-devel] [PATCH v3 1/2] intel-iommu: differentiate host address width from IOVA address width.

[Eduardo Habkost]

On Wed, Dec 26, 2018 at 01:30:00PM +0800, Yu Zhang wrote:
> On Tue, Dec 25, 2018 at 11:56:19AM -0500, Michael S. Tsirkin wrote:
> > On Sat, Dec 22, 2018 at 09:11:26AM +0800, Yu Zhang wrote:
> > > On Fri, Dec 21, 2018 at 02:02:28PM -0500, Michael S. Tsirkin wrote:
> > > > On Sat, Dec 22, 2018 at 01:37:58AM +0800, Yu Zhang wrote:
> > > > > On Fri, Dec 21, 2018 at 12:04:49PM -0500, Michael S. Tsirkin wrote:
> > > > > > On Sat, Dec 22, 2018 at 12:09:44AM +0800, Yu Zhang wrote:
> > > > > > > Well, my understanding of the vt-d spec is that the address 
> > > > > > > limitation in
> > > > > > > DMAR are referring to the same concept of CPUID.MAXPHYSADDR. I do 
> > > > > > > not think
> > > > > > > there's any different in the native scenario. :)
> > > > > > 
> > > > > > I think native machines exist on which the two values are different.
> > > > > > Is that true?
> > > > > 
> > > > > I think the answer is not. My understanding is that HAW(host address 
> > > > > wdith) is
> > > > > the maximum physical address width a CPU can detects(by 
> > > > > cpuid.0x8008).
> > > > > 
> > > > > I agree there are some addresses the CPU does not touch, but they are 
> > > > > still in
> > > > > the physical address space, and there's only one physical address 
> > > > > space...
> > > > > 
> > > > > B.R.
> > > > > Yu
> > > > 
> > > > Ouch I thought we are talking about the virtual address size.
> > > > I think I did have a box where VTD's virtual address size was
> > > > smaller than CPU's.
> > > > For physical one - we just need to make it as big as max supported
> > > > memory right?
> > > 
> > > Well, my understanding of the physical one is the maximum physical address
> > > width. Sorry, this explain seems nonsense... I mean, it's not just about
> > > the max supported memory, but also covers MMIO. It shall be detectable
> > > from cpuid, or ACPI's DMAR table, instead of calculated by the max memory
> > > size. One common usage of this value is to tell the paging structure 
> > > entries(
> > > CPU's or IOMMU's) which bits shall be reserved. There are also some 
> > > registers
> > > e.g. apic base reg etc, whose contents are physical addresses, therefore 
> > > also
> > > need to follow the similar requirement for the reserved bits.
> > > 
> > > So I think the correct direction might be to define this property in the
> > > machine status level, instead of the CPU level. Is this reasonable to you?
> > 
> > At that level yes. But isn't this already specified by "pci-hole64-end"?
> 
> But this value is set by guest firmware? Will PCI hotplug change this address?
> 
> @Eduardo, do you have any plan to calculate the phys-bits by "pci-hole64-end"?
> Or introduce another property, say "max-phys-bits" in machine status?

I agree it may make sense to make the machine code control
phys-bits instead of the CPU object.  A machine property sounds
like the simplest solution.

But I don't think we can have a meaningful discussion about
implementation if we don't agree about the command-line
interface.  We must decide what will happen to the CPU and iommu
physical address width in cases like:

  $QEMU -device intel-iommu
  $QEMU -cpu ...,phys-bits=50 -device intel-iommu
  $QEMU -cpu ...,host-phys-bits=on -device intel-iommu
  $QEMU -machine phys-bits=50 -device intel-iommu
  $QEMU -machine phys-bits=50 -cpu ...,phys-bits=48 -device intel-iommu

-- 
Eduardo

Re: [Qemu-devel] [PATCH v6 00/26] disas: nanoMIPS: Clean up several issues

[Aleksandar Rikalo]

> From: Aleksandar Markovic 
> Sent: Thursday, December 27, 2018 3:22 PM
> To: qemu-devel@nongnu.org
> Cc: aurel...@aurel32.net; Aleksandar Markovic; Stefan Markovic; Aleksandar 
> Rikalo
> Subject: [PATCH v6 00/26] disas: nanoMIPS: Clean up several issues
>
> From: Aleksandar Markovic 
>
> Clean up several misc issues in nanoMIPS disassembler. There are
> more issues to be cleaned, and this is meant to be just the first
> phase. Complete cleanup should happen over the course of next
> few months.
>
> All these changes should not and do not affect any functionality.

For the whole series:
Reviewed-by: Aleksandar Rikalo 

> v5->v6:
>
>   - patches that deal with adding format specifiers [16] and [49]
> removed, until we determine what is the most appropriate form,
> and how to be more in sync with objdump output and inline
> assembler allowed formats
>   - added 14 patches on reformating grp decoders
>   - added a patch that adds documentation as reference
>
> v4->v5:
>
>   - renamed patch "Fix comments for 48-bit instructions" to
>   "Clean up handling of 48-bit instructions"
>   - added patch "Clean up handling of 16-bit logic instructions"
>   - added eight patches on improving gpr decoders
>   - minor addition to patch "Fix order of more invocations"
>   - minor cleanups of previous commit messages
>
> v3->v4:
>
>   - added patch "Name more functions in a more descriptive way"
>   - added patch "Fix order of more invocations"
>   - added patch "Fix comments for 48-bit instructions"
>   - minor cleanups of previous commit messages
>
> v2->v3:
>
>   - added three patches that fix function misnomers.
>   - minor changes in commit messages.
>
> v1->v2:
>
>   - patch 5 was somehow lost in v1, now should be fine.
>
> Aleksandar Markovic (26):
>   disas: nanoMIPS: Fix preamble text in nanomips.* files
>   disas: nanoMIPS: Remove functions that are not used
>   disas: nanoMIPS: Fix a function misnomer
>   disas: nanoMIPS: Fix order of some invocations
>   disas: nanoMIPS: Name some functions in a more descriptive way
>   disas: nanoMIPS: Fix an FP-related misnomer 1
>   disas: nanoMIPS: Fix an FP-related misnomer 2
>   disas: nanoMIPS: Fix an FP-related misnomer 3
>   disas: nanoMIPS: Name more functions in a more descriptive way
>   disas: nanoMIPS: Fix order of more invocations
>   disas: nanoMIPS: Rename the decoder of 'gpr3' gpr encoding type
>   disas: nanoMIPS: Comment the decoder of 'gpr3' gpr encoding type
>   disas: nanoMIPS: Rename the decoder of 'gpr3.src.store' gpr encoding
> type
>   disas: nanoMIPS: Comment the decoder of 'gpr3.src.store' gpr encoding
> type
>   disas: nanoMIPS: Rename the decoder of 'gpr4' gpr encoding type
>   disas: nanoMIPS: Comment the decoder of 'gpr4' gpr encoding type
>   disas: nanoMIPS: Rename the decoder of 'gpr4.zero' gpr encoding type
>   disas: nanoMIPS: Comment the decoder of 'gpr4.zero' gpr encoding type
>   disas: nanoMIPS: Rename the decoder of 'gpr2.reg1' gpr encoding type
>   disas: nanoMIPS: Comment the decoder of 'gpr2.reg1' gpr encoding type
>   disas: nanoMIPS: Rename the decoder of 'gpr2.reg2' gpr encoding type
>   disas: nanoMIPS: Comment the decoder of 'gpr2.reg2' gpr encoding type
>   disas: nanoMIPS: Rename the decoder of 'gpr1' gpr encoding type
>   disas: nanoMIPS: Comment the decoder of 'gpr1' gpr encoding type
>   disas: nanoMIPS: Reorder declarations and definitions of gpr decoders
>   disas: nanoMIPS: Add a note on documentation
>
>  disas/nanomips.cpp | 2135 
> ++--
>  disas/nanomips.h   |  115 ++-
>  2 files changed,  insertions(+), 1139 deletions(-)
>
> --
> 2.7.4

Re: [Qemu-devel] [PATCH v6 04/26] disas: nanoMIPS: Fix order of some invocations

[Aleksandar Markovic]

> From: Aleksandar Markovic 
> Subject: [PATCH v6 04/26] disas: nanoMIPS: Fix order of some invocations

> Fix order of extraction function invocations so that extraction
goes from MSB side to LSB side of the given instruction coding
content. This is desireable because of consistency and easier
visual spotting of errors.

The dictionaries list "desireable" as an archaic form of "desirable", so I will 
replace "desireable" with "desirable" in next version of the series, or 
potential pull request.

The same appplies to patch 10.

Thanks,
Aleksandar

Re: [Qemu-devel] [PATCH v3 1/2] intel-iommu: differentiate host address width from IOVA address width.

[Eduardo Habkost]

On Fri, Dec 21, 2018 at 03:13:25PM +0100, Igor Mammedov wrote:
> On Thu, 20 Dec 2018 19:18:01 -0200
> Eduardo Habkost  wrote:
> 
> > On Wed, Dec 19, 2018 at 11:40:37AM +0100, Igor Mammedov wrote:
> > > On Wed, 19 Dec 2018 10:57:17 +0800
> > > Yu Zhang  wrote:
> > >   
> > > > On Tue, Dec 18, 2018 at 03:55:36PM +0100, Igor Mammedov wrote:  
> > > > > On Tue, 18 Dec 2018 17:27:23 +0800
> > > > > Yu Zhang  wrote:
> > > > > 
> > > > > > On Mon, Dec 17, 2018 at 02:17:40PM +0100, Igor Mammedov wrote:
> > > > > > > On Wed, 12 Dec 2018 21:05:38 +0800
> > > > > > > Yu Zhang  wrote:
> > > > > > > 
> > > > > > > > Currently, vIOMMU is using the value of IOVA address width, 
> > > > > > > > instead of
> > > > > > > > the host address width(HAW) to calculate the number of reserved 
> > > > > > > > bits in
> > > > > > > > data structures such as root entries, context entries, and 
> > > > > > > > entries of
> > > > > > > > DMA paging structures etc.
> > > > > > > > 
> > > > > > > > However values of IOVA address width and of the HAW may not 
> > > > > > > > equal. For
> > > > > > > > example, a 48-bit IOVA can only be mapped to host addresses no 
> > > > > > > > wider than
> > > > > > > > 46 bits. Using 48, instead of 46 to calculate the reserved bit 
> > > > > > > > may result
> > > > > > > > in an invalid IOVA being accepted.
> > > > > > > > 
> > > > > > > > To fix this, a new field - haw_bits is introduced in struct 
> > > > > > > > IntelIOMMUState,
> > > > > > > > whose value is initialized based on the maximum physical 
> > > > > > > > address set to
> > > > > > > > guest CPU.
> > > > > > > 
> > > > > > > > Also, definitions such as VTD_HOST_AW_39/48BIT etc. are renamed
> > > > > > > > to clarify.
> > > > > > > > 
> > > > > > > > Signed-off-by: Yu Zhang 
> > > > > > > > Reviewed-by: Peter Xu 
> > > > > > > > ---
> > > > > > > [...]
> > > > > > > 
> > > > > > > > @@ -3100,6 +3104,8 @@ static void 
> > > > > > > > vtd_iommu_replay(IOMMUMemoryRegion *iommu_mr, IOMMUNotifier *n)
> > > > > > > >  static void vtd_init(IntelIOMMUState *s)
> > > > > > > >  {
> > > > > > > >  X86IOMMUState *x86_iommu = X86_IOMMU_DEVICE(s);
> > > > > > > > +CPUState *cs = first_cpu;
> > > > > > > > +X86CPU *cpu = X86_CPU(cs);
> > > > > > > >  
> > > > > > > >  memset(s->csr, 0, DMAR_REG_SIZE);
> > > > > > > >  memset(s->wmask, 0, DMAR_REG_SIZE);
> > > > > > > > @@ -3119,23 +3125,24 @@ static void vtd_init(IntelIOMMUState *s)
> > > > > > > >  s->cap = VTD_CAP_FRO | VTD_CAP_NFR | VTD_CAP_ND |
> > > > > > > >   VTD_CAP_MAMV | VTD_CAP_PSI | VTD_CAP_SLLPS |
> > > > > > > >   VTD_CAP_SAGAW_39bit | VTD_CAP_MGAW(s->aw_bits);
> > > > > > > > -if (s->aw_bits == VTD_HOST_AW_48BIT) {
> > > > > > > > +if (s->aw_bits == VTD_AW_48BIT) {
> > > > > > > >  s->cap |= VTD_CAP_SAGAW_48bit;
> > > > > > > >  }
> > > > > > > >  s->ecap = VTD_ECAP_QI | VTD_ECAP_IRO;
> > > > > > > > +s->haw_bits = cpu->phys_bits;
> > > > > > > Is it possible to avoid accessing CPU fields directly or cpu 
> > > > > > > altogether
> > > > > > > and set phys_bits when iommu is created?
> > > > > > 
> > > > > > Thanks for your comments, Igor.
> > > > > > 
> > > > > > Well, I guess you prefer not to query the CPU capabilities while 
> > > > > > deciding
> > > > > > the vIOMMU features. But to me, they are not that irrelevant.:)
> > > > > > 
> > > > > > Here the hardware address width in vt-d, and the one in 
> > > > > > cpuid.MAXPHYSADDR
> > > > > > are referring to the same concept. In VM, both are the maximum 
> > > > > > guest physical
> > > > > > address width. If we do not check the CPU field here, we will still 
> > > > > > have to
> > > > > > check the CPU field in other places such as build_dmar_q35(), and 
> > > > > > reset the
> > > > > > s->haw_bits again.
> > > > > > 
> > > > > > Is this explanation convincing enough? :)
> > > > > current build_dmar_q35() doesn't do it, it's all new code in this 
> > > > > series that
> > > > > contains not acceptable direct access from one device (iommu) to 
> > > > > another (cpu).   
> > > > > Proper way would be for the owner of iommu to fish limits from 
> > > > > somewhere and set
> > > > > values during iommu creation.
> > > > 
> > > > Well, current build_dmar_q35() doesn't do it, because it is using the 
> > > > incorrect value. :)
> > > > According to the spec, the host address width is the maximum physical 
> > > > address width,
> > > > yet current implementation is using the DMA address width. For me, this 
> > > > is not only
> > > > wrong, but also unsecure. For this point, I think we all agree this 
> > > > need to be fixed.
> > > > 
> > > > As to how to fix it - should we query the cpu fields, I still do not 
> > > > understand why
> > > > this is not acceptable. :)
> > > > 
> > > > I had thought of other approaches before, yet I did not choose:
> > > >   
> > > > 1> Introduce a new parameter, say, 

[Qemu-devel] [PATCH v6 10/26] disas: nanoMIPS: Fix order of more invocations

[Aleksandar Markovic]

From: Aleksandar Markovic 

Fix order of extraction function invocations so that extraction
goes from MSB side to LSB side of the given instruction coding
content. This is desireable because of consistency and easier
visual spotting of errors.

After this patch, all such invocations should be in the desired
order.

Signed-off-by: Aleksandar Markovic 
---
 disas/nanomips.cpp | 260 ++---
 1 file changed, 130 insertions(+), 130 deletions(-)

diff --git a/disas/nanomips.cpp b/disas/nanomips.cpp
index 372af90..69e768b 100644
--- a/disas/nanomips.cpp
+++ b/disas/nanomips.cpp
@@ -1704,8 +1704,8 @@ std::string NMD::ABSQ_S_W(uint64 instruction)
 std::string NMD::ACLR(uint64 instruction)
 {
 uint64 bit_value = extract_bit_23_22_21(instruction);
-int64 s_value = extract_s__se8_15_7_6_5_4_3_2_1_0(instruction);
 uint64 rs_value = extract_rs_20_19_18_17_16(instruction);
+int64 s_value = extract_s__se8_15_7_6_5_4_3_2_1_0(instruction);
 
 std::string bit = IMMEDIATE(copy(bit_value));
 std::string s = IMMEDIATE(copy(s_value));
@@ -1950,9 +1950,9 @@ std::string NMD::ADDIU_R1_SP_(uint64 instruction)
  */
 std::string NMD::ADDIU_R2_(uint64 instruction)
 {
-uint64 u_value = extract_u_2_1_0__s2(instruction);
 uint64 rt3_value = extract_rt3_9_8_7(instruction);
 uint64 rs3_value = extract_rs3_6_5_4(instruction);
+uint64 u_value = extract_u_2_1_0__s2(instruction);
 
 std::string rt3 = GPR(encode_gpr3(rt3_value));
 std::string rs3 = GPR(encode_gpr3(rs3_value));
@@ -2609,8 +2609,8 @@ std::string NMD::APPEND(uint64 instruction)
 std::string NMD::ASET(uint64 instruction)
 {
 uint64 bit_value = extract_bit_23_22_21(instruction);
-int64 s_value = extract_s__se8_15_7_6_5_4_3_2_1_0(instruction);
 uint64 rs_value = extract_rs_20_19_18_17_16(instruction);
+int64 s_value = extract_s__se8_15_7_6_5_4_3_2_1_0(instruction);
 
 std::string bit = IMMEDIATE(copy(bit_value));
 std::string s = IMMEDIATE(copy(s_value));
@@ -2782,8 +2782,8 @@ std::string NMD::BC_32_(uint64 instruction)
  */
 std::string NMD::BC1EQZC(uint64 instruction)
 {
-int64 s_value = extract_s__se14_0_13_to_1_s1(instruction);
 uint64 ft_value = extract_ft_25_24_23_22_21(instruction);
+int64 s_value = extract_s__se14_0_13_to_1_s1(instruction);
 
 std::string ft = FPR(copy(ft_value));
 std::string s = ADDRESS(encode_s_from_address(s_value), 4);
@@ -2804,8 +2804,8 @@ std::string NMD::BC1EQZC(uint64 instruction)
  */
 std::string NMD::BC1NEZC(uint64 instruction)
 {
-int64 s_value = extract_s__se14_0_13_to_1_s1(instruction);
 uint64 ft_value = extract_ft_25_24_23_22_21(instruction);
+int64 s_value = extract_s__se14_0_13_to_1_s1(instruction);
 
 std::string ft = FPR(copy(ft_value));
 std::string s = ADDRESS(encode_s_from_address(s_value), 4);
@@ -2826,8 +2826,8 @@ std::string NMD::BC1NEZC(uint64 instruction)
  */
 std::string NMD::BC2EQZC(uint64 instruction)
 {
-int64 s_value = extract_s__se14_0_13_to_1_s1(instruction);
 uint64 ct_value = extract_ct_25_24_23_22_21(instruction);
+int64 s_value = extract_s__se14_0_13_to_1_s1(instruction);
 
 std::string ct = CPR(copy(ct_value));
 std::string s = ADDRESS(encode_s_from_address(s_value), 4);
@@ -2848,8 +2848,8 @@ std::string NMD::BC2EQZC(uint64 instruction)
  */
 std::string NMD::BC2NEZC(uint64 instruction)
 {
-int64 s_value = extract_s__se14_0_13_to_1_s1(instruction);
 uint64 ct_value = extract_ct_25_24_23_22_21(instruction);
+int64 s_value = extract_s__se14_0_13_to_1_s1(instruction);
 
 std::string ct = CPR(copy(ct_value));
 std::string s = ADDRESS(encode_s_from_address(s_value), 4);
@@ -2870,9 +2870,9 @@ std::string NMD::BC2NEZC(uint64 instruction)
  */
 std::string NMD::BEQC_16_(uint64 instruction)
 {
-uint64 u_value = extract_u_3_2_1_0__s1(instruction);
 uint64 rt3_value = extract_rt3_9_8_7(instruction);
 uint64 rs3_value = extract_rs3_6_5_4(instruction);
+uint64 u_value = extract_u_3_2_1_0__s1(instruction);
 
 std::string rs3 = GPR(encode_rs3_and_check_rs3_lt_rt3(rs3_value));
 std::string rt3 = GPR(encode_gpr3(rt3_value));
@@ -2895,8 +2895,8 @@ std::string NMD::BEQC_16_(uint64 instruction)
 std::string NMD::BEQC_32_(uint64 instruction)
 {
 uint64 rt_value = extract_rt_25_24_23_22_21(instruction);
-int64 s_value = extract_s__se14_0_13_to_1_s1(instruction);
 uint64 rs_value = extract_rs_20_19_18_17_16(instruction);
+int64 s_value = extract_s__se14_0_13_to_1_s1(instruction);
 
 std::string rs = GPR(copy(rs_value));
 std::string rt = GPR(copy(rt_value));
@@ -2919,8 +2919,8 @@ std::string NMD::BEQC_32_(uint64 instruction)
 std::string NMD::BEQIC(uint64 instruction)
 {
 uint64 rt_value = extract_rt_25_24_23_22_21(instruction);
-int64 s_value = extract_s__se11_0_10_9_8_7_6_5_4_3_2_1_0_s1(instruction);
 uint64 u_value = extract_u_17_16_15_14_13_12_11(instruction);
+int64 s_value = 

[Qemu-devel] [PATCH v6 25/26] disas: nanoMIPS: Reorder declarations and definitions of gpr decoders

[Aleksandar Markovic]

From: Aleksandar Markovic 

Reorder declarations and definitions of gpr decoders by number of
input bits of vorresponding encoding type.

Signed-off-by: Aleksandar Markovic 
---
 disas/nanomips.cpp | 200 ++---
 disas/nanomips.h   |   7 +-
 2 files changed, 104 insertions(+), 103 deletions(-)

diff --git a/disas/nanomips.cpp b/disas/nanomips.cpp
index e55361c..ea902f9 100644
--- a/disas/nanomips.cpp
+++ b/disas/nanomips.cpp
@@ -291,6 +291,77 @@ uint64 NMD::renumber_registers(uint64 index, uint64 
*register_list,
 
 
 /*
+ * NMD::decode_gpr_gpr4() - decoder for 'gpr4' gpr encoding type
+ *
+ *   Map a 4-bit code to the 5-bit register space according to this pattern:
+ *
+ *  1   0
+ *5 4 3 2 1 0 9 8 7 6 5 4 3 2 1 0
+ *| | | | | | | | | | | | | | | |
+ *| | | | | | | | | | | | | | | |
+ *| | | | | | | | | | | └---┐
+ *| | | | | | | | | | └---┐ |
+ *| | | | | | | | | └---┐ | |
+ *| | | | | | | | └---┐ | | |
+ *| | | | | | | | | | | | | | | |
+ *| | | | | | | | | | | | | | | |
+ *1 0 9 8 7 6 5 4 3 2 1 0 9 8 7 6 5 4 3 2 1 0 9 8 7 6 5 4 3 2 1 0
+ *  3   2   1   0
+ *
+ *   Used in handling following instructions:
+ *
+ * - ADDU[4X4]
+ * - LW[4X4]
+ * - MOVEP[REV]
+ * - MUL[4X4]
+ * - SW[4X4]
+ */
+uint64 NMD::decode_gpr_gpr4(uint64 d)
+{
+static uint64 register_list[] = {  8,  9, 10, 11,  4,  5,  6,  7,
+  16, 17, 18, 19, 20, 21, 22, 23 };
+return renumber_registers(d, register_list,
+   sizeof(register_list) / sizeof(register_list[0]));
+}
+
+
+/*
+ * NMD::decode_gpr_gpr4_zero() - decoder for 'gpr4.zero' gpr encoding type
+ *
+ *   Map a 4-bit code to the 5-bit register space according to this pattern:
+ *
+ *  1   0
+ *5 4 3 2 1 0 9 8 7 6 5 4 3 2 1 0
+ *| | | | | | | | | | | | | | | |
+ *| | | | | | | | | | | | └-┐
+ *| | | | | | | | | | | └---┐   |
+ *| | | | | | | | | | └---┐ |   |
+ *| | | | | | | | | └---┐ | |   |
+ *| | | | | | | | └---┐ | | |   |
+ *| | | | | | | |   | | | | | | |   |
+ *| | | | | | | |   | | | | | | |   |
+ *1 0 9 8 7 6 5 4 3 2 1 0 9 8 7 6 5 4 3 2 1 0 9 8 7 6 5 4 3 2 1 0
+ *  3   2   1   0
+ *
+ *   This pattern is the same one used for 'gpr4' gpr encoding type, except for
+ * the input value 3, that is mapped to the output value 0 instead of 11.
+ *
+ *   Used in handling following instructions:
+ *
+ * - MOVE.BALC
+ * - MOVEP
+ * - SW[4X4]
+ */
+uint64 NMD::decode_gpr_gpr4_zero(uint64 d)
+{
+static uint64 register_list[] = {  8,  9, 10,  0,  4,  5,  6,  7,
+  16, 17, 18, 19, 20, 21, 22, 23 };
+return renumber_registers(d, register_list,
+   sizeof(register_list) / sizeof(register_list[0]));
+}
+
+
+/*
  * NMD::decode_gpr_gpr3() - decoder for 'gpr3' gpr encoding type
  *
  *   Map a 3-bit code to the 5-bit register space according to this pattern:
@@ -389,106 +460,6 @@ uint64 NMD::decode_gpr_gpr3_src_store(uint64 d)
 
 
 /*
- * NMD::decode_gpr_gpr1() - decoder for 'gpr1' gpr encoding type
- *
- *   Map a 1-bit code to the 5-bit register space according to this pattern:
- *
- *  1 0
- *  | |
- *  | |
- *  | └-┐
- *  └-┐ |
- *| |
- *| |
- *| |
- *| |
- *1 0 9 8 7 6 5 4 3 2 1 0 9 8 7 6 5 4 3 2 1 0 9 8 7 6 5 4 3 2 1 0
- *  3   2   1   0
- *
- *   Used in handling following instruction:
- *
- * - MOVE.BALC
- */
-uint64 NMD::decode_gpr_gpr1(uint64 d)
-{
-static uint64 register_list[] = {  4,  5 };
-return renumber_registers(d, register_list,
-   sizeof(register_list) / sizeof(register_list[0]));
-}
-
-
-/*
- * NMD::decode_gpr_gpr4_zero() - decoder for 'gpr4.zero' gpr encoding type
- *
- *   Map a 4-bit code to the 5-bit register space according to this pattern:
- *
- *

[Qemu-devel] [PATCH v2 6/8] tests: smbios: fetch whole table in one step instead of reading it step by step

[Igor Mammedov]

replace a bunch of ACPI_READ_ARRAY/ACPI_READ_FIELD macro, that read
SMBIOS table field by field with one memread() to fetch whole table
at once and drop no longer used ACPI_READ_ARRAY/ACPI_READ_FIELD macro.

Signed-off-by: Igor Mammedov 
---
V2:
  rebase: s/memread/qtest_memread/
---
 tests/acpi-utils.h   | 17 -
 tests/bios-tables-test.c | 15 +--
 2 files changed, 1 insertion(+), 31 deletions(-)

diff --git a/tests/acpi-utils.h b/tests/acpi-utils.h
index 1aa00db..cb7183e 100644
--- a/tests/acpi-utils.h
+++ b/tests/acpi-utils.h
@@ -30,23 +30,6 @@ typedef struct {
 bool tmp_files_retain;   /* do not delete the temp asl/aml */
 } AcpiSdtTable;
 
-#define ACPI_READ_FIELD(qts, field, addr)\
-do { \
-qtest_memread(qts, addr, , sizeof(field)); \
-addr += sizeof(field);   \
-} while (0)
-
-#define ACPI_READ_ARRAY_PTR(qts, arr, length, addr)  \
-do { \
-int idx; \
-for (idx = 0; idx < length; ++idx) { \
-ACPI_READ_FIELD(qts, arr[idx], addr);\
-}\
-} while (0)
-
-#define ACPI_READ_ARRAY(qts, arr, addr) \
-ACPI_READ_ARRAY_PTR(qts, arr, sizeof(arr) / sizeof(arr[0]), addr)
-
 #define ACPI_ASSERT_CMP(actual, expected) do { \
 char ACPI_ASSERT_CMP_str[5] = {}; \
 memcpy(ACPI_ASSERT_CMP_str, , 4); \
diff --git a/tests/bios-tables-test.c b/tests/bios-tables-test.c
index 8fdd1c1..dcd6be8 100644
--- a/tests/bios-tables-test.c
+++ b/tests/bios-tables-test.c
@@ -406,32 +406,19 @@ static bool smbios_ep_table_ok(test_data *data)
 struct smbios_21_entry_point *ep_table = >smbios_ep_table;
 uint32_t addr = data->smbios_ep_addr;
 
-ACPI_READ_ARRAY(data->qts, ep_table->anchor_string, addr);
+qtest_memread(data->qts, addr, ep_table, sizeof(*ep_table));
 if (memcmp(ep_table->anchor_string, "_SM_", 4)) {
 return false;
 }
-ACPI_READ_FIELD(data->qts, ep_table->checksum, addr);
-ACPI_READ_FIELD(data->qts, ep_table->length, addr);
-ACPI_READ_FIELD(data->qts, ep_table->smbios_major_version, addr);
-ACPI_READ_FIELD(data->qts, ep_table->smbios_minor_version, addr);
-ACPI_READ_FIELD(data->qts, ep_table->max_structure_size, addr);
-ACPI_READ_FIELD(data->qts, ep_table->entry_point_revision, addr);
-ACPI_READ_ARRAY(data->qts, ep_table->formatted_area, addr);
-ACPI_READ_ARRAY(data->qts, ep_table->intermediate_anchor_string, addr);
 if (memcmp(ep_table->intermediate_anchor_string, "_DMI_", 5)) {
 return false;
 }
-ACPI_READ_FIELD(data->qts, ep_table->intermediate_checksum, addr);
-ACPI_READ_FIELD(data->qts, ep_table->structure_table_length, addr);
 if (ep_table->structure_table_length == 0) {
 return false;
 }
-ACPI_READ_FIELD(data->qts, ep_table->structure_table_address, addr);
-ACPI_READ_FIELD(data->qts, ep_table->number_of_structures, addr);
 if (ep_table->number_of_structures == 0) {
 return false;
 }
-ACPI_READ_FIELD(data->qts, ep_table->smbios_bcd_revision, addr);
 if (acpi_calc_checksum((uint8_t *)ep_table, sizeof *ep_table) ||
 acpi_calc_checksum((uint8_t *)ep_table + 0x10,
sizeof *ep_table - 0x10)) {
-- 
2.7.4

[Qemu-devel] [PATCH v6 17/26] disas: nanoMIPS: Rename the decoder of 'gpr4.zero' gpr encoding type

[Aleksandar Markovic]

From: Aleksandar Markovic 

Rename the decoder of 'gpr4.zero' gpr encoding type in nanoMIPS
disassembler.

Signed-off-by: Aleksandar Markovic 
---
 disas/nanomips.cpp | 10 +-
 disas/nanomips.h   |  2 +-
 2 files changed, 6 insertions(+), 6 deletions(-)

diff --git a/disas/nanomips.cpp b/disas/nanomips.cpp
index 014ec06..f4acba8 100644
--- a/disas/nanomips.cpp
+++ b/disas/nanomips.cpp
@@ -396,7 +396,7 @@ uint64 NMD::encode_rd1_from_rd(uint64 d)
 }
 
 
-uint64 NMD::encode_gpr4_zero(uint64 d)
+uint64 NMD::decode_gpr_gpr4_zero(uint64 d)
 {
 static uint64 register_list[] = {  8,  9, 10,  0,  4,  5,  6,  7,
   16, 17, 18, 19, 20, 21, 22, 23 };
@@ -10391,7 +10391,7 @@ std::string NMD::MOVE_BALC(uint64 instruction)
 int64 s_value = extract_s__se21_0_20_to_1_s1(instruction);
 
 std::string rd1 = GPR(encode_rd1_from_rd(rd1_value));
-std::string rtz4 = GPR(encode_gpr4_zero(rtz4_value));
+std::string rtz4 = GPR(decode_gpr_gpr4_zero(rtz4_value));
 std::string s = ADDRESS(encode_s_from_address(s_value), 4);
 
 return img::format("MOVE.BALC %s, %s, %s", rd1, rtz4, s);
@@ -10417,8 +10417,8 @@ std::string NMD::MOVEP(uint64 instruction)
 std::string rd2 = GPR(encode_rd2_reg1(rd2_value));
 std::string re2 = GPR(encode_rd2_reg2(rd2_value));
 /* !! - no conversion function */
-std::string rsz4 = GPR(encode_gpr4_zero(rsz4_value));
-std::string rtz4 = GPR(encode_gpr4_zero(rtz4_value));
+std::string rsz4 = GPR(decode_gpr_gpr4_zero(rsz4_value));
+std::string rtz4 = GPR(decode_gpr_gpr4_zero(rtz4_value));
 
 return img::format("MOVEP %s, %s, %s, %s", rd2, re2, rsz4, rtz4);
 /* hand edited */
@@ -15284,7 +15284,7 @@ std::string NMD::SW_4X4_(uint64 instruction)
 uint64 rs4_value = extract_rs4_4_2_1_0(instruction);
 uint64 u_value = extract_u_3_8__s2(instruction);
 
-std::string rtz4 = GPR(encode_gpr4_zero(rtz4_value));
+std::string rtz4 = GPR(decode_gpr_gpr4_zero(rtz4_value));
 std::string u = IMMEDIATE(copy(u_value));
 std::string rs4 = GPR(decode_gpr_gpr4(rs4_value));
 
diff --git a/disas/nanomips.h b/disas/nanomips.h
index 0734844..917f33e 100644
--- a/disas/nanomips.h
+++ b/disas/nanomips.h
@@ -108,7 +108,7 @@ private:
 uint64 decode_gpr_gpr3(uint64 d);
 uint64 decode_gpr_gpr3_src_store(uint64 d);
 uint64 encode_rd1_from_rd(uint64 d);
-uint64 encode_gpr4_zero(uint64 d);
+uint64 decode_gpr_gpr4_zero(uint64 d);
 uint64 decode_gpr_gpr4(uint64 d);
 uint64 encode_rd2_reg1(uint64 d);
 uint64 encode_rd2_reg2(uint64 d);
-- 
2.7.4

[Qemu-devel] [PATCH v6 24/26] disas: nanoMIPS: Comment the decoder of 'gpr1' gpr encoding type

[Aleksandar Markovic]

From: Aleksandar Markovic 

Comment the decoder of 'gpr1' gpr encoding type in nanoMIPS
disassembler.

Signed-off-by: Aleksandar Markovic 
---
 disas/nanomips.cpp | 21 +
 1 file changed, 21 insertions(+)

diff --git a/disas/nanomips.cpp b/disas/nanomips.cpp
index ec223e8..e55361c 100644
--- a/disas/nanomips.cpp
+++ b/disas/nanomips.cpp
@@ -388,6 +388,27 @@ uint64 NMD::decode_gpr_gpr3_src_store(uint64 d)
 }
 
 
+/*
+ * NMD::decode_gpr_gpr1() - decoder for 'gpr1' gpr encoding type
+ *
+ *   Map a 1-bit code to the 5-bit register space according to this pattern:
+ *
+ *  1 0
+ *  | |
+ *  | |
+ *  | └-┐
+ *  └-┐ |
+ *| |
+ *| |
+ *| |
+ *| |
+ *1 0 9 8 7 6 5 4 3 2 1 0 9 8 7 6 5 4 3 2 1 0 9 8 7 6 5 4 3 2 1 0
+ *  3   2   1   0
+ *
+ *   Used in handling following instruction:
+ *
+ * - MOVE.BALC
+ */
 uint64 NMD::decode_gpr_gpr1(uint64 d)
 {
 static uint64 register_list[] = {  4,  5 };
-- 
2.7.4

[Qemu-devel] [PATCH v2 7/8] tests: acpi: squash sanitize_fadt_ptrs() into test_acpi_fadt_table()

[Igor Mammedov]

some parts of sanitize_fadt_ptrs() do redundant job
  - locating FADT
  - checking original checksum

There is no need to do it as test_acpi_fadt_table() already does that,
so drop duplicate code and move remaining fixup code into
test_acpi_fadt_table().

Signed-off-by: Igor Mammedov 
---
 tests/bios-tables-test.c | 39 ++-
 1 file changed, 10 insertions(+), 29 deletions(-)

diff --git a/tests/bios-tables-test.c b/tests/bios-tables-test.c
index dcd6be8..9139dec 100644
--- a/tests/bios-tables-test.c
+++ b/tests/bios-tables-test.c
@@ -128,6 +128,7 @@ static void test_acpi_fadt_table(test_data *data)
 /* FADT table is 1st */
 AcpiSdtTable table = g_array_index(data->tables, typeof(table), 0);
 uint8_t *fadt_aml = table.aml;
+uint32_t fadt_len = table.aml_len;
 
 ACPI_ASSERT_CMP(table.header->signature, "FACP");
 
@@ -139,35 +140,17 @@ static void test_acpi_fadt_table(test_data *data)
 acpi_fetch_table(data->qts, , _len,
  fadt_aml + 40 /* DSDT */, "DSDT", true);
 g_array_append_val(data->tables, table);
-}
-
-static void sanitize_fadt_ptrs(test_data *data)
-{
-/* fixup pointers in FADT */
-int i;
-
-for (i = 0; i < data->tables->len; i++) {
-AcpiSdtTable *sdt = _array_index(data->tables, AcpiSdtTable, i);
-
-if (memcmp(>header->signature, "FACP", 4)) {
-continue;
-}
 
-/* check original FADT checksum before sanitizing table */
-g_assert(!acpi_calc_checksum(sdt->aml, sdt->aml_len));
-
-memset(sdt->aml + 36, 0, 4); /* sanitize FIRMWARE_CTRL ptr */
-memset(sdt->aml + 40, 0, 4); /* sanitize DSDT ptr */
-if (sdt->header->revision >= 3) {
-memset(sdt->aml + 132, 0, 8); /* sanitize X_FIRMWARE_CTRL ptr */
-memset(sdt->aml + 140, 0, 8); /* sanitize X_DSDT ptr */
-}
-
-/* update checksum */
-sdt->header->checksum = 0;
-sdt->header->checksum -= acpi_calc_checksum(sdt->aml, sdt->aml_len);
-break;
+memset(fadt_aml + 36, 0, 4); /* sanitize FIRMWARE_CTRL ptr */
+memset(fadt_aml + 40, 0, 4); /* sanitize DSDT ptr */
+if (fadt_aml[8 /* FADT Major Version */] >= 3) {
+memset(fadt_aml + 132, 0, 8); /* sanitize X_FIRMWARE_CTRL ptr */
+memset(fadt_aml + 140, 0, 8); /* sanitize X_DSDT ptr */
 }
+
+/* update checksum */
+fadt_aml[9 /* Checksum */] = 0;
+fadt_aml[9 /* Checksum */] -= acpi_calc_checksum(fadt_aml, fadt_len);
 }
 
 static void dump_aml_files(test_data *data, bool rebuild)
@@ -541,8 +524,6 @@ static void test_acpi_one(const char *params, test_data 
*data)
 test_acpi_rsdt_table(data);
 test_acpi_fadt_table(data);
 
-sanitize_fadt_ptrs(data);
-
 if (iasl) {
 if (getenv(ACPI_REBUILD_EXPECTED_AML)) {
 dump_aml_files(data, true);
-- 
2.7.4

[Qemu-devel] [PATCH v6 18/26] disas: nanoMIPS: Comment the decoder of 'gpr4.zero' gpr encoding type

[Aleksandar Markovic]

From: Aleksandar Markovic 

Comment the decoder of 'gpr4.zero' gpr encoding type in nanoMIPS
disassembler.

Signed-off-by: Aleksandar Markovic 
---
 disas/nanomips.cpp | 27 +++
 1 file changed, 27 insertions(+)

diff --git a/disas/nanomips.cpp b/disas/nanomips.cpp
index f4acba8..6578aa3 100644
--- a/disas/nanomips.cpp
+++ b/disas/nanomips.cpp
@@ -396,6 +396,33 @@ uint64 NMD::encode_rd1_from_rd(uint64 d)
 }
 
 
+/*
+ * NMD::decode_gpr_gpr4_zero() - decoder for 'gpr4.zero' gpr encoding type
+ *
+ *   Map a 4-bit code to the 5-bit register space according to this pattern:
+ *
+ *  1   0
+ *5 4 3 2 1 0 9 8 7 6 5 4 3 2 1 0
+ *| | | | | | | | | | | | | | | |
+ *| | | | | | | | | | | | └-┐
+ *| | | | | | | | | | | └---┐   |
+ *| | | | | | | | | | └---┐ |   |
+ *| | | | | | | | | └---┐ | |   |
+ *| | | | | | | | └---┐ | | |   |
+ *| | | | | | | |   | | | | | | |   |
+ *| | | | | | | |   | | | | | | |   |
+ *1 0 9 8 7 6 5 4 3 2 1 0 9 8 7 6 5 4 3 2 1 0 9 8 7 6 5 4 3 2 1 0
+ *  3   2   1   0
+ *
+ *   This pattern is the same one used for 'gpr4' gpr encoding type, except for
+ * the input value 3, that is mapped to the output value 0 instead of 11.
+ *
+ *   Used in handling following instructions:
+ *
+ * - MOVE.BALC
+ * - MOVEP
+ * - SW[4X4]
+ */
 uint64 NMD::decode_gpr_gpr4_zero(uint64 d)
 {
 static uint64 register_list[] = {  8,  9, 10,  0,  4,  5,  6,  7,
-- 
2.7.4

[Qemu-devel] [PATCH v2 5/8] tests: acpi: reuse fetch_table() in vmgenid-test

[Igor Mammedov]

Move fetch_table() into acpi-utils.c renaming it to acpi_fetch_table()
and reuse it in vmgenid-test that reads RSDT and then tables it references,
to find and parse VMGNEID SSDT.
While at it wrap RSDT referenced tables enumeration into FOREACH macro
(similar to what we do with QLIST_FOREACH & co) to reuse it with bios and
vmgenid tests.

Signed-off-by: Igor Mammedov 
---
v2:
  - rebase: s/memread/qtest_memread/
---
 tests/acpi-utils.h   | 23 ++---
 tests/acpi-utils.c   | 35 --
 tests/bios-tables-test.c | 55 +
 tests/vmgenid-test.c | 64 +++-
 4 files changed, 67 insertions(+), 110 deletions(-)

diff --git a/tests/acpi-utils.h b/tests/acpi-utils.h
index 1b0e80d..1aa00db 100644
--- a/tests/acpi-utils.h
+++ b/tests/acpi-utils.h
@@ -22,7 +22,7 @@ typedef struct {
 AcpiTableHeader *header;
 uint8_t *aml;/* aml bytecode from guest */
 };
-gsize aml_len;
+uint32_t aml_len;
 gchar *aml_file;
 gchar *asl;/* asl code generated from aml */
 gsize asl_len;
@@ -47,19 +47,6 @@ typedef struct {
 #define ACPI_READ_ARRAY(qts, arr, addr) \
 ACPI_READ_ARRAY_PTR(qts, arr, sizeof(arr) / sizeof(arr[0]), addr)
 
-#define ACPI_READ_TABLE_HEADER(qts, table, addr) \
-do { \
-ACPI_READ_FIELD(qts, (table)->signature, addr);  \
-ACPI_READ_FIELD(qts, (table)->length, addr); \
-ACPI_READ_FIELD(qts, (table)->revision, addr);   \
-ACPI_READ_FIELD(qts, (table)->checksum, addr);   \
-ACPI_READ_ARRAY(qts, (table)->oem_id, addr); \
-ACPI_READ_ARRAY(qts, (table)->oem_table_id, addr);   \
-ACPI_READ_FIELD(qts, (table)->oem_revision, addr);   \
-ACPI_READ_ARRAY(qts, (table)->asl_compiler_id, addr);\
-ACPI_READ_FIELD(qts, (table)->asl_compiler_revision, addr); \
-} while (0)
-
 #define ACPI_ASSERT_CMP(actual, expected) do { \
 char ACPI_ASSERT_CMP_str[5] = {}; \
 memcpy(ACPI_ASSERT_CMP_str, , 4); \
@@ -73,11 +60,17 @@ typedef struct {
 } while (0)
 
 
+#define ACPI_FOREACH_RSDT_ENTRY(table, table_len, entry_ptr, entry_size) \
+for (entry_ptr = table + 36 /* 1st Entry */; \
+ entry_ptr < table + table_len;  \
+ entry_ptr += entry_size)
 
 uint8_t acpi_calc_checksum(const uint8_t *data, int len);
 uint32_t acpi_find_rsdp_address(QTestState *qts);
-uint32_t acpi_get_rsdt_address(uint8_t *rsdp_table);
 uint64_t acpi_get_xsdt_address(uint8_t *rsdp_table);
 void acpi_parse_rsdp_table(QTestState *qts, uint32_t addr, uint8_t 
*rsdp_table);
+void acpi_fetch_table(QTestState *qts, uint8_t **aml, uint32_t *aml_len,
+  const uint8_t *addr_ptr, const char *sig,
+  bool verify_checksum);
 
 #endif  /* TEST_ACPI_UTILS_H */
diff --git a/tests/acpi-utils.c b/tests/acpi-utils.c
index 17abcc4..cc33b46 100644
--- a/tests/acpi-utils.c
+++ b/tests/acpi-utils.c
@@ -51,14 +51,6 @@ uint32_t acpi_find_rsdp_address(QTestState *qts)
 return off;
 }
 
-uint32_t acpi_get_rsdt_address(uint8_t *rsdp_table)
-{
-uint32_t rsdt_physical_address;
-
-memcpy(_physical_address, _table[16 /* RsdtAddress offset */], 
4);
-return le32_to_cpu(rsdt_physical_address);
-}
-
 uint64_t acpi_get_xsdt_address(uint8_t *rsdp_table)
 {
 uint64_t xsdt_physical_address;
@@ -92,3 +84,30 @@ void acpi_parse_rsdp_table(QTestState *qts, uint32_t addr, 
uint8_t *rsdp_table)
 
 ACPI_ASSERT_CMP64(*((uint64_t *)(rsdp_table)), "RSD PTR ");
 }
+
+/** acpi_fetch_table
+ *  load ACPI table at @addr_ptr offset pointer into buffer and return it in
+ *  @aml, its length in @aml_len and check that signature/checksum matches
+ *  actual one.
+ */
+void acpi_fetch_table(QTestState *qts, uint8_t **aml, uint32_t *aml_len,
+  const uint8_t *addr_ptr, const char *sig,
+  bool verify_checksum)
+{
+uint32_t addr, len;
+
+memcpy(, addr_ptr , sizeof(addr));
+addr = le32_to_cpu(addr);
+qtest_memread(qts, addr + 4, , 4); /* Length of ACPI table */
+*aml_len = le32_to_cpu(len);
+*aml = g_malloc0(*aml_len);
+/* get whole table */
+qtest_memread(qts, addr, *aml, *aml_len);
+
+if (sig) {
+ACPI_ASSERT_CMP(**aml, sig);
+}
+if (verify_checksum) {
+g_assert(!acpi_calc_checksum(*aml, *aml_len));
+}
+}
diff --git a/tests/bios-tables-test.c b/tests/bios-tables-test.c
index 0f6dd84..8fdd1c1 100644
--- a/tests/bios-tables-test.c
+++ b/tests/bios-tables-test.c
@@ -72,34 +72,6 @@ static void free_test_data(test_data *data)
 g_array_free(data->tables, true);
 }
 
-/** fetch_table
- *   load ACPI table at @addr_ptr offset pointer into table descriptor
- *  

[Qemu-devel] [PATCH v2 4/8] tests: acpi: reuse fetch_table() for fetching FACS and DSDT

[Igor Mammedov]

It allows to remove a bit more of code duplication and
reuse common utility to get ACPI tables from guest (modulo RSDP).

While at it, consolidate signature checking into fetch_table() instead
of open-codding it.

Considering FACS is special and doesn't have checksum, make checksum
validation optin, the same goes for signature verification.

PS:
By pure accident, patch also fixes FACS not being tested against
reference table since it wasn't added to data::tables list.
But we managed not to regress it since reference file was added
by commit
   (d25979380 acpi unit-test: add test files)
back in 2013

Signed-off-by: Igor Mammedov 
---
  v2:
- rebase: s/memread/qtest_memread/
---
 tests/bios-tables-test.c | 78 +++-
 1 file changed, 30 insertions(+), 48 deletions(-)

diff --git a/tests/bios-tables-test.c b/tests/bios-tables-test.c
index 8082adc..0f6dd84 100644
--- a/tests/bios-tables-test.c
+++ b/tests/bios-tables-test.c
@@ -28,9 +28,6 @@ typedef struct {
 const char *variant;
 uint32_t rsdp_addr;
 uint8_t rsdp_table[36 /* ACPI 2.0+ RSDP size */];
-uint32_t dsdt_addr;
-uint32_t facs_addr;
-AcpiFacsDescriptorRev1 facs_table;
 GArray *tables;
 uint32_t smbios_ep_addr;
 struct smbios_21_entry_point smbios_ep_table;
@@ -76,11 +73,18 @@ static void free_test_data(test_data *data)
 }
 
 /** fetch_table
- *   load ACPI table at @addr into table descriptor @sdt_table
- *   and check that header checksum matches actual one.
+ *   load ACPI table at @addr_ptr offset pointer into table descriptor
+ *   @sdt_table and check that signature/checksum matches actual one.
  */
-static void fetch_table(QTestState *qts, AcpiSdtTable *sdt_table, uint32_t 
addr)
+static void fetch_table(QTestState *qts, AcpiSdtTable *sdt_table,
+uint8_t *addr_ptr, const char *sig,
+bool verify_checksum)
 {
+uint32_t addr;
+
+memcpy(, addr_ptr , sizeof(addr));
+addr = le32_to_cpu(addr);
+
 qtest_memread(qts, addr + 4 /* Length of ACPI table */,
   _table->aml_len, 4);
 sdt_table->aml_len = le32_to_cpu(sdt_table->aml_len);
@@ -88,7 +92,12 @@ static void fetch_table(QTestState *qts, AcpiSdtTable 
*sdt_table, uint32_t addr)
 /* get whole table */
 qtest_memread(qts, addr, sdt_table->aml, sdt_table->aml_len);
 
-g_assert(!acpi_calc_checksum(sdt_table->aml, sdt_table->aml_len));
+if (sig) {
+ACPI_ASSERT_CMP(sdt_table->header->signature, sig);
+}
+if (verify_checksum) {
+g_assert(!acpi_calc_checksum(sdt_table->aml, sdt_table->aml_len));
+}
 }
 
 static void test_acpi_rsdp_address(test_data *data)
@@ -123,15 +132,13 @@ static void test_acpi_rsdp_table(test_data *data)
 
 static void test_acpi_rsdt_table(test_data *data)
 {
-uint32_t addr = acpi_get_rsdt_address(data->rsdp_table);
 const int entry_size = 4 /* 32-bit Entry size */;
 const int tables_off = 36 /* 1st Entry */;
 AcpiSdtTable rsdt = {};
 int i, table_len, table_nr;
-uint32_t *entry;
 
-fetch_table(data->qts, , addr);
-ACPI_ASSERT_CMP(rsdt.header->signature, "RSDT");
+fetch_table(data->qts, , >rsdp_table[16 /* RsdtAddress */],
+"RSDT", true);
 
 /* Load all tables and add to test list directly RSDT referenced tables */
 table_len = le32_to_cpu(rsdt.header->length);
@@ -139,9 +146,8 @@ static void test_acpi_rsdt_table(test_data *data)
 for (i = 0; i < table_nr; i++) {
 AcpiSdtTable ssdt_table = {};
 
-entry = (uint32_t *)(rsdt.aml + tables_off + i * entry_size);
-addr = le32_to_cpu(*entry);
-fetch_table(data->qts, _table, addr);
+fetch_table(data->qts, _table,
+rsdt.aml + tables_off + i * entry_size, NULL, true);
 
 /* Add table to ASL test tables list */
 g_array_append_val(data->tables, ssdt_table);
@@ -152,12 +158,18 @@ static void test_acpi_rsdt_table(test_data *data)
 static void test_acpi_fadt_table(test_data *data)
 {
 /* FADT table is 1st */
-AcpiSdtTable *fadt = _array_index(data->tables, typeof(*fadt), 0);
+AcpiSdtTable table = g_array_index(data->tables, typeof(table), 0);
+uint8_t *fadt_aml = table.aml;
 
-ACPI_ASSERT_CMP(fadt->header->signature, "FACP");
+ACPI_ASSERT_CMP(table.header->signature, "FACP");
 
-memcpy(>facs_addr, fadt->aml + 36 /* FIRMWARE_CTRL */, 4);
-memcpy(>dsdt_addr, fadt->aml + 40 /* DSDT */, 4);
+/* Since DSDT/FACS isn't in RSDT, add them to ASL test list manually */
+fetch_table(data->qts, , fadt_aml + 36 /* FIRMWARE_CTRL */,
+"FACS", false);
+g_array_append_val(data->tables, table);
+
+fetch_table(data->qts, , fadt_aml + 40 /* DSDT */, "DSDT", true);
+g_array_append_val(data->tables, table);
 }
 
 static void sanitize_fadt_ptrs(test_data *data)
@@ -189,34 +201,6 @@ static void sanitize_fadt_ptrs(test_data *data)
 }
 }
 
-static void 

[Qemu-devel] [PATCH v6 21/26] disas: nanoMIPS: Rename the decoder of 'gpr2.reg2' gpr encoding type

[Aleksandar Markovic]

From: Aleksandar Markovic 

Rename the decoder of 'gpr2.reg2' gpr encoding type in nanoMIPS
disassembler.

Signed-off-by: Aleksandar Markovic 
---
 disas/nanomips.cpp | 6 +++---
 disas/nanomips.h   | 2 +-
 2 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/disas/nanomips.cpp b/disas/nanomips.cpp
index 7a22ffe..05237e9 100644
--- a/disas/nanomips.cpp
+++ b/disas/nanomips.cpp
@@ -497,7 +497,7 @@ uint64 NMD::decode_gpr_gpr2_reg1(uint64 d)
 }
 
 
-uint64 NMD::encode_rd2_reg2(uint64 d)
+uint64 NMD::decode_gpr_gpr2_reg2(uint64 d)
 {
 static uint64 register_list[] = {  5,  6,  7,  8 };
 return renumber_registers(d, register_list,
@@ -10464,7 +10464,7 @@ std::string NMD::MOVEP(uint64 instruction)
 uint64 rsz4_value = extract_rsz4_4_2_1_0(instruction);
 
 std::string rd2 = GPR(decode_gpr_gpr2_reg1(rd2_value));
-std::string re2 = GPR(encode_rd2_reg2(rd2_value));
+std::string re2 = GPR(decode_gpr_gpr2_reg2(rd2_value));
 /* !! - no conversion function */
 std::string rsz4 = GPR(decode_gpr_gpr4_zero(rsz4_value));
 std::string rtz4 = GPR(decode_gpr_gpr4_zero(rtz4_value));
@@ -10493,7 +10493,7 @@ std::string NMD::MOVEP_REV_(uint64 instruction)
 std::string rs4 = GPR(decode_gpr_gpr4(rs4_value));
 std::string rt4 = GPR(decode_gpr_gpr4(rt4_value));
 std::string rd2 = GPR(decode_gpr_gpr2_reg1(rd2_value));
-std::string rs2 = GPR(encode_rd2_reg2(rd2_value));
+std::string rs2 = GPR(decode_gpr_gpr2_reg2(rd2_value));
 /* !! - no conversion function */
 
 return img::format("MOVEP %s, %s, %s, %s", rs4, rt4, rd2, rs2);
diff --git a/disas/nanomips.h b/disas/nanomips.h
index 4c31392..bbb4894 100644
--- a/disas/nanomips.h
+++ b/disas/nanomips.h
@@ -111,7 +111,7 @@ private:
 uint64 decode_gpr_gpr4_zero(uint64 d);
 uint64 decode_gpr_gpr4(uint64 d);
 uint64 decode_gpr_gpr2_reg1(uint64 d);
-uint64 encode_rd2_reg2(uint64 d);
+uint64 decode_gpr_gpr2_reg2(uint64 d);
 
 uint64 copy(uint64 d);
 int64 copy(int64 d);
-- 
2.7.4

[Qemu-devel] [PATCH v6 15/26] disas: nanoMIPS: Rename the decoder of 'gpr4' gpr encoding type

[Aleksandar Markovic]

From: Aleksandar Markovic 

Rename the decoder of 'gpr4' gpr encoding type in nanoMIPS
disassembler.

Signed-off-by: Aleksandar Markovic 
---
 disas/nanomips.cpp | 20 ++--
 disas/nanomips.h   |  2 +-
 2 files changed, 11 insertions(+), 11 deletions(-)

diff --git a/disas/nanomips.cpp b/disas/nanomips.cpp
index c04dd14..6ecdd62 100644
--- a/disas/nanomips.cpp
+++ b/disas/nanomips.cpp
@@ -405,7 +405,7 @@ uint64 NMD::encode_gpr4_zero(uint64 d)
 }
 
 
-uint64 NMD::encode_gpr4(uint64 d)
+uint64 NMD::decode_gpr_gpr4(uint64 d)
 {
 static uint64 register_list[] = {  8,  9, 10, 11,  4,  5,  6,  7,
   16, 17, 18, 19, 20, 21, 22, 23 };
@@ -2359,8 +2359,8 @@ std::string NMD::ADDU_4X4_(uint64 instruction)
 uint64 rt4_value = extract_rt4_9_7_6_5(instruction);
 uint64 rs4_value = extract_rs4_4_2_1_0(instruction);
 
-std::string rs4 = GPR(encode_gpr4(rs4_value));
-std::string rt4 = GPR(encode_gpr4(rt4_value));
+std::string rs4 = GPR(decode_gpr_gpr4(rs4_value));
+std::string rt4 = GPR(decode_gpr_gpr4(rt4_value));
 
 return img::format("ADDU %s, %s", rs4, rt4);
 }
@@ -9042,9 +9042,9 @@ std::string NMD::LW_4X4_(uint64 instruction)
 uint64 rs4_value = extract_rs4_4_2_1_0(instruction);
 uint64 u_value = extract_u_3_8__s2(instruction);
 
-std::string rt4 = GPR(encode_gpr4(rt4_value));
+std::string rt4 = GPR(decode_gpr_gpr4(rt4_value));
 std::string u = IMMEDIATE(copy(u_value));
-std::string rs4 = GPR(encode_gpr4(rs4_value));
+std::string rs4 = GPR(decode_gpr_gpr4(rs4_value));
 
 return img::format("LW %s, %s(%s)", rt4, u, rs4);
 }
@@ -10415,8 +10415,8 @@ std::string NMD::MOVEP_REV_(uint64 instruction)
 uint64 rd2_value = extract_rd2_3_8(instruction);
 uint64 rs4_value = extract_rs4_4_2_1_0(instruction);
 
-std::string rs4 = GPR(encode_gpr4(rs4_value));
-std::string rt4 = GPR(encode_gpr4(rt4_value));
+std::string rs4 = GPR(decode_gpr_gpr4(rs4_value));
+std::string rt4 = GPR(decode_gpr_gpr4(rt4_value));
 std::string rd2 = GPR(encode_rd2_reg1(rd2_value));
 std::string rs2 = GPR(encode_rd2_reg2(rd2_value));
 /* !! - no conversion function */
@@ -10981,8 +10981,8 @@ std::string NMD::MUL_4X4_(uint64 instruction)
 uint64 rt4_value = extract_rt4_9_7_6_5(instruction);
 uint64 rs4_value = extract_rs4_4_2_1_0(instruction);
 
-std::string rs4 = GPR(encode_gpr4(rs4_value));
-std::string rt4 = GPR(encode_gpr4(rt4_value));
+std::string rs4 = GPR(decode_gpr_gpr4(rs4_value));
+std::string rt4 = GPR(decode_gpr_gpr4(rt4_value));
 
 return img::format("MUL %s, %s", rs4, rt4);
 }
@@ -15260,7 +15260,7 @@ std::string NMD::SW_4X4_(uint64 instruction)
 
 std::string rtz4 = GPR(encode_gpr4_zero(rtz4_value));
 std::string u = IMMEDIATE(copy(u_value));
-std::string rs4 = GPR(encode_gpr4(rs4_value));
+std::string rs4 = GPR(decode_gpr_gpr4(rs4_value));
 
 return img::format("SW %s, %s(%s)", rtz4, u, rs4);
 }
diff --git a/disas/nanomips.h b/disas/nanomips.h
index bb66c5f..0734844 100644
--- a/disas/nanomips.h
+++ b/disas/nanomips.h
@@ -109,7 +109,7 @@ private:
 uint64 decode_gpr_gpr3_src_store(uint64 d);
 uint64 encode_rd1_from_rd(uint64 d);
 uint64 encode_gpr4_zero(uint64 d);
-uint64 encode_gpr4(uint64 d);
+uint64 decode_gpr_gpr4(uint64 d);
 uint64 encode_rd2_reg1(uint64 d);
 uint64 encode_rd2_reg2(uint64 d);
 
-- 
2.7.4

[Qemu-devel] [PATCH v2 8/8] tests: acpi: use AcpiSdtTable::aml instead of AcpiSdtTable::header::signature

[Igor Mammedov]

AcpiSdtTable::header::signature is the only remained field from
AcpiTableHeader structure used by tests. Instead of using packed
structure to access signature, just read it directly from table
blob and remove no longer used AcpiSdtTable::header / union and
keep only AcpiSdtTable::aml byte array.

Signed-off-by: Igor Mammedov 
---
 tests/acpi-utils.h   |  6 +-
 tests/bios-tables-test.c | 20 +---
 2 files changed, 10 insertions(+), 16 deletions(-)

diff --git a/tests/acpi-utils.h b/tests/acpi-utils.h
index cb7183e..ef388bb 100644
--- a/tests/acpi-utils.h
+++ b/tests/acpi-utils.h
@@ -13,15 +13,11 @@
 #ifndef TEST_ACPI_UTILS_H
 #define TEST_ACPI_UTILS_H
 
-#include "hw/acpi/acpi-defs.h"
 #include "libqtest.h"
 
 /* DSDT and SSDTs format */
 typedef struct {
-union {
-AcpiTableHeader *header;
-uint8_t *aml;/* aml bytecode from guest */
-};
+uint8_t *aml;/* aml bytecode from guest */
 uint32_t aml_len;
 gchar *aml_file;
 gchar *asl;/* asl code generated from aml */
diff --git a/tests/bios-tables-test.c b/tests/bios-tables-test.c
index 9139dec..0bf7164 100644
--- a/tests/bios-tables-test.c
+++ b/tests/bios-tables-test.c
@@ -44,6 +44,11 @@ static const char *iasl = stringify(CONFIG_IASL);
 static const char *iasl;
 #endif
 
+static bool compare_signature(const AcpiSdtTable *sdt, const char *signature)
+{
+   return !memcmp(sdt->aml, signature, 4);
+}
+
 static void cleanup_table_descriptor(AcpiSdtTable *table)
 {
 g_free(table->aml);
@@ -130,7 +135,7 @@ static void test_acpi_fadt_table(test_data *data)
 uint8_t *fadt_aml = table.aml;
 uint32_t fadt_len = table.aml_len;
 
-ACPI_ASSERT_CMP(table.header->signature, "FACP");
+g_assert(compare_signature(, "FACP"));
 
 /* Since DSDT/FACS isn't in RSDT, add them to ASL test list manually */
 acpi_fetch_table(data->qts, , _len,
@@ -169,7 +174,7 @@ static void dump_aml_files(test_data *data, bool rebuild)
 
 if (rebuild) {
 aml_file = g_strdup_printf("%s/%s/%.4s%s", data_dir, data->machine,
-   (gchar *)>header->signature, ext);
+   sdt->aml, ext);
 fd = g_open(aml_file, O_WRONLY|O_TRUNC|O_CREAT,
 S_IRUSR|S_IWUSR|S_IRGRP|S_IWGRP|S_IROTH);
 } else {
@@ -187,11 +192,6 @@ static void dump_aml_files(test_data *data, bool rebuild)
 }
 }
 
-static bool compare_signature(AcpiSdtTable *sdt, const char *signature)
-{
-   return !memcmp(>header->signature, signature, 4);
-}
-
 static bool load_asl(GArray *sdts, AcpiSdtTable *sdt)
 {
 AcpiSdtTable *temp;
@@ -290,7 +290,7 @@ static GArray *load_expected_aml(test_data *data)
 
 try_again:
 aml_file = g_strdup_printf("%s/%s/%.4s%s", data_dir, data->machine,
-   (gchar *)>header->signature, ext);
+   sdt->aml, ext);
 if (getenv("V")) {
 fprintf(stderr, "Looking for expected file '%s'\n", aml_file);
 }
@@ -350,14 +350,12 @@ static void test_acpi_asl(test_data *data)
 fprintf(stderr,
 "Warning! iasl couldn't parse the expected aml\n");
 } else {
-uint32_t signature = cpu_to_le32(exp_sdt->header->signature);
 sdt->tmp_files_retain = true;
 exp_sdt->tmp_files_retain = true;
 fprintf(stderr,
 "acpi-test: Warning! %.4s mismatch. "
 "Actual [asl:%s, aml:%s], Expected [asl:%s, 
aml:%s].\n",
-(gchar *),
-sdt->asl_file, sdt->aml_file,
+exp_sdt->aml, sdt->asl_file, sdt->aml_file,
 exp_sdt->asl_file, exp_sdt->aml_file);
 if (getenv("V")) {
 const char *diff_cmd = getenv("DIFF");
-- 
2.7.4

[Qemu-devel] [PATCH v6 26/26] disas: nanoMIPS: Add a note on documentation

[Aleksandar Markovic]

From: Aleksandar Markovic 

Add "nanoMIPS32 Instruction Set Technical Reference Manual" as
a reference.

Signed-off-by: Aleksandar Markovic 
---
 disas/nanomips.cpp | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/disas/nanomips.cpp b/disas/nanomips.cpp
index ea902f9..fa3beb6 100644
--- a/disas/nanomips.cpp
+++ b/disas/nanomips.cpp
@@ -20,6 +20,13 @@
  *
  */
 
+/*
+ *  Documentation used while implementing this component:
+ *
+ *  [1] "MIPS® Architecture Base: nanoMIPS32(tm) Instruction Set Technical
+ *  Reference Manual", Revision 01.01, April 27, 2018
+ */
+
 extern "C" {
 #include "qemu/osdep.h"
 #include "disas/bfd.h"
-- 
2.7.4

[Qemu-devel] [PATCH v6 13/26] disas: nanoMIPS: Rename the decoder of 'gpr3.src.store' gpr encoding type

[Aleksandar Markovic]

From: Aleksandar Markovic 

Rename the decoder of 'gpr3.src.store' gpr encoding type in nanoMIPS
disassembler.

Signed-off-by: Aleksandar Markovic 
---
 disas/nanomips.cpp | 10 +-
 disas/nanomips.h   |  2 +-
 2 files changed, 6 insertions(+), 6 deletions(-)

diff --git a/disas/nanomips.cpp b/disas/nanomips.cpp
index 8f354b2..bc95089 100644
--- a/disas/nanomips.cpp
+++ b/disas/nanomips.cpp
@@ -348,7 +348,7 @@ uint64 NMD::decode_gpr_gpr3(uint64 d)
 }
 
 
-uint64 NMD::encode_gpr3_store(uint64 d)
+uint64 NMD::decode_gpr_gpr3_src_store(uint64 d)
 {
 static uint64 register_list[] = {  0, 17, 18, 19,  4,  5,  6,  7 };
 return renumber_registers(d, register_list,
@@ -12782,7 +12782,7 @@ std::string NMD::SB_16_(uint64 instruction)
 uint64 rs3_value = extract_rs3_6_5_4(instruction);
 uint64 u_value = extract_u_1_0(instruction);
 
-std::string rtz3 = GPR(encode_gpr3_store(rtz3_value));
+std::string rtz3 = GPR(decode_gpr_gpr3_src_store(rtz3_value));
 std::string u = IMMEDIATE(copy(u_value));
 std::string rs3 = GPR(decode_gpr_gpr3(rs3_value));
 
@@ -13628,7 +13628,7 @@ std::string NMD::SH_16_(uint64 instruction)
 uint64 rs3_value = extract_rs3_6_5_4(instruction);
 uint64 u_value = extract_u_2_1__s1(instruction);
 
-std::string rtz3 = GPR(encode_gpr3_store(rtz3_value));
+std::string rtz3 = GPR(decode_gpr_gpr3_src_store(rtz3_value));
 std::string u = IMMEDIATE(copy(u_value));
 std::string rs3 = GPR(decode_gpr_gpr3(rs3_value));
 
@@ -15202,7 +15202,7 @@ std::string NMD::SW_16_(uint64 instruction)
 uint64 rs3_value = extract_rs3_6_5_4(instruction);
 uint64 u_value = extract_u_3_2_1_0__s2(instruction);
 
-std::string rtz3 = GPR(encode_gpr3_store(rtz3_value));
+std::string rtz3 = GPR(decode_gpr_gpr3_src_store(rtz3_value));
 std::string u = IMMEDIATE(copy(u_value));
 std::string rs3 = GPR(decode_gpr_gpr3(rs3_value));
 
@@ -15249,7 +15249,7 @@ std::string NMD::SW_GP16_(uint64 instruction)
 uint64 u_value = extract_u_6_5_4_3_2_1_0__s2(instruction);
 uint64 rtz3_value = extract_rtz3_9_8_7(instruction);
 
-std::string rtz3 = GPR(encode_gpr3_store(rtz3_value));
+std::string rtz3 = GPR(decode_gpr_gpr3_src_store(rtz3_value));
 std::string u = IMMEDIATE(copy(u_value));
 
 return img::format("SW %s, %s($%d)", rtz3, u, 28);
diff --git a/disas/nanomips.h b/disas/nanomips.h
index ec750cc..bb66c5f 100644
--- a/disas/nanomips.h
+++ b/disas/nanomips.h
@@ -106,7 +106,7 @@ private:
 uint64 renumber_registers(uint64 index, uint64 *register_list,
   size_t register_list_size);
 uint64 decode_gpr_gpr3(uint64 d);
-uint64 encode_gpr3_store(uint64 d);
+uint64 decode_gpr_gpr3_src_store(uint64 d);
 uint64 encode_rd1_from_rd(uint64 d);
 uint64 encode_gpr4_zero(uint64 d);
 uint64 encode_gpr4(uint64 d);
-- 
2.7.4

[Qemu-devel] [PATCH v6 23/26] disas: nanoMIPS: Rename the decoder of 'gpr1' gpr encoding type

[Aleksandar Markovic]

From: Aleksandar Markovic 

Rename the decoder of 'gpr1' gpr encoding type in nanoMIPS
disassembler.

Signed-off-by: Aleksandar Markovic 
---
 disas/nanomips.cpp | 4 ++--
 disas/nanomips.h   | 2 +-
 2 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/disas/nanomips.cpp b/disas/nanomips.cpp
index e52f8e3..ec223e8 100644
--- a/disas/nanomips.cpp
+++ b/disas/nanomips.cpp
@@ -388,7 +388,7 @@ uint64 NMD::decode_gpr_gpr3_src_store(uint64 d)
 }
 
 
-uint64 NMD::encode_rd1_from_rd(uint64 d)
+uint64 NMD::decode_gpr_gpr1(uint64 d)
 {
 static uint64 register_list[] = {  4,  5 };
 return renumber_registers(d, register_list,
@@ -10461,7 +10461,7 @@ std::string NMD::MOVE_BALC(uint64 instruction)
 uint64 rd1_value = extract_rdl_25_24(instruction);
 int64 s_value = extract_s__se21_0_20_to_1_s1(instruction);
 
-std::string rd1 = GPR(encode_rd1_from_rd(rd1_value));
+std::string rd1 = GPR(decode_gpr_gpr1(rd1_value));
 std::string rtz4 = GPR(decode_gpr_gpr4_zero(rtz4_value));
 std::string s = ADDRESS(encode_s_from_address(s_value), 4);
 
diff --git a/disas/nanomips.h b/disas/nanomips.h
index bbb4894..d7ccda4 100644
--- a/disas/nanomips.h
+++ b/disas/nanomips.h
@@ -107,7 +107,7 @@ private:
   size_t register_list_size);
 uint64 decode_gpr_gpr3(uint64 d);
 uint64 decode_gpr_gpr3_src_store(uint64 d);
-uint64 encode_rd1_from_rd(uint64 d);
+uint64 decode_gpr_gpr1(uint64 d);
 uint64 decode_gpr_gpr4_zero(uint64 d);
 uint64 decode_gpr_gpr4(uint64 d);
 uint64 decode_gpr_gpr2_reg1(uint64 d);
-- 
2.7.4

[Qemu-devel] [PATCH v6 22/26] disas: nanoMIPS: Comment the decoder of 'gpr2.reg2' gpr encoding type

[Aleksandar Markovic]

From: Aleksandar Markovic 

Comment the decoder of 'gpr2.reg2' gpr encoding type in nanoMIPS
disassembler.

Signed-off-by: Aleksandar Markovic 
---
 disas/nanomips.cpp | 22 ++
 1 file changed, 22 insertions(+)

diff --git a/disas/nanomips.cpp b/disas/nanomips.cpp
index 05237e9..e52f8e3 100644
--- a/disas/nanomips.cpp
+++ b/disas/nanomips.cpp
@@ -497,6 +497,28 @@ uint64 NMD::decode_gpr_gpr2_reg1(uint64 d)
 }
 
 
+/*
+ * NMD::decode_gpr_gpr2_reg2() - decoder for 'gpr2.reg2' gpr encoding type
+ *
+ *   Map a 2-bit code to the 5-bit register space according to this pattern:
+ *
+ *3 2 1 0
+ *| | | |
+ *| | | |
+ *| | | └-┐
+ *| | └-┐ |
+ *| └-┐ | |
+ *└-┐ | | |
+ *  | | | |
+ *  | | | |
+ *1 0 9 8 7 6 5 4 3 2 1 0 9 8 7 6 5 4 3 2 1 0 9 8 7 6 5 4 3 2 1 0
+ *  3   2   1   0
+ *
+ *   Used in handling following instructions:
+ *
+ * - MOVEP
+ * - MOVEP[REV]
+ */
 uint64 NMD::decode_gpr_gpr2_reg2(uint64 d)
 {
 static uint64 register_list[] = {  5,  6,  7,  8 };
-- 
2.7.4

[Qemu-devel] [PATCH v6 20/26] disas: nanoMIPS: Comment the decoder of 'gpr2.reg1' gpr encoding type

[Aleksandar Markovic]

From: Aleksandar Markovic 

Comment the decoder of 'gpr2.reg1' gpr encoding type in nanoMIPS
disassembler.

Signed-off-by: Aleksandar Markovic 
---
 disas/nanomips.cpp | 22 ++
 1 file changed, 22 insertions(+)

diff --git a/disas/nanomips.cpp b/disas/nanomips.cpp
index 80f50fc..7a22ffe 100644
--- a/disas/nanomips.cpp
+++ b/disas/nanomips.cpp
@@ -467,6 +467,28 @@ uint64 NMD::decode_gpr_gpr4(uint64 d)
 }
 
 
+/*
+ * NMD::decode_gpr_gpr2_reg1() - decoder for 'gpr2.reg1' gpr encoding type
+ *
+ *   Map a 2-bit code to the 5-bit register space according to this pattern:
+ *
+ *3 2 1 0
+ *| | | |
+ *| | | |
+ *| | | └---┐
+ *| | └---┐ |
+ *| └---┐ | |
+ *└---┐ | | |
+ *| | | |
+ *| | | |
+ *1 0 9 8 7 6 5 4 3 2 1 0 9 8 7 6 5 4 3 2 1 0 9 8 7 6 5 4 3 2 1 0
+ *  3   2   1   0
+ *
+ *   Used in handling following instructions:
+ *
+ * - MOVEP
+ * - MOVEP[REV]
+ */
 uint64 NMD::decode_gpr_gpr2_reg1(uint64 d)
 {
 static uint64 register_list[] = {  4,  5,  6,  7 };
-- 
2.7.4

[Qemu-devel] [PATCH v2 1/8] tests: acpi: use AcpiSdtTable::aml in consistent way

[Igor Mammedov]

Currently in the 1st case we store table body fetched from QEMU in
AcpiSdtTable::aml minus it's header but in the 2nd case when we
load reference aml from disk, it holds whole blob including header.
More over in the 1st case, we read header in separate AcpiSdtTable::header
structure and then jump over hoops to fixup tables and combine both.

Treat AcpiSdtTable::aml as whole table blob approach in both cases
and when fetching tables from QEMU, first get table length and then
fetch whole table into AcpiSdtTable::aml instead if doing it field
by field.

As result
 * AcpiSdtTable::aml is used in consistent manner
 * FADT fixups use offsets from spec instead of being shifted by
   header length
 * calculating checksums and dumping blobs becomes simpler

Signed-off-by: Igor Mammedov 
---
v2:
 * rebase: s/memread/qtest_memread/
 * drop explicit cast to uint8_t* as sdt->aml is uint8_t* now
 (Wainer dos Santos Moschetta )
 * drop not comment explaining starnge offsets as offsets are
   now follow APCI spec
---
 tests/acpi-utils.h   |  6 +++--
 tests/bios-tables-test.c | 64 ++--
 2 files changed, 28 insertions(+), 42 deletions(-)

diff --git a/tests/acpi-utils.h b/tests/acpi-utils.h
index c5b0e12..1b0e80d 100644
--- a/tests/acpi-utils.h
+++ b/tests/acpi-utils.h
@@ -18,8 +18,10 @@
 
 /* DSDT and SSDTs format */
 typedef struct {
-AcpiTableHeader header;
-gchar *aml;/* aml bytecode from guest */
+union {
+AcpiTableHeader *header;
+uint8_t *aml;/* aml bytecode from guest */
+};
 gsize aml_len;
 gchar *aml_file;
 gchar *asl;/* asl code generated from aml */
diff --git a/tests/bios-tables-test.c b/tests/bios-tables-test.c
index d455b2a..3f20bbd 100644
--- a/tests/bios-tables-test.c
+++ b/tests/bios-tables-test.c
@@ -163,29 +163,23 @@ static void sanitize_fadt_ptrs(test_data *data)
 for (i = 0; i < data->tables->len; i++) {
 AcpiSdtTable *sdt = _array_index(data->tables, AcpiSdtTable, i);
 
-if (memcmp(>header.signature, "FACP", 4)) {
+if (memcmp(>header->signature, "FACP", 4)) {
 continue;
 }
 
 /* check original FADT checksum before sanitizing table */
-g_assert(!(uint8_t)(
-acpi_calc_checksum((uint8_t *)sdt, sizeof(AcpiTableHeader)) +
-acpi_calc_checksum((uint8_t *)sdt->aml, sdt->aml_len)
-));
-
-/* sdt->aml field offset := spec offset - header size */
-memset(sdt->aml + 0, 0, 4); /* sanitize FIRMWARE_CTRL(36) ptr */
-memset(sdt->aml + 4, 0, 4); /* sanitize DSDT(40) ptr */
-if (sdt->header.revision >= 3) {
-memset(sdt->aml + 96, 0, 8); /* sanitize X_FIRMWARE_CTRL(132) ptr 
*/
-memset(sdt->aml + 104, 0, 8); /* sanitize X_DSDT(140) ptr */
+g_assert(!acpi_calc_checksum(sdt->aml, sdt->aml_len));
+
+memset(sdt->aml + 36, 0, 4); /* sanitize FIRMWARE_CTRL ptr */
+memset(sdt->aml + 40, 0, 4); /* sanitize DSDT ptr */
+if (sdt->header->revision >= 3) {
+memset(sdt->aml + 132, 0, 8); /* sanitize X_FIRMWARE_CTRL ptr */
+memset(sdt->aml + 140, 0, 8); /* sanitize X_DSDT ptr */
 }
 
 /* update checksum */
-sdt->header.checksum = 0;
-sdt->header.checksum -=
-acpi_calc_checksum((uint8_t *)sdt, sizeof(AcpiTableHeader)) +
-acpi_calc_checksum((uint8_t *)sdt->aml, sdt->aml_len);
+sdt->header->checksum = 0;
+sdt->header->checksum -= acpi_calc_checksum(sdt->aml, sdt->aml_len);
 break;
 }
 }
@@ -212,30 +206,23 @@ static void test_acpi_facs_table(test_data *data)
  */
 static void fetch_table(QTestState *qts, AcpiSdtTable *sdt_table, uint32_t 
addr)
 {
-uint8_t checksum;
-
-memset(sdt_table, 0, sizeof(*sdt_table));
-ACPI_READ_TABLE_HEADER(qts, _table->header, addr);
-
-sdt_table->aml_len = le32_to_cpu(sdt_table->header.length)
- - sizeof(AcpiTableHeader);
+qtest_memread(qts, addr + 4 /* Length of ACPI table */,
+  _table->aml_len, 4);
+sdt_table->aml_len = le32_to_cpu(sdt_table->aml_len);
 sdt_table->aml = g_malloc0(sdt_table->aml_len);
-ACPI_READ_ARRAY_PTR(qts, sdt_table->aml, sdt_table->aml_len, addr);
+/* get whole table */
+qtest_memread(qts, addr, sdt_table->aml, sdt_table->aml_len);
 
-checksum = acpi_calc_checksum((uint8_t *)sdt_table,
-  sizeof(AcpiTableHeader)) +
-   acpi_calc_checksum((uint8_t *)sdt_table->aml,
-  sdt_table->aml_len);
-g_assert(!checksum);
+g_assert(!acpi_calc_checksum(sdt_table->aml, sdt_table->aml_len));
 }
 
 static void test_acpi_dsdt_table(test_data *data)
 {
-AcpiSdtTable dsdt_table;
+AcpiSdtTable dsdt_table = {};
 uint32_t addr = le32_to_cpu(data->dsdt_addr);
 
 fetch_table(data->qts, _table, addr);
-

[Qemu-devel] [PATCH v6 14/26] disas: nanoMIPS: Comment the decoder of 'gpr3.src.store' gpr encoding type

[Aleksandar Markovic]

From: Aleksandar Markovic 

Comment the decoder of 'gpr3.src.store' gpr encoding type in nanoMIPS
disassembler.

Signed-off-by: Aleksandar Markovic 
---
 disas/nanomips.cpp | 32 
 1 file changed, 32 insertions(+)

diff --git a/disas/nanomips.cpp b/disas/nanomips.cpp
index bc95089..c04dd14 100644
--- a/disas/nanomips.cpp
+++ b/disas/nanomips.cpp
@@ -348,6 +348,38 @@ uint64 NMD::decode_gpr_gpr3(uint64 d)
 }
 
 
+/*
+ * NMD::decode_gpr_gpr3_src_store() - decoder for 'gpr3.src.store' gpr encoding
+ * type
+ *
+ *   Map a 3-bit code to the 5-bit register space according to this pattern:
+ *
+ *7 6 5 4 3 2 1 0
+ *| | | | | | | |
+ *| | | | | | | └---┐
+ *| | | └---┐   |
+ *| | └---┐ |   |
+ *| └---┐ | |   |
+ *└---┐ | | |   |
+ *| | |   | | | |   |
+ *┌---┘ | |   | | | |   |
+ *| ┌---┘ |   | | | |   |
+ *| | ┌---┘   | | | |   |
+ *| | |   | | | |   |
+ *| | |   | | | |   |
+ *1 0 9 8 7 6 5 4 3 2 1 0 9 8 7 6 5 4 3 2 1 0 9 8 7 6 5 4 3 2 1 0
+ *  3   2   1   0
+ *
+ *   This pattern is the same one used for 'gpr3' gpr encoding type, except for
+ * the input value 0, that is mapped to the output value 0 instead of 16.
+ *
+ *   Used in handling following instructions:
+ *
+ * - SB[16]
+ * - SH[16]
+ * - SW[16]
+ * - SW[GP16]
+ */
 uint64 NMD::decode_gpr_gpr3_src_store(uint64 d)
 {
 static uint64 register_list[] = {  0, 17, 18, 19,  4,  5,  6,  7 };
-- 
2.7.4

[Qemu-devel] [PATCH v6 19/26] disas: nanoMIPS: Rename the decoder of 'gpr2.reg1' gpr encoding type

[Aleksandar Markovic]

From: Aleksandar Markovic 

Rename the decoder of 'gpr2.reg1' gpr encoding type in nanoMIPS
disassembler.

Signed-off-by: Aleksandar Markovic 
---
 disas/nanomips.cpp | 6 +++---
 disas/nanomips.h   | 2 +-
 2 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/disas/nanomips.cpp b/disas/nanomips.cpp
index 6578aa3..80f50fc 100644
--- a/disas/nanomips.cpp
+++ b/disas/nanomips.cpp
@@ -467,7 +467,7 @@ uint64 NMD::decode_gpr_gpr4(uint64 d)
 }
 
 
-uint64 NMD::encode_rd2_reg1(uint64 d)
+uint64 NMD::decode_gpr_gpr2_reg1(uint64 d)
 {
 static uint64 register_list[] = {  4,  5,  6,  7 };
 return renumber_registers(d, register_list,
@@ -10441,7 +10441,7 @@ std::string NMD::MOVEP(uint64 instruction)
 uint64 rd2_value = extract_rd2_3_8(instruction);
 uint64 rsz4_value = extract_rsz4_4_2_1_0(instruction);
 
-std::string rd2 = GPR(encode_rd2_reg1(rd2_value));
+std::string rd2 = GPR(decode_gpr_gpr2_reg1(rd2_value));
 std::string re2 = GPR(encode_rd2_reg2(rd2_value));
 /* !! - no conversion function */
 std::string rsz4 = GPR(decode_gpr_gpr4_zero(rsz4_value));
@@ -10470,7 +10470,7 @@ std::string NMD::MOVEP_REV_(uint64 instruction)
 
 std::string rs4 = GPR(decode_gpr_gpr4(rs4_value));
 std::string rt4 = GPR(decode_gpr_gpr4(rt4_value));
-std::string rd2 = GPR(encode_rd2_reg1(rd2_value));
+std::string rd2 = GPR(decode_gpr_gpr2_reg1(rd2_value));
 std::string rs2 = GPR(encode_rd2_reg2(rd2_value));
 /* !! - no conversion function */
 
diff --git a/disas/nanomips.h b/disas/nanomips.h
index 917f33e..4c31392 100644
--- a/disas/nanomips.h
+++ b/disas/nanomips.h
@@ -110,7 +110,7 @@ private:
 uint64 encode_rd1_from_rd(uint64 d);
 uint64 decode_gpr_gpr4_zero(uint64 d);
 uint64 decode_gpr_gpr4(uint64 d);
-uint64 encode_rd2_reg1(uint64 d);
+uint64 decode_gpr_gpr2_reg1(uint64 d);
 uint64 encode_rd2_reg2(uint64 d);
 
 uint64 copy(uint64 d);
-- 
2.7.4

[Qemu-devel] [PATCH v2 3/8] tests: acpi: simplify rsdt handling

[Igor Mammedov]

RSDT referenced tables always have length at offset 4 and checksum at
offset 9, that's enough for reusing fetch_table() and replacing custom
RSDT fetching code with it.
While at it
 * merge fetch_rsdt_referenced_tables() into test_acpi_rsdt_table()
 * drop test_data::rsdt_table/rsdt_tables_addr/rsdt_tables_nr since
   we need this data only for duration of test_acpi_rsdt_table() to
   fetch other tables and use locals instead.

Signed-off-by: Igor Mammedov 
---
v2:
  - rebase: s/memread/qtest_memread/
---
 tests/bios-tables-test.c | 137 +++
 1 file changed, 55 insertions(+), 82 deletions(-)

diff --git a/tests/bios-tables-test.c b/tests/bios-tables-test.c
index b2a40bb..8082adc 100644
--- a/tests/bios-tables-test.c
+++ b/tests/bios-tables-test.c
@@ -28,12 +28,9 @@ typedef struct {
 const char *variant;
 uint32_t rsdp_addr;
 uint8_t rsdp_table[36 /* ACPI 2.0+ RSDP size */];
-AcpiRsdtDescriptorRev1 rsdt_table;
 uint32_t dsdt_addr;
 uint32_t facs_addr;
 AcpiFacsDescriptorRev1 facs_table;
-uint32_t *rsdt_tables_addr;
-int rsdt_tables_nr;
 GArray *tables;
 uint32_t smbios_ep_addr;
 struct smbios_21_entry_point smbios_ep_table;
@@ -50,33 +47,50 @@ static const char *iasl = stringify(CONFIG_IASL);
 static const char *iasl;
 #endif
 
+static void cleanup_table_descriptor(AcpiSdtTable *table)
+{
+g_free(table->aml);
+if (table->aml_file &&
+!table->tmp_files_retain &&
+g_strstr_len(table->aml_file, -1, "aml-")) {
+unlink(table->aml_file);
+}
+g_free(table->aml_file);
+g_free(table->asl);
+if (table->asl_file &&
+!table->tmp_files_retain) {
+unlink(table->asl_file);
+}
+g_free(table->asl_file);
+}
+
 static void free_test_data(test_data *data)
 {
-AcpiSdtTable *temp;
 int i;
 
-g_free(data->rsdt_tables_addr);
-
 for (i = 0; i < data->tables->len; ++i) {
-temp = _array_index(data->tables, AcpiSdtTable, i);
-g_free(temp->aml);
-if (temp->aml_file &&
-!temp->tmp_files_retain &&
-g_strstr_len(temp->aml_file, -1, "aml-")) {
-unlink(temp->aml_file);
-}
-g_free(temp->aml_file);
-g_free(temp->asl);
-if (temp->asl_file &&
-!temp->tmp_files_retain) {
-unlink(temp->asl_file);
-}
-g_free(temp->asl_file);
+cleanup_table_descriptor(_array_index(data->tables, AcpiSdtTable, 
i));
 }
 
 g_array_free(data->tables, true);
 }
 
+/** fetch_table
+ *   load ACPI table at @addr into table descriptor @sdt_table
+ *   and check that header checksum matches actual one.
+ */
+static void fetch_table(QTestState *qts, AcpiSdtTable *sdt_table, uint32_t 
addr)
+{
+qtest_memread(qts, addr + 4 /* Length of ACPI table */,
+  _table->aml_len, 4);
+sdt_table->aml_len = le32_to_cpu(sdt_table->aml_len);
+sdt_table->aml = g_malloc0(sdt_table->aml_len);
+/* get whole table */
+qtest_memread(qts, addr, sdt_table->aml, sdt_table->aml_len);
+
+g_assert(!acpi_calc_checksum(sdt_table->aml, sdt_table->aml_len));
+}
+
 static void test_acpi_rsdp_address(test_data *data)
 {
 uint32_t off = acpi_find_rsdp_address(data->qts);
@@ -109,36 +123,30 @@ static void test_acpi_rsdp_table(test_data *data)
 
 static void test_acpi_rsdt_table(test_data *data)
 {
-AcpiRsdtDescriptorRev1 *rsdt_table = >rsdt_table;
 uint32_t addr = acpi_get_rsdt_address(data->rsdp_table);
-uint32_t *tables;
-int tables_nr;
-uint8_t checksum;
-uint32_t rsdt_table_length;
-
-/* read the header */
-ACPI_READ_TABLE_HEADER(data->qts, rsdt_table, addr);
-ACPI_ASSERT_CMP(rsdt_table->signature, "RSDT");
-
-rsdt_table_length = le32_to_cpu(rsdt_table->length);
-
-/* compute the table entries in rsdt */
-tables_nr = (rsdt_table_length - sizeof(AcpiRsdtDescriptorRev1)) /
-sizeof(uint32_t);
-g_assert(tables_nr > 0);
-
-/* get the addresses of the tables pointed by rsdt */
-tables = g_new0(uint32_t, tables_nr);
-ACPI_READ_ARRAY_PTR(data->qts, tables, tables_nr, addr);
+const int entry_size = 4 /* 32-bit Entry size */;
+const int tables_off = 36 /* 1st Entry */;
+AcpiSdtTable rsdt = {};
+int i, table_len, table_nr;
+uint32_t *entry;
+
+fetch_table(data->qts, , addr);
+ACPI_ASSERT_CMP(rsdt.header->signature, "RSDT");
+
+/* Load all tables and add to test list directly RSDT referenced tables */
+table_len = le32_to_cpu(rsdt.header->length);
+table_nr = (table_len - tables_off) / entry_size;
+for (i = 0; i < table_nr; i++) {
+AcpiSdtTable ssdt_table = {};
 
-checksum = acpi_calc_checksum((uint8_t *)rsdt_table, rsdt_table_length) +
-   acpi_calc_checksum((uint8_t *)tables,
-  tables_nr * sizeof(uint32_t));
-g_assert(!checksum);
+entry = (uint32_t *)(rsdt.aml + 

[Qemu-devel] [PATCH v2 0/8] tests: apci: consolidate and cleanup ACPI test code

[Igor Mammedov]

Changes since v1:
  * rebase on top of current master due to a lots of conflicts with
'qtest global' removal being merged first
  * drop explicit cast to uint8_t* as sdt->aml is uint8_t* now
  * drop not comment explaining strange offsets as offsets are
now follow ACPI spec

While working on adding tests for virt/arm board (uefi/XSDT/64-bit table 
pointers),
I found it's rather difficult to deal with mixed ACPI testing code that we've
collected so far. So instead of just adding a pile of XSDT hacks on top, here
goes small refactoring series:
   * that removes dead code
   * replaces reading tables with a fetch per table everywhere instead of
 mix of field by field and whole table
   * consolidates the way tables are read (reduces code duplication)
   * test no longer depends on ACPI structures from QEMU (i.e. doesn't affected
 by mistakes there) 
   * fixes FACS not being compared against reference tables
Overall test is reduced on ~160LOC and hopefully it makes easier to follow and
add more stuff on top.

PS:
arm/virt test patches fill follow up a separate series on top of this one
for not to mix things up

Git tree for testing:
  https://github.com/imammedo/qemu acpi_tests_cleanup_v2

CC: "Michael S. Tsirkin" 
CC: Thomas Huth 
CC: Laurent Vivier 
CC: Samuel Ortiz 
CC: waine...@redhat.com


Igor Mammedov (8):
  tests: acpi: use AcpiSdtTable::aml in consistent way
  tests: acpi: make sure FADT is fetched only once
  tests: acpi: simplify rsdt handling
  tests: acpi: reuse fetch_table() for fetching FACS and DSDT
  tests: acpi: reuse fetch_table() in vmgenid-test
  tests: smbios: fetch whole table in one step instead of reading it
step by step
  tests: acpi: squash sanitize_fadt_ptrs() into test_acpi_fadt_table()
  tests: acpi: use AcpiSdtTable::aml instead of
AcpiSdtTable::header::signature

 tests/acpi-utils.h   |  44 ++--
 tests/acpi-utils.c   |  35 +--
 tests/bios-tables-test.c | 259 ---
 tests/vmgenid-test.c |  64 
 4 files changed, 121 insertions(+), 281 deletions(-)

-- 
2.7.4

[Qemu-devel] [PATCH v6 12/26] disas: nanoMIPS: Comment the decoder of 'gpr3' gpr encoding type

[Aleksandar Markovic]

From: Aleksandar Markovic 

Comment the decoder of 'gpr3' gpr encoding type in nanoMIPS
disassembler.

Signed-off-by: Aleksandar Markovic 
---
 disas/nanomips.cpp | 51 ---
 1 file changed, 48 insertions(+), 3 deletions(-)

diff --git a/disas/nanomips.cpp b/disas/nanomips.cpp
index bfa8c1a..8f354b2 100644
--- a/disas/nanomips.cpp
+++ b/disas/nanomips.cpp
@@ -291,9 +291,54 @@ uint64 NMD::renumber_registers(uint64 index, uint64 
*register_list,
 
 
 /*
- * these functions should be decode functions but the json does not have
- * decode sections so they are based on the encode, the equivalent decode
- * functions need writing eventually.
+ * NMD::decode_gpr_gpr3() - decoder for 'gpr3' gpr encoding type
+ *
+ *   Map a 3-bit code to the 5-bit register space according to this pattern:
+ *
+ *7 6 5 4 3 2 1 0
+ *| | | | | | | |
+ *| | | | | | | |
+ *| | | └---┐
+ *| | └---┐ |
+ *| └---┐ | |
+ *└---┐ | | |
+ *| | | | | | | |
+ *┌---┘ | | | | | | |
+ *| ┌---┘ | | | | | |
+ *| | ┌---┘ | | | | |
+ *| | | ┌---┘ | | | |
+ *| | | | | | | |
+ *1 0 9 8 7 6 5 4 3 2 1 0 9 8 7 6 5 4 3 2 1 0 9 8 7 6 5 4 3 2 1 0
+ *  3   2   1   0
+ *
+ *   Used in handling following instructions:
+ *
+ * - ADDIU[R1.SP]
+ * - ADDIU[R2]
+ * - ADDU[16]
+ * - AND[16]
+ * - ANDI[16]
+ * - BEQC[16]
+ * - BEQZC[16]
+ * - BNEC[16]
+ * - BNEZC[16]
+ * - LB[16]
+ * - LBU[16]
+ * - LH[16]
+ * - LHU[16]
+ * - LI[16]
+ * - LW[16]
+ * - LW[GP16]
+ * - LWXS[16]
+ * - NOT[16]
+ * - OR[16]
+ * - SB[16]
+ * - SH[16]
+ * - SLL[16]
+ * - SRL[16]
+ * - SUBU[16]
+ * - SW[16]
+ * - XOR[16]
  */
 uint64 NMD::decode_gpr_gpr3(uint64 d)
 {
-- 
2.7.4

[Qemu-devel] [PATCH v6 16/26] disas: nanoMIPS: Comment the decoder of 'gpr4' gpr encoding type

[Aleksandar Markovic]

From: Aleksandar Markovic 

Comment the decoder of 'gpr4' gpr encoding type in nanoMIPS
disassembler.

Signed-off-by: Aleksandar Markovic 
---
 disas/nanomips.cpp | 26 ++
 1 file changed, 26 insertions(+)

diff --git a/disas/nanomips.cpp b/disas/nanomips.cpp
index 6ecdd62..014ec06 100644
--- a/disas/nanomips.cpp
+++ b/disas/nanomips.cpp
@@ -405,6 +405,32 @@ uint64 NMD::encode_gpr4_zero(uint64 d)
 }
 
 
+/*
+ * NMD::decode_gpr_gpr4() - decoder for 'gpr4' gpr encoding type
+ *
+ *   Map a 4-bit code to the 5-bit register space according to this pattern:
+ *
+ *  1   0
+ *5 4 3 2 1 0 9 8 7 6 5 4 3 2 1 0
+ *| | | | | | | | | | | | | | | |
+ *| | | | | | | | | | | | | | | |
+ *| | | | | | | | | | | └---┐
+ *| | | | | | | | | | └---┐ |
+ *| | | | | | | | | └---┐ | |
+ *| | | | | | | | └---┐ | | |
+ *| | | | | | | | | | | | | | | |
+ *| | | | | | | | | | | | | | | |
+ *1 0 9 8 7 6 5 4 3 2 1 0 9 8 7 6 5 4 3 2 1 0 9 8 7 6 5 4 3 2 1 0
+ *  3   2   1   0
+ *
+ *   Used in handling following instructions:
+ *
+ * - ADDU[4X4]
+ * - LW[4X4]
+ * - MOVEP[REV]
+ * - MUL[4X4]
+ * - SW[4X4]
+ */
 uint64 NMD::decode_gpr_gpr4(uint64 d)
 {
 static uint64 register_list[] = {  8,  9, 10, 11,  4,  5,  6,  7,
-- 
2.7.4

[Qemu-devel] [PATCH v6 08/26] disas: nanoMIPS: Fix an FP-related misnomer 3

[Aleksandar Markovic]

From: Aleksandar Markovic 

Rename NMD::extract_ft_20_19_18_17_16(uint64 instruction) to
NMD::extract_ft_25_24_23_22_21(uint64 instruction).

Signed-off-by: Aleksandar Markovic 
---
 disas/nanomips.cpp | 258 ++---
 disas/nanomips.h   |   2 +-
 2 files changed, 130 insertions(+), 130 deletions(-)

diff --git a/disas/nanomips.cpp b/disas/nanomips.cpp
index 8f6db93..d354a67 100644
--- a/disas/nanomips.cpp
+++ b/disas/nanomips.cpp
@@ -1184,7 +1184,7 @@ uint64 NMD::extract_rt3_9_8_7(uint64 instruction)
 }
 
 
-uint64 NMD::extract_ft_20_19_18_17_16(uint64 instruction)
+uint64 NMD::extract_ft_25_24_23_22_21(uint64 instruction)
 {
 uint64 value = 0;
 value |= extract_bits(instruction, 21, 5);
@@ -1597,7 +1597,7 @@ bool NMD::SLTU_cond(uint64 instruction)
  */
 std::string NMD::ABS_D(uint64 instruction)
 {
-uint64 fd_value = extract_ft_20_19_18_17_16(instruction);
+uint64 fd_value = extract_ft_25_24_23_22_21(instruction);
 uint64 fs_value = extract_fs_20_19_18_17_16(instruction);
 
 std::string fs = FPR(copy(fs_value));
@@ -1619,7 +1619,7 @@ std::string NMD::ABS_D(uint64 instruction)
  */
 std::string NMD::ABS_S(uint64 instruction)
 {
-uint64 fd_value = extract_ft_20_19_18_17_16(instruction);
+uint64 fd_value = extract_ft_25_24_23_22_21(instruction);
 uint64 fs_value = extract_fs_20_19_18_17_16(instruction);
 
 std::string fs = FPR(copy(fs_value));
@@ -1751,7 +1751,7 @@ std::string NMD::ADD(uint64 instruction)
  */
 std::string NMD::ADD_D(uint64 instruction)
 {
-uint64 ft_value = extract_ft_20_19_18_17_16(instruction);
+uint64 ft_value = extract_ft_25_24_23_22_21(instruction);
 uint64 fs_value = extract_fs_20_19_18_17_16(instruction);
 uint64 fd_value = extract_fd_15_14_13_12_11(instruction);
 
@@ -1776,7 +1776,7 @@ std::string NMD::ADD_D(uint64 instruction)
  */
 std::string NMD::ADD_S(uint64 instruction)
 {
-uint64 ft_value = extract_ft_20_19_18_17_16(instruction);
+uint64 ft_value = extract_ft_25_24_23_22_21(instruction);
 uint64 fs_value = extract_fs_20_19_18_17_16(instruction);
 uint64 fd_value = extract_fd_15_14_13_12_11(instruction);
 
@@ -2783,7 +2783,7 @@ std::string NMD::BC_32_(uint64 instruction)
 std::string NMD::BC1EQZC(uint64 instruction)
 {
 int64 s_value = extr_sil0il14bs1_il1il1bs13Tmsb14(instruction);
-uint64 ft_value = extract_ft_20_19_18_17_16(instruction);
+uint64 ft_value = extract_ft_25_24_23_22_21(instruction);
 
 std::string ft = FPR(copy(ft_value));
 std::string s = ADDRESS(encode_s_from_address(s_value), 4);
@@ -2805,7 +2805,7 @@ std::string NMD::BC1EQZC(uint64 instruction)
 std::string NMD::BC1NEZC(uint64 instruction)
 {
 int64 s_value = extr_sil0il14bs1_il1il1bs13Tmsb14(instruction);
-uint64 ft_value = extract_ft_20_19_18_17_16(instruction);
+uint64 ft_value = extract_ft_25_24_23_22_21(instruction);
 
 std::string ft = FPR(copy(ft_value));
 std::string s = ADDRESS(encode_s_from_address(s_value), 4);
@@ -3378,7 +3378,7 @@ std::string NMD::CACHEE(uint64 instruction)
  */
 std::string NMD::CEIL_L_D(uint64 instruction)
 {
-uint64 ft_value = extract_ft_20_19_18_17_16(instruction);
+uint64 ft_value = extract_ft_25_24_23_22_21(instruction);
 uint64 fs_value = extract_fs_20_19_18_17_16(instruction);
 
 std::string ft = FPR(copy(ft_value));
@@ -3400,7 +3400,7 @@ std::string NMD::CEIL_L_D(uint64 instruction)
  */
 std::string NMD::CEIL_L_S(uint64 instruction)
 {
-uint64 ft_value = extract_ft_20_19_18_17_16(instruction);
+uint64 ft_value = extract_ft_25_24_23_22_21(instruction);
 uint64 fs_value = extract_fs_20_19_18_17_16(instruction);
 
 std::string ft = FPR(copy(ft_value));
@@ -3422,7 +3422,7 @@ std::string NMD::CEIL_L_S(uint64 instruction)
  */
 std::string NMD::CEIL_W_D(uint64 instruction)
 {
-uint64 ft_value = extract_ft_20_19_18_17_16(instruction);
+uint64 ft_value = extract_ft_25_24_23_22_21(instruction);
 uint64 fs_value = extract_fs_20_19_18_17_16(instruction);
 
 std::string ft = FPR(copy(ft_value));
@@ -3444,7 +3444,7 @@ std::string NMD::CEIL_W_D(uint64 instruction)
  */
 std::string NMD::CEIL_W_S(uint64 instruction)
 {
-uint64 ft_value = extract_ft_20_19_18_17_16(instruction);
+uint64 ft_value = extract_ft_25_24_23_22_21(instruction);
 uint64 fs_value = extract_fs_20_19_18_17_16(instruction);
 
 std::string ft = FPR(copy(ft_value));
@@ -3510,7 +3510,7 @@ std::string NMD::CFC2(uint64 instruction)
  */
 std::string NMD::CLASS_D(uint64 instruction)
 {
-uint64 ft_value = extract_ft_20_19_18_17_16(instruction);
+uint64 ft_value = extract_ft_25_24_23_22_21(instruction);
 uint64 fs_value = extract_fs_20_19_18_17_16(instruction);
 
 std::string ft = FPR(copy(ft_value));
@@ -3532,7 +3532,7 @@ std::string NMD::CLASS_D(uint64 instruction)
  */
 std::string NMD::CLASS_S(uint64 instruction)
 {
-uint64 ft_value = extract_ft_20_19_18_17_16(instruction);
+

[Qemu-devel] [PATCH v6 09/26] disas: nanoMIPS: Name more functions in a more descriptive way

[Aleksandar Markovic]

From: Aleksandar Markovic 

Rename more functions that have names that are hard to understand.

Signed-off-by: Aleksandar Markovic 
---
 disas/nanomips.cpp | 212 ++---
 disas/nanomips.h   |  28 +++
 2 files changed, 120 insertions(+), 120 deletions(-)

diff --git a/disas/nanomips.cpp b/disas/nanomips.cpp
index d354a67..372af90 100644
--- a/disas/nanomips.cpp
+++ b/disas/nanomips.cpp
@@ -715,7 +715,7 @@ uint64 NMD::extract_u_17_to_1__s1(uint64 instruction)
 }
 
 
-int64 NMD::extr_sil11il0bs10Tmsb9(uint64 instruction)
+int64 NMD::extract_s__se9_20_19_18_17_16_15_14_13_12_11(uint64 instruction)
 {
 int64 value = 0;
 value |= extract_bits(instruction, 11, 10);
@@ -724,7 +724,7 @@ int64 NMD::extr_sil11il0bs10Tmsb9(uint64 instruction)
 }
 
 
-int64 NMD::extr_sil0il11bs1_il1il1bs10Tmsb11(uint64 instruction)
+int64 NMD::extract_s__se11_0_10_9_8_7_6_5_4_3_2_1_0_s1(uint64 instruction)
 {
 int64 value = 0;
 value |= extract_bits(instruction, 0, 1) << 11;
@@ -791,7 +791,7 @@ uint64 NMD::extract_count3_14_13_12(uint64 instruction)
 }
 
 
-int64 NMD::extr_sil0il31bs1_il2il21bs10_il12il12bs9Tmsb31(uint64 instruction)
+int64 NMD::extract_s__se31_0_11_to_2_20_to_12_s12(uint64 instruction)
 {
 int64 value = 0;
 value |= extract_bits(instruction, 0, 1) << 31;
@@ -802,7 +802,7 @@ int64 
NMD::extr_sil0il31bs1_il2il21bs10_il12il12bs9Tmsb31(uint64 instruction)
 }
 
 
-int64 NMD::extr_sil0il7bs1_il1il1bs6Tmsb7(uint64 instruction)
+int64 NMD::extract_s__se7_0_6_5_4_3_2_1_s1(uint64 instruction)
 {
 int64 value = 0;
 value |= extract_bits(instruction, 0, 1) << 7;
@@ -876,7 +876,7 @@ uint64 NMD::extract_rdl_25_24(uint64 instruction)
 }
 
 
-int64 NMD::extr_sil0il10bs1_il1il1bs9Tmsb10(uint64 instruction)
+int64 NMD::extract_s__se10_0_9_8_7_6_5_4_3_2_1_s1(uint64 instruction)
 {
 int64 value = 0;
 value |= extract_bits(instruction, 0, 1) << 10;
@@ -1015,7 +1015,7 @@ uint64 NMD::extract_rsz4_4_2_1_0(uint64 instruction)
 }
 
 
-int64 NMD::extr_sil0il21bs1_il1il1bs20Tmsb21(uint64 instruction)
+int64 NMD::extract_s__se21_0_20_to_1_s1(uint64 instruction)
 {
 int64 value = 0;
 value |= extract_bits(instruction, 0, 1) << 21;
@@ -1058,7 +1058,7 @@ uint64 NMD::extract_rt_41_40_39_38_37(uint64 instruction)
 }
 
 
-int64 NMD::extract_shift_21_20_19_18_17_16(uint64 instruction)
+int64 NMD::extract_shift__se5_21_20_19_18_17_16(uint64 instruction)
 {
 int64 value = 0;
 value |= extract_bits(instruction, 16, 6);
@@ -1092,7 +1092,7 @@ uint64 NMD::extract_size_20_19_18_17_16(uint64 
instruction)
 }
 
 
-int64 NMD::extr_sil2il2bs6_il15il8bs1Tmsb8(uint64 instruction)
+int64 NMD::extract_s__se8_15_7_6_5_4_3_2_s2(uint64 instruction)
 {
 int64 value = 0;
 value |= extract_bits(instruction, 2, 6) << 2;
@@ -1118,7 +1118,7 @@ uint64 NMD::extract_fs_20_19_18_17_16(uint64 instruction)
 }
 
 
-int64 NMD::extr_sil0il0bs8_il15il8bs1Tmsb8(uint64 instruction)
+int64 NMD::extract_s__se8_15_7_6_5_4_3_2_1_0(uint64 instruction)
 {
 int64 value = 0;
 value |= extract_bits(instruction, 0, 8);
@@ -1241,7 +1241,7 @@ uint64 NMD::extract_sa_15_14_13(uint64 instruction)
 }
 
 
-int64 NMD::extr_sil0il14bs1_il1il1bs13Tmsb14(uint64 instruction)
+int64 NMD::extract_s__se14_0_13_to_1_s1(uint64 instruction)
 {
 int64 value = 0;
 value |= extract_bits(instruction, 0, 1) << 14;
@@ -1347,7 +1347,7 @@ uint64 NMD::extract_u_7_6_5_4__s4(uint64 instruction)
 }
 
 
-int64 NMD::extr_sil3il3bs5_il15il8bs1Tmsb8(uint64 instruction)
+int64 NMD::extract_s__se8_15_7_6_5_4_3_s3(uint64 instruction)
 {
 int64 value = 0;
 value |= extract_bits(instruction, 3, 5) << 3;
@@ -1365,7 +1365,7 @@ uint64 NMD::extract_ft_15_14_13_12_11(uint64 instruction)
 }
 
 
-int64 NMD::extr_sil0il16bs16_il16il0bs16Tmsb31(uint64 instruction)
+int64 NMD::extract_s__se31_15_to_0_31_to_16(uint64 instruction)
 {
 int64 value = 0;
 value |= extract_bits(instruction, 0, 16) << 16;
@@ -1415,7 +1415,7 @@ uint64 NMD::extract_code_1_0(uint64 instruction)
 }
 
 
-int64 NMD::extr_sil0il25bs1_il1il1bs24Tmsb25(uint64 instruction)
+int64 NMD::extract_s__se25_0_24_to_1_s1(uint64 instruction)
 {
 int64 value = 0;
 value |= extract_bits(instruction, 0, 1) << 25;
@@ -1491,7 +1491,7 @@ uint64 NMD::extract_u_20_to_2__s2(uint64 instruction)
 }
 
 
-int64 NMD::extract_s_4_2_1_0(uint64 instruction)
+int64 NMD::extract_s__se3_4_2_1_0(uint64 instruction)
 {
 int64 value = 0;
 value |= extract_bits(instruction, 0, 3);
@@ -1704,7 +1704,7 @@ std::string NMD::ABSQ_S_W(uint64 instruction)
 std::string NMD::ACLR(uint64 instruction)
 {
 uint64 bit_value = extract_bit_23_22_21(instruction);
-int64 s_value = extr_sil0il0bs8_il15il8bs1Tmsb8(instruction);
+int64 s_value = extract_s__se8_15_7_6_5_4_3_2_1_0(instruction);
 uint64 rs_value = extract_rs_20_19_18_17_16(instruction);
 
 std::string bit = IMMEDIATE(copy(bit_value));
@@ -1823,7 +1823,7 @@ std::string NMD::ADDIU_32_(uint64 

[Qemu-devel] [PATCH v2 2/8] tests: acpi: make sure FADT is fetched only once

[Igor Mammedov]

Whole FADT is fetched as part of RSDT referenced tables in
fetch_rsdt_referenced_tables() albeit a bit later than when FADT
is partially parsed in fadt_fetch_facs_and_dsdt_ptrs().
However there is no reason for calling fetch_rsdt_referenced_tables()
so late, just move it right after we fetched RSDT and before
fadt_fetch_facs_and_dsdt_ptrs(). That way we can reuse whole FADT
fetched by fetch_rsdt_referenced_tables() and avoid duplicate
custom fields fetching in fadt_fetch_facs_and_dsdt_ptrs().

While at it rename fadt_fetch_facs_and_dsdt_ptrs() to
test_acpi_fadt_table(). The follow up patch will merge
fadt_fetch_facs_and_dsdt_ptrs() into test_acpi_rsdt_table(),
so that we would end up calling only test_acpi_FOO_table()
for consistency for tables that require special processing.

Signed-off-by: Igor Mammedov 
---
 tests/bios-tables-test.c | 19 ---
 1 file changed, 8 insertions(+), 11 deletions(-)

diff --git a/tests/bios-tables-test.c b/tests/bios-tables-test.c
index 3f20bbd..b2a40bb 100644
--- a/tests/bios-tables-test.c
+++ b/tests/bios-tables-test.c
@@ -141,18 +141,15 @@ static void test_acpi_rsdt_table(test_data *data)
 data->rsdt_tables_nr = tables_nr;
 }
 
-static void fadt_fetch_facs_and_dsdt_ptrs(test_data *data)
+static void test_acpi_fadt_table(test_data *data)
 {
-uint32_t addr;
-AcpiTableHeader hdr;
+/* FADT table is 1st */
+AcpiSdtTable *fadt = _array_index(data->tables, typeof(*fadt), 0);
 
-/* FADT table comes first */
-addr = le32_to_cpu(data->rsdt_tables_addr[0]);
-ACPI_READ_TABLE_HEADER(data->qts, , addr);
-ACPI_ASSERT_CMP(hdr.signature, "FACP");
+ACPI_ASSERT_CMP(fadt->header->signature, "FACP");
 
-ACPI_READ_FIELD(data->qts, data->facs_addr, addr);
-ACPI_READ_FIELD(data->qts, data->dsdt_addr, addr);
+memcpy(>facs_addr, fadt->aml + 36 /* FIRMWARE_CTRL */, 4);
+memcpy(>dsdt_addr, fadt->aml + 40 /* DSDT */, 4);
 }
 
 static void sanitize_fadt_ptrs(test_data *data)
@@ -628,10 +625,10 @@ static void test_acpi_one(const char *params, test_data 
*data)
 test_acpi_rsdp_address(data);
 test_acpi_rsdp_table(data);
 test_acpi_rsdt_table(data);
-fadt_fetch_facs_and_dsdt_ptrs(data);
+fetch_rsdt_referenced_tables(data);
+test_acpi_fadt_table(data);
 test_acpi_facs_table(data);
 test_acpi_dsdt_table(data);
-fetch_rsdt_referenced_tables(data);
 
 sanitize_fadt_ptrs(data);
 
-- 
2.7.4

[Qemu-devel] [PATCH v6 07/26] disas: nanoMIPS: Fix an FP-related misnomer 2

[Aleksandar Markovic]

From: Aleksandar Markovic 

Rename NMD::extract_fs_15_14_13_12_11(uint64 instruction) to
NMD::extract_fs_20_19_18_17_16(uint64 instruction).

Signed-off-by: Aleksandar Markovic 
---
 disas/nanomips.cpp | 242 ++---
 disas/nanomips.h   |   2 +-
 2 files changed, 122 insertions(+), 122 deletions(-)

diff --git a/disas/nanomips.cpp b/disas/nanomips.cpp
index 9682725..8f6db93 100644
--- a/disas/nanomips.cpp
+++ b/disas/nanomips.cpp
@@ -1110,7 +1110,7 @@ uint64 NMD::extract_u_15_to_0(uint64 instruction)
 }
 
 
-uint64 NMD::extract_fs_15_14_13_12_11(uint64 instruction)
+uint64 NMD::extract_fs_20_19_18_17_16(uint64 instruction)
 {
 uint64 value = 0;
 value |= extract_bits(instruction, 16, 5);
@@ -1598,7 +1598,7 @@ bool NMD::SLTU_cond(uint64 instruction)
 std::string NMD::ABS_D(uint64 instruction)
 {
 uint64 fd_value = extract_ft_20_19_18_17_16(instruction);
-uint64 fs_value = extract_fs_15_14_13_12_11(instruction);
+uint64 fs_value = extract_fs_20_19_18_17_16(instruction);
 
 std::string fs = FPR(copy(fs_value));
 std::string fd = FPR(copy(fd_value));
@@ -1620,7 +1620,7 @@ std::string NMD::ABS_D(uint64 instruction)
 std::string NMD::ABS_S(uint64 instruction)
 {
 uint64 fd_value = extract_ft_20_19_18_17_16(instruction);
-uint64 fs_value = extract_fs_15_14_13_12_11(instruction);
+uint64 fs_value = extract_fs_20_19_18_17_16(instruction);
 
 std::string fs = FPR(copy(fs_value));
 std::string fd = FPR(copy(fd_value));
@@ -1752,7 +1752,7 @@ std::string NMD::ADD(uint64 instruction)
 std::string NMD::ADD_D(uint64 instruction)
 {
 uint64 ft_value = extract_ft_20_19_18_17_16(instruction);
-uint64 fs_value = extract_fs_15_14_13_12_11(instruction);
+uint64 fs_value = extract_fs_20_19_18_17_16(instruction);
 uint64 fd_value = extract_fd_15_14_13_12_11(instruction);
 
 std::string ft = FPR(copy(ft_value));
@@ -1777,7 +1777,7 @@ std::string NMD::ADD_D(uint64 instruction)
 std::string NMD::ADD_S(uint64 instruction)
 {
 uint64 ft_value = extract_ft_20_19_18_17_16(instruction);
-uint64 fs_value = extract_fs_15_14_13_12_11(instruction);
+uint64 fs_value = extract_fs_20_19_18_17_16(instruction);
 uint64 fd_value = extract_fd_15_14_13_12_11(instruction);
 
 std::string ft = FPR(copy(ft_value));
@@ -3379,7 +3379,7 @@ std::string NMD::CACHEE(uint64 instruction)
 std::string NMD::CEIL_L_D(uint64 instruction)
 {
 uint64 ft_value = extract_ft_20_19_18_17_16(instruction);
-uint64 fs_value = extract_fs_15_14_13_12_11(instruction);
+uint64 fs_value = extract_fs_20_19_18_17_16(instruction);
 
 std::string ft = FPR(copy(ft_value));
 std::string fs = FPR(copy(fs_value));
@@ -3401,7 +3401,7 @@ std::string NMD::CEIL_L_D(uint64 instruction)
 std::string NMD::CEIL_L_S(uint64 instruction)
 {
 uint64 ft_value = extract_ft_20_19_18_17_16(instruction);
-uint64 fs_value = extract_fs_15_14_13_12_11(instruction);
+uint64 fs_value = extract_fs_20_19_18_17_16(instruction);
 
 std::string ft = FPR(copy(ft_value));
 std::string fs = FPR(copy(fs_value));
@@ -3423,7 +3423,7 @@ std::string NMD::CEIL_L_S(uint64 instruction)
 std::string NMD::CEIL_W_D(uint64 instruction)
 {
 uint64 ft_value = extract_ft_20_19_18_17_16(instruction);
-uint64 fs_value = extract_fs_15_14_13_12_11(instruction);
+uint64 fs_value = extract_fs_20_19_18_17_16(instruction);
 
 std::string ft = FPR(copy(ft_value));
 std::string fs = FPR(copy(fs_value));
@@ -3445,7 +3445,7 @@ std::string NMD::CEIL_W_D(uint64 instruction)
 std::string NMD::CEIL_W_S(uint64 instruction)
 {
 uint64 ft_value = extract_ft_20_19_18_17_16(instruction);
-uint64 fs_value = extract_fs_15_14_13_12_11(instruction);
+uint64 fs_value = extract_fs_20_19_18_17_16(instruction);
 
 std::string ft = FPR(copy(ft_value));
 std::string fs = FPR(copy(fs_value));
@@ -3511,7 +3511,7 @@ std::string NMD::CFC2(uint64 instruction)
 std::string NMD::CLASS_D(uint64 instruction)
 {
 uint64 ft_value = extract_ft_20_19_18_17_16(instruction);
-uint64 fs_value = extract_fs_15_14_13_12_11(instruction);
+uint64 fs_value = extract_fs_20_19_18_17_16(instruction);
 
 std::string ft = FPR(copy(ft_value));
 std::string fs = FPR(copy(fs_value));
@@ -3533,7 +3533,7 @@ std::string NMD::CLASS_D(uint64 instruction)
 std::string NMD::CLASS_S(uint64 instruction)
 {
 uint64 ft_value = extract_ft_20_19_18_17_16(instruction);
-uint64 fs_value = extract_fs_15_14_13_12_11(instruction);
+uint64 fs_value = extract_fs_20_19_18_17_16(instruction);
 
 std::string ft = FPR(copy(ft_value));
 std::string fs = FPR(copy(fs_value));
@@ -3599,7 +3599,7 @@ std::string NMD::CLZ(uint64 instruction)
 std::string NMD::CMP_AF_D(uint64 instruction)
 {
 uint64 ft_value = extract_ft_20_19_18_17_16(instruction);
-uint64 fs_value = extract_fs_15_14_13_12_11(instruction);
+uint64 fs_value = 

[Qemu-devel] [PATCH v6 03/26] disas: nanoMIPS: Fix a function misnomer

[Aleksandar Markovic]

From: Aleksandar Markovic 

Fix wrong function name. The convention in these files is that names of
extraction functions should reflect bit patterns they are extracting.

Reviewed-by: Stefan Markovic 
Signed-off-by: Aleksandar Markovic 
---
 disas/nanomips.cpp | 264 ++---
 disas/nanomips.h   |   2 +-
 2 files changed, 133 insertions(+), 133 deletions(-)

diff --git a/disas/nanomips.cpp b/disas/nanomips.cpp
index 935c2de..cfad1ec 100644
--- a/disas/nanomips.cpp
+++ b/disas/nanomips.cpp
@@ -1391,7 +1391,7 @@ uint64 NMD::extr_uil2il2bs16Fmsb17(uint64 instruction)
 }
 
 
-uint64 NMD::extract_rd_20_19_18_17_16(uint64 instruction)
+uint64 NMD::extract_rd_15_14_13_12_11(uint64 instruction)
 {
 uint64 value = 0;
 value |= extract_bits(instruction, 11, 5);
@@ -1579,7 +1579,7 @@ bool NMD::PREFE_cond(uint64 instruction)
 
 bool NMD::SLTU_cond(uint64 instruction)
 {
-uint64 rd = extract_rd_20_19_18_17_16(instruction);
+uint64 rd = extract_rd_15_14_13_12_11(instruction);
 return rd != 0;
 }
 
@@ -1727,7 +1727,7 @@ std::string NMD::ACLR(uint64 instruction)
 std::string NMD::ADD(uint64 instruction)
 {
 uint64 rt_value = extract_rt_25_24_23_22_21(instruction);
-uint64 rd_value = extract_rd_20_19_18_17_16(instruction);
+uint64 rd_value = extract_rd_15_14_13_12_11(instruction);
 uint64 rs_value = extract_rs_20_19_18_17_16(instruction);
 
 std::string rd = GPR(copy(rd_value));
@@ -2039,7 +2039,7 @@ std::string NMD::ADDIUPC_48_(uint64 instruction)
 std::string NMD::ADDQ_PH(uint64 instruction)
 {
 uint64 rt_value = extract_rt_25_24_23_22_21(instruction);
-uint64 rd_value = extract_rd_20_19_18_17_16(instruction);
+uint64 rd_value = extract_rd_15_14_13_12_11(instruction);
 uint64 rs_value = extract_rs_20_19_18_17_16(instruction);
 
 std::string rd = GPR(copy(rd_value));
@@ -2063,7 +2063,7 @@ std::string NMD::ADDQ_PH(uint64 instruction)
 std::string NMD::ADDQ_S_PH(uint64 instruction)
 {
 uint64 rt_value = extract_rt_25_24_23_22_21(instruction);
-uint64 rd_value = extract_rd_20_19_18_17_16(instruction);
+uint64 rd_value = extract_rd_15_14_13_12_11(instruction);
 uint64 rs_value = extract_rs_20_19_18_17_16(instruction);
 
 std::string rd = GPR(copy(rd_value));
@@ -2087,7 +2087,7 @@ std::string NMD::ADDQ_S_PH(uint64 instruction)
 std::string NMD::ADDQ_S_W(uint64 instruction)
 {
 uint64 rt_value = extract_rt_25_24_23_22_21(instruction);
-uint64 rd_value = extract_rd_20_19_18_17_16(instruction);
+uint64 rd_value = extract_rd_15_14_13_12_11(instruction);
 uint64 rs_value = extract_rs_20_19_18_17_16(instruction);
 
 std::string rd = GPR(copy(rd_value));
@@ -2112,7 +2112,7 @@ std::string NMD::ADDQ_S_W(uint64 instruction)
 std::string NMD::ADDQH_PH(uint64 instruction)
 {
 uint64 rt_value = extract_rt_25_24_23_22_21(instruction);
-uint64 rd_value = extract_rd_20_19_18_17_16(instruction);
+uint64 rd_value = extract_rd_15_14_13_12_11(instruction);
 uint64 rs_value = extract_rs_20_19_18_17_16(instruction);
 
 std::string rd = GPR(copy(rd_value));
@@ -2137,7 +2137,7 @@ std::string NMD::ADDQH_PH(uint64 instruction)
 std::string NMD::ADDQH_R_PH(uint64 instruction)
 {
 uint64 rt_value = extract_rt_25_24_23_22_21(instruction);
-uint64 rd_value = extract_rd_20_19_18_17_16(instruction);
+uint64 rd_value = extract_rd_15_14_13_12_11(instruction);
 uint64 rs_value = extract_rs_20_19_18_17_16(instruction);
 
 std::string rd = GPR(copy(rd_value));
@@ -2161,7 +2161,7 @@ std::string NMD::ADDQH_R_PH(uint64 instruction)
 std::string NMD::ADDQH_R_W(uint64 instruction)
 {
 uint64 rt_value = extract_rt_25_24_23_22_21(instruction);
-uint64 rd_value = extract_rd_20_19_18_17_16(instruction);
+uint64 rd_value = extract_rd_15_14_13_12_11(instruction);
 uint64 rs_value = extract_rs_20_19_18_17_16(instruction);
 
 std::string rd = GPR(copy(rd_value));
@@ -2185,7 +2185,7 @@ std::string NMD::ADDQH_R_W(uint64 instruction)
 std::string NMD::ADDQH_W(uint64 instruction)
 {
 uint64 rt_value = extract_rt_25_24_23_22_21(instruction);
-uint64 rd_value = extract_rd_20_19_18_17_16(instruction);
+uint64 rd_value = extract_rd_15_14_13_12_11(instruction);
 uint64 rs_value = extract_rs_20_19_18_17_16(instruction);
 
 std::string rd = GPR(copy(rd_value));
@@ -2209,7 +2209,7 @@ std::string NMD::ADDQH_W(uint64 instruction)
 std::string NMD::ADDSC(uint64 instruction)
 {
 uint64 rt_value = extract_rt_25_24_23_22_21(instruction);
-uint64 rd_value = extract_rd_20_19_18_17_16(instruction);
+uint64 rd_value = extract_rd_15_14_13_12_11(instruction);
 uint64 rs_value = extract_rs_20_19_18_17_16(instruction);
 
 std::string rd = GPR(copy(rd_value));
@@ -2256,7 +2256,7 @@ std::string NMD::ADDU_16_(uint64 instruction)
 std::string NMD::ADDU_32_(uint64 instruction)
 {
 uint64 rt_value = extract_rt_25_24_23_22_21(instruction);
-uint64 rd_value = 

[Qemu-devel] [PATCH v6 06/26] disas: nanoMIPS: Fix an FP-related misnomer 1

[Aleksandar Markovic]

From: Aleksandar Markovic 

Rename NMD::extract_fd_10_9_8_7_6(uint64 instruction) to
NMD::extract_fd_15_14_13_12_11(uint64 instruction).

Signed-off-by: Aleksandar Markovic 
---
 disas/nanomips.cpp | 142 ++---
 disas/nanomips.h   |   2 +-
 2 files changed, 72 insertions(+), 72 deletions(-)

diff --git a/disas/nanomips.cpp b/disas/nanomips.cpp
index 477df84..9682725 100644
--- a/disas/nanomips.cpp
+++ b/disas/nanomips.cpp
@@ -1442,7 +1442,7 @@ uint64 NMD::extract_u_3_8__s2(uint64 instruction)
 }
 
 
-uint64 NMD::extract_fd_10_9_8_7_6(uint64 instruction)
+uint64 NMD::extract_fd_15_14_13_12_11(uint64 instruction)
 {
 uint64 value = 0;
 value |= extract_bits(instruction, 11, 5);
@@ -1753,7 +1753,7 @@ std::string NMD::ADD_D(uint64 instruction)
 {
 uint64 ft_value = extract_ft_20_19_18_17_16(instruction);
 uint64 fs_value = extract_fs_15_14_13_12_11(instruction);
-uint64 fd_value = extract_fd_10_9_8_7_6(instruction);
+uint64 fd_value = extract_fd_15_14_13_12_11(instruction);
 
 std::string ft = FPR(copy(ft_value));
 std::string fs = FPR(copy(fs_value));
@@ -1778,7 +1778,7 @@ std::string NMD::ADD_S(uint64 instruction)
 {
 uint64 ft_value = extract_ft_20_19_18_17_16(instruction);
 uint64 fs_value = extract_fs_15_14_13_12_11(instruction);
-uint64 fd_value = extract_fd_10_9_8_7_6(instruction);
+uint64 fd_value = extract_fd_15_14_13_12_11(instruction);
 
 std::string ft = FPR(copy(ft_value));
 std::string fs = FPR(copy(fs_value));
@@ -3600,7 +3600,7 @@ std::string NMD::CMP_AF_D(uint64 instruction)
 {
 uint64 ft_value = extract_ft_20_19_18_17_16(instruction);
 uint64 fs_value = extract_fs_15_14_13_12_11(instruction);
-uint64 fd_value = extract_fd_10_9_8_7_6(instruction);
+uint64 fd_value = extract_fd_15_14_13_12_11(instruction);
 
 std::string fd = FPR(copy(fd_value));
 std::string fs = FPR(copy(fs_value));
@@ -3624,7 +3624,7 @@ std::string NMD::CMP_AF_S(uint64 instruction)
 {
 uint64 ft_value = extract_ft_20_19_18_17_16(instruction);
 uint64 fs_value = extract_fs_15_14_13_12_11(instruction);
-uint64 fd_value = extract_fd_10_9_8_7_6(instruction);
+uint64 fd_value = extract_fd_15_14_13_12_11(instruction);
 
 std::string fd = FPR(copy(fd_value));
 std::string fs = FPR(copy(fs_value));
@@ -3648,7 +3648,7 @@ std::string NMD::CMP_EQ_D(uint64 instruction)
 {
 uint64 ft_value = extract_ft_20_19_18_17_16(instruction);
 uint64 fs_value = extract_fs_15_14_13_12_11(instruction);
-uint64 fd_value = extract_fd_10_9_8_7_6(instruction);
+uint64 fd_value = extract_fd_15_14_13_12_11(instruction);
 
 std::string fd = FPR(copy(fd_value));
 std::string fs = FPR(copy(fs_value));
@@ -3694,7 +3694,7 @@ std::string NMD::CMP_EQ_S(uint64 instruction)
 {
 uint64 ft_value = extract_ft_20_19_18_17_16(instruction);
 uint64 fs_value = extract_fs_15_14_13_12_11(instruction);
-uint64 fd_value = extract_fd_10_9_8_7_6(instruction);
+uint64 fd_value = extract_fd_15_14_13_12_11(instruction);
 
 std::string fd = FPR(copy(fd_value));
 std::string fs = FPR(copy(fs_value));
@@ -3718,7 +3718,7 @@ std::string NMD::CMP_LE_D(uint64 instruction)
 {
 uint64 ft_value = extract_ft_20_19_18_17_16(instruction);
 uint64 fs_value = extract_fs_15_14_13_12_11(instruction);
-uint64 fd_value = extract_fd_10_9_8_7_6(instruction);
+uint64 fd_value = extract_fd_15_14_13_12_11(instruction);
 
 std::string fd = FPR(copy(fd_value));
 std::string fs = FPR(copy(fs_value));
@@ -3764,7 +3764,7 @@ std::string NMD::CMP_LE_S(uint64 instruction)
 {
 uint64 ft_value = extract_ft_20_19_18_17_16(instruction);
 uint64 fs_value = extract_fs_15_14_13_12_11(instruction);
-uint64 fd_value = extract_fd_10_9_8_7_6(instruction);
+uint64 fd_value = extract_fd_15_14_13_12_11(instruction);
 
 std::string fd = FPR(copy(fd_value));
 std::string fs = FPR(copy(fs_value));
@@ -3788,7 +3788,7 @@ std::string NMD::CMP_LT_D(uint64 instruction)
 {
 uint64 ft_value = extract_ft_20_19_18_17_16(instruction);
 uint64 fs_value = extract_fs_15_14_13_12_11(instruction);
-uint64 fd_value = extract_fd_10_9_8_7_6(instruction);
+uint64 fd_value = extract_fd_15_14_13_12_11(instruction);
 
 std::string fd = FPR(copy(fd_value));
 std::string fs = FPR(copy(fs_value));
@@ -3834,7 +3834,7 @@ std::string NMD::CMP_LT_S(uint64 instruction)
 {
 uint64 ft_value = extract_ft_20_19_18_17_16(instruction);
 uint64 fs_value = extract_fs_15_14_13_12_11(instruction);
-uint64 fd_value = extract_fd_10_9_8_7_6(instruction);
+uint64 fd_value = extract_fd_15_14_13_12_11(instruction);
 
 std::string fd = FPR(copy(fd_value));
 std::string fs = FPR(copy(fs_value));
@@ -3858,7 +3858,7 @@ std::string NMD::CMP_NE_D(uint64 instruction)
 {
 uint64 ft_value = extract_ft_20_19_18_17_16(instruction);
 uint64 fs_value = 

[Qemu-devel] [PATCH v6 05/26] disas: nanoMIPS: Name some functions in a more descriptive way

[Aleksandar Markovic]

From: Aleksandar Markovic 

Rename some functions that have names that are hard to understand.

Reviewed-by: Stefan Markovic 
Signed-off-by: Aleksandar Markovic 
---
 disas/nanomips.cpp | 112 ++---
 disas/nanomips.h   |  32 +++
 2 files changed, 72 insertions(+), 72 deletions(-)

diff --git a/disas/nanomips.cpp b/disas/nanomips.cpp
index 9e87630..477df84 100644
--- a/disas/nanomips.cpp
+++ b/disas/nanomips.cpp
@@ -683,7 +683,7 @@ uint64 NMD::extract_shift3_2_1_0(uint64 instruction)
 }
 
 
-uint64 NMD::extr_uil3il3bs9Fmsb11(uint64 instruction)
+uint64 NMD::extract_u_11_10_9_8_7_6_5_4_3__s3(uint64 instruction)
 {
 uint64 value = 0;
 value |= extract_bits(instruction, 3, 9) << 3;
@@ -707,7 +707,7 @@ uint64 NMD::extract_rtz3_9_8_7(uint64 instruction)
 }
 
 
-uint64 NMD::extr_uil1il1bs17Fmsb17(uint64 instruction)
+uint64 NMD::extract_u_17_to_1__s1(uint64 instruction)
 {
 uint64 value = 0;
 value |= extract_bits(instruction, 1, 17) << 1;
@@ -767,7 +767,7 @@ uint64 NMD::extract_shift_4_3_2_1_0(uint64 instruction)
 }
 
 
-uint64 NMD::extr_shiftxil7il1bs4Fmsb4(uint64 instruction)
+uint64 NMD::extract_shiftx_10_9_8_7__s1(uint64 instruction)
 {
 uint64 value = 0;
 value |= extract_bits(instruction, 7, 4) << 1;
@@ -836,7 +836,7 @@ uint64 NMD::extract_rs_20_19_18_17_16(uint64 instruction)
 }
 
 
-uint64 NMD::extr_uil1il1bs2Fmsb2(uint64 instruction)
+uint64 NMD::extract_u_2_1__s1(uint64 instruction)
 {
 uint64 value = 0;
 value |= extract_bits(instruction, 1, 2) << 1;
@@ -934,7 +934,7 @@ uint64 NMD::extract_rs_4_3_2_1_0(uint64 instruction)
 }
 
 
-uint64 NMD::extr_uil3il3bs18Fmsb20(uint64 instruction)
+uint64 NMD::extract_u_20_to_3__s3(uint64 instruction)
 {
 uint64 value = 0;
 value |= extract_bits(instruction, 3, 18) << 3;
@@ -942,7 +942,7 @@ uint64 NMD::extr_uil3il3bs18Fmsb20(uint64 instruction)
 }
 
 
-uint64 NMD::extr_uil0il2bs4Fmsb5(uint64 instruction)
+uint64 NMD::extract_u_3_2_1_0__s2(uint64 instruction)
 {
 uint64 value = 0;
 value |= extract_bits(instruction, 0, 4) << 2;
@@ -958,7 +958,7 @@ uint64 NMD::extract_cofun_25_24_23(uint64 instruction)
 }
 
 
-uint64 NMD::extr_uil0il2bs3Fmsb4(uint64 instruction)
+uint64 NMD::extract_u_2_1_0__s2(uint64 instruction)
 {
 uint64 value = 0;
 value |= extract_bits(instruction, 0, 3) << 2;
@@ -1225,7 +1225,7 @@ uint64 NMD::extract_msbt_10_9_8_7_6(uint64 instruction)
 }
 
 
-uint64 NMD::extr_uil0il2bs6Fmsb7(uint64 instruction)
+uint64 NMD::extract_u_5_4_3_2_1_0__s2(uint64 instruction)
 {
 uint64 value = 0;
 value |= extract_bits(instruction, 0, 6) << 2;
@@ -1259,7 +1259,7 @@ uint64 NMD::extract_rs3_6_5_4(uint64 instruction)
 }
 
 
-uint64 NMD::extr_uil0il32bs32Fmsb63(uint64 instruction)
+uint64 NMD::extract_u_31_to_0__s32(uint64 instruction)
 {
 uint64 value = 0;
 value |= extract_bits(instruction, 0, 32) << 32;
@@ -1307,7 +1307,7 @@ uint64 NMD::extract_op_25_24_23_22_21(uint64 instruction)
 }
 
 
-uint64 NMD::extr_uil0il2bs7Fmsb8(uint64 instruction)
+uint64 NMD::extract_u_6_5_4_3_2_1_0__s2(uint64 instruction)
 {
 uint64 value = 0;
 value |= extract_bits(instruction, 0, 7) << 2;
@@ -1339,7 +1339,7 @@ uint64 NMD::extract_eu_3_2_1_0(uint64 instruction)
 }
 
 
-uint64 NMD::extr_uil4il4bs4Fmsb7(uint64 instruction)
+uint64 NMD::extract_u_7_6_5_4__s4(uint64 instruction)
 {
 uint64 value = 0;
 value |= extract_bits(instruction, 4, 4) << 4;
@@ -1383,7 +1383,7 @@ uint64 NMD::extract_u_20_19_18_17_16_15_14_13(uint64 
instruction)
 }
 
 
-uint64 NMD::extr_uil2il2bs16Fmsb17(uint64 instruction)
+uint64 NMD::extract_u_17_to_2__s2(uint64 instruction)
 {
 uint64 value = 0;
 value |= extract_bits(instruction, 2, 16) << 2;
@@ -1433,7 +1433,7 @@ uint64 NMD::extract_u_1_0(uint64 instruction)
 }
 
 
-uint64 NMD::extr_uil3il3bs1_il8il2bs1Fmsb3(uint64 instruction)
+uint64 NMD::extract_u_3_8__s2(uint64 instruction)
 {
 uint64 value = 0;
 value |= extract_bits(instruction, 3, 1) << 3;
@@ -1450,7 +1450,7 @@ uint64 NMD::extract_fd_10_9_8_7_6(uint64 instruction)
 }
 
 
-uint64 NMD::extr_uil0il2bs5Fmsb6(uint64 instruction)
+uint64 NMD::extract_u_4_3_2_1_0__s2(uint64 instruction)
 {
 uint64 value = 0;
 value |= extract_bits(instruction, 0, 5) << 2;
@@ -1483,7 +1483,7 @@ uint64 NMD::extract_ct_25_24_23_22_21(uint64 instruction)
 }
 
 
-uint64 NMD::extr_uil2il2bs19Fmsb20(uint64 instruction)
+uint64 NMD::extract_u_20_to_2__s2(uint64 instruction)
 {
 uint64 value = 0;
 value |= extract_bits(instruction, 2, 19) << 2;
@@ -1501,7 +1501,7 @@ int64 NMD::extract_s_4_2_1_0(uint64 instruction)
 }
 
 
-uint64 NMD::extr_uil0il1bs4Fmsb4(uint64 instruction)
+uint64 NMD::extract_u_3_2_1_0__s1(uint64 instruction)
 {
 uint64 value = 0;
 value |= extract_bits(instruction, 0, 4) << 1;
@@ -1535,7 +1535,7 @@ bool NMD::BEQC_16__cond(uint64 instruction)
 {
 uint64 rs3 = extract_rs3_6_5_4(instruction);
 uint64 rt3 = 

[Qemu-devel] [PATCH v6 11/26] disas: nanoMIPS: Rename the decoder of 'gpr3' gpr encoding type

[Aleksandar Markovic]

From: Aleksandar Markovic 

Rename the decoder of 'gpr3' gpr encoding type in nanoMIPS
disassembler.

Signed-off-by: Aleksandar Markovic 
---
 disas/nanomips.cpp | 96 +++---
 disas/nanomips.h   |  2 +-
 2 files changed, 49 insertions(+), 49 deletions(-)

diff --git a/disas/nanomips.cpp b/disas/nanomips.cpp
index 69e768b..bfa8c1a 100644
--- a/disas/nanomips.cpp
+++ b/disas/nanomips.cpp
@@ -295,7 +295,7 @@ uint64 NMD::renumber_registers(uint64 index, uint64 
*register_list,
  * decode sections so they are based on the encode, the equivalent decode
  * functions need writing eventually.
  */
-uint64 NMD::encode_gpr3(uint64 d)
+uint64 NMD::decode_gpr_gpr3(uint64 d)
 {
 static uint64 register_list[] = { 16, 17, 18, 19,  4,  5,  6,  7 };
 return renumber_registers(d, register_list,
@@ -380,14 +380,14 @@ int64 NMD::neg_copy(int64 d)
 /* strange wrapper around  gpr3 */
 uint64 NMD::encode_rs3_and_check_rs3_ge_rt3(uint64 d)
 {
-return encode_gpr3(d);
+return decode_gpr_gpr3(d);
 }
 
 
 /* strange wrapper around  gpr3 */
 uint64 NMD::encode_rs3_and_check_rs3_lt_rt3(uint64 d)
 {
-return encode_gpr3(d);
+return decode_gpr_gpr3(d);
 }
 
 
@@ -1932,7 +1932,7 @@ std::string NMD::ADDIU_R1_SP_(uint64 instruction)
 uint64 u_value = extract_u_5_4_3_2_1_0__s2(instruction);
 uint64 rt3_value = extract_rt3_9_8_7(instruction);
 
-std::string rt3 = GPR(encode_gpr3(rt3_value));
+std::string rt3 = GPR(decode_gpr_gpr3(rt3_value));
 std::string u = IMMEDIATE(copy(u_value));
 
 return img::format("ADDIU %s, $%d, %s", rt3, 29, u);
@@ -1954,8 +1954,8 @@ std::string NMD::ADDIU_R2_(uint64 instruction)
 uint64 rs3_value = extract_rs3_6_5_4(instruction);
 uint64 u_value = extract_u_2_1_0__s2(instruction);
 
-std::string rt3 = GPR(encode_gpr3(rt3_value));
-std::string rs3 = GPR(encode_gpr3(rs3_value));
+std::string rt3 = GPR(decode_gpr_gpr3(rt3_value));
+std::string rs3 = GPR(decode_gpr_gpr3(rs3_value));
 std::string u = IMMEDIATE(copy(u_value));
 
 return img::format("ADDIU %s, %s, %s", rt3, rs3, u);
@@ -2235,9 +2235,9 @@ std::string NMD::ADDU_16_(uint64 instruction)
 uint64 rs3_value = extract_rs3_6_5_4(instruction);
 uint64 rd3_value = extract_rd3_3_2_1(instruction);
 
-std::string rt3 = GPR(encode_gpr3(rt3_value));
-std::string rs3 = GPR(encode_gpr3(rs3_value));
-std::string rd3 = GPR(encode_gpr3(rd3_value));
+std::string rt3 = GPR(decode_gpr_gpr3(rt3_value));
+std::string rs3 = GPR(decode_gpr_gpr3(rs3_value));
+std::string rd3 = GPR(decode_gpr_gpr3(rd3_value));
 
 return img::format("ADDU %s, %s, %s", rd3, rs3, rt3);
 }
@@ -2494,8 +2494,8 @@ std::string NMD::AND_16_(uint64 instruction)
 uint64 rt3_value = extract_rt3_9_8_7(instruction);
 uint64 rs3_value = extract_rs3_6_5_4(instruction);
 
-std::string rt3 = GPR(encode_gpr3(rt3_value));
-std::string rs3 = GPR(encode_gpr3(rs3_value));
+std::string rt3 = GPR(decode_gpr_gpr3(rt3_value));
+std::string rs3 = GPR(decode_gpr_gpr3(rs3_value));
 
 return img::format("AND %s, %s", rs3, rt3);
 }
@@ -2540,8 +2540,8 @@ std::string NMD::ANDI_16_(uint64 instruction)
 uint64 rs3_value = extract_rs3_6_5_4(instruction);
 uint64 eu_value = extract_eu_3_2_1_0(instruction);
 
-std::string rt3 = GPR(encode_gpr3(rt3_value));
-std::string rs3 = GPR(encode_gpr3(rs3_value));
+std::string rt3 = GPR(decode_gpr_gpr3(rt3_value));
+std::string rs3 = GPR(decode_gpr_gpr3(rs3_value));
 std::string eu = IMMEDIATE(encode_eu_from_u_andi16(eu_value));
 
 return img::format("ANDI %s, %s, %s", rt3, rs3, eu);
@@ -2875,7 +2875,7 @@ std::string NMD::BEQC_16_(uint64 instruction)
 uint64 u_value = extract_u_3_2_1_0__s1(instruction);
 
 std::string rs3 = GPR(encode_rs3_and_check_rs3_lt_rt3(rs3_value));
-std::string rt3 = GPR(encode_gpr3(rt3_value));
+std::string rt3 = GPR(decode_gpr_gpr3(rt3_value));
 std::string u = ADDRESS(encode_u_from_address(u_value), 2);
 
 return img::format("BEQC %s, %s, %s", rs3, rt3, u);
@@ -2945,7 +2945,7 @@ std::string NMD::BEQZC_16_(uint64 instruction)
 uint64 rt3_value = extract_rt3_9_8_7(instruction);
 int64 s_value = extract_s__se7_0_6_5_4_3_2_1_s1(instruction);
 
-std::string rt3 = GPR(encode_gpr3(rt3_value));
+std::string rt3 = GPR(decode_gpr_gpr3(rt3_value));
 std::string s = ADDRESS(encode_s_from_address(s_value), 2);
 
 return img::format("BEQZC %s, %s", rt3, s);
@@ -3161,7 +3161,7 @@ std::string NMD::BNEC_16_(uint64 instruction)
 uint64 u_value = extract_u_3_2_1_0__s1(instruction);
 
 std::string rs3 = GPR(encode_rs3_and_check_rs3_ge_rt3(rs3_value));
-std::string rt3 = GPR(encode_gpr3(rt3_value));
+std::string rt3 = GPR(decode_gpr_gpr3(rt3_value));
 std::string u = ADDRESS(encode_u_from_address(u_value), 2);
 
 return img::format("BNEC %s, %s, %s", rs3, rt3, u);
@@ -3231,7 +3231,7 @@ std::string 

[Qemu-devel] [PATCH v6 00/26] disas: nanoMIPS: Clean up several issues

[Aleksandar Markovic]

From: Aleksandar Markovic 

Clean up several misc issues in nanoMIPS disassembler. There are
more issues to be cleaned, and this is meant to be just the first
phase. Complete cleanup should happen over the course of next
few months.

All these changes should not and do not affect any functionality.

v5->v6:

  - patches that deal with adding format specifiers [16] and [49]
removed, until we determine what is the most appropriate form,
and how to be more in sync with objdump output and inline
assembler allowed formats
  - added 14 patches on reformating grp decoders
  - added a patch that adds documentation as reference

v4->v5:

  - renamed patch "Fix comments for 48-bit instructions" to
  "Clean up handling of 48-bit instructions"
  - added patch "Clean up handling of 16-bit logic instructions"
  - added eight patches on improving gpr decoders
  - minor addition to patch "Fix order of more invocations"
  - minor cleanups of previous commit messages

v3->v4:

  - added patch "Name more functions in a more descriptive way"
  - added patch "Fix order of more invocations"
  - added patch "Fix comments for 48-bit instructions"
  - minor cleanups of previous commit messages

v2->v3:

  - added three patches that fix function misnomers.
  - minor changes in commit messages.

v1->v2:

  - patch 5 was somehow lost in v1, now should be fine.

Aleksandar Markovic (26):
  disas: nanoMIPS: Fix preamble text in nanomips.* files
  disas: nanoMIPS: Remove functions that are not used
  disas: nanoMIPS: Fix a function misnomer
  disas: nanoMIPS: Fix order of some invocations
  disas: nanoMIPS: Name some functions in a more descriptive way
  disas: nanoMIPS: Fix an FP-related misnomer 1
  disas: nanoMIPS: Fix an FP-related misnomer 2
  disas: nanoMIPS: Fix an FP-related misnomer 3
  disas: nanoMIPS: Name more functions in a more descriptive way
  disas: nanoMIPS: Fix order of more invocations
  disas: nanoMIPS: Rename the decoder of 'gpr3' gpr encoding type
  disas: nanoMIPS: Comment the decoder of 'gpr3' gpr encoding type
  disas: nanoMIPS: Rename the decoder of 'gpr3.src.store' gpr encoding
type
  disas: nanoMIPS: Comment the decoder of 'gpr3.src.store' gpr encoding
type
  disas: nanoMIPS: Rename the decoder of 'gpr4' gpr encoding type
  disas: nanoMIPS: Comment the decoder of 'gpr4' gpr encoding type
  disas: nanoMIPS: Rename the decoder of 'gpr4.zero' gpr encoding type
  disas: nanoMIPS: Comment the decoder of 'gpr4.zero' gpr encoding type
  disas: nanoMIPS: Rename the decoder of 'gpr2.reg1' gpr encoding type
  disas: nanoMIPS: Comment the decoder of 'gpr2.reg1' gpr encoding type
  disas: nanoMIPS: Rename the decoder of 'gpr2.reg2' gpr encoding type
  disas: nanoMIPS: Comment the decoder of 'gpr2.reg2' gpr encoding type
  disas: nanoMIPS: Rename the decoder of 'gpr1' gpr encoding type
  disas: nanoMIPS: Comment the decoder of 'gpr1' gpr encoding type
  disas: nanoMIPS: Reorder declarations and definitions of gpr decoders
  disas: nanoMIPS: Add a note on documentation

 disas/nanomips.cpp | 2135 ++--
 disas/nanomips.h   |  115 ++-
 2 files changed,  insertions(+), 1139 deletions(-)

-- 
2.7.4

[Qemu-devel] [PATCH v6 01/26] disas: nanoMIPS: Fix preamble text in nanomips.* files

[Aleksandar Markovic]

From: Aleksandar Markovic 

Fix several mistakes in preambles of nanomips disassembler source
files.

Reviewed-by: Stefan Markovic 
Signed-off-by: Aleksandar Markovic 
---
 disas/nanomips.cpp | 7 ---
 disas/nanomips.h   | 7 ---
 2 files changed, 8 insertions(+), 6 deletions(-)

diff --git a/disas/nanomips.cpp b/disas/nanomips.cpp
index 1238c2f..f9ef0a2 100644
--- a/disas/nanomips.cpp
+++ b/disas/nanomips.cpp
@@ -1,13 +1,13 @@
 /*
  *  Source file for nanoMIPS disassembler component of QEMU
  *
- *  Copyright (C) 2018  Wave Computing
+ *  Copyright (C) 2018  Wave Computing, Inc.
  *  Copyright (C) 2018  Matthew Fortune 
- *  Copyright (C) 2018  Aleksandar Markovic 
+ *  Copyright (C) 2018  Aleksandar Markovic 
  *
  *  This program is free software: you can redistribute it and/or modify
  *  it under the terms of the GNU General Public License as published by
- *  the Free Software Foundation, either version 3 of the License, or
+ *  the Free Software Foundation, either version 2 of the License, or
  *  (at your option) any later version.
  *
  *  This program is distributed in the hope that it will be useful,
@@ -17,6 +17,7 @@
  *
  *  You should have received a copy of the GNU General Public License
  *  along with this program.  If not, see .
+ *
  */
 
 extern "C" {
diff --git a/disas/nanomips.h b/disas/nanomips.h
index 84cc9a6..3df138d 100644
--- a/disas/nanomips.h
+++ b/disas/nanomips.h
@@ -1,13 +1,13 @@
 /*
  *  Header file for nanoMIPS disassembler component of QEMU
  *
- *  Copyright (C) 2018  Wave Computing
+ *  Copyright (C) 2018  Wave Computing, Inc.
  *  Copyright (C) 2018  Matthew Fortune 
- *  Copyright (C) 2018  Aleksandar Markovic 
+ *  Copyright (C) 2018  Aleksandar Markovic 
  *
  *  This program is free software: you can redistribute it and/or modify
  *  it under the terms of the GNU General Public License as published by
- *  the Free Software Foundation, either version 3 of the License, or
+ *  the Free Software Foundation, either version 2 of the License, or
  *  (at your option) any later version.
  *
  *  This program is distributed in the hope that it will be useful,
@@ -17,6 +17,7 @@
  *
  *  You should have received a copy of the GNU General Public License
  *  along with this program.  If not, see .
+ *
  */
 
 #ifndef NANOMIPS_DISASSEMBLER_H
-- 
2.7.4

[Qemu-devel] [PATCH v6 02/26] disas: nanoMIPS: Remove functions that are not used

[Aleksandar Markovic]

From: Aleksandar Markovic 

Some functions were not used at all. Compiler doesn't complain
since they are class memebers. Remove them - no future usage is
planned.

Reviewed-by: Stefan Markovic 
Signed-off-by: Aleksandar Markovic 
---
 disas/nanomips.cpp | 208 -
 disas/nanomips.h   |  25 ---
 2 files changed, 233 deletions(-)

diff --git a/disas/nanomips.cpp b/disas/nanomips.cpp
index f9ef0a2..935c2de 100644
--- a/disas/nanomips.cpp
+++ b/disas/nanomips.cpp
@@ -852,23 +852,6 @@ uint64 NMD::extract_stripe_6(uint64 instruction)
 }
 
 
-uint64 NMD::extr_xil17il0bs1Fmsb0(uint64 instruction)
-{
-uint64 value = 0;
-value |= extract_bits(instruction, 17, 1);
-return value;
-}
-
-
-uint64 NMD::extr_xil2il0bs1_il15il0bs1Fmsb0(uint64 instruction)
-{
-uint64 value = 0;
-value |= extract_bits(instruction, 2, 1);
-value |= extract_bits(instruction, 15, 1);
-return value;
-}
-
-
 uint64 NMD::extract_ac_13_12(uint64 instruction)
 {
 uint64 value = 0;
@@ -919,14 +902,6 @@ uint64 NMD::extract_shift_5_4_3_2_1_0(uint64 instruction)
 }
 
 
-uint64 NMD::extr_xil10il0bs6Fmsb5(uint64 instruction)
-{
-uint64 value = 0;
-value |= extract_bits(instruction, 10, 6);
-return value;
-}
-
-
 uint64 NMD::extract_count_19_18_17_16(uint64 instruction)
 {
 uint64 value = 0;
@@ -943,15 +918,6 @@ uint64 NMD::extract_code_2_1_0(uint64 instruction)
 }
 
 
-uint64 NMD::extr_xil10il0bs4_il22il0bs4Fmsb3(uint64 instruction)
-{
-uint64 value = 0;
-value |= extract_bits(instruction, 10, 4);
-value |= extract_bits(instruction, 22, 4);
-return value;
-}
-
-
 uint64 NMD::extract_u_11_10_9_8_7_6_5_4_3_2_1_0(uint64 instruction)
 {
 uint64 value = 0;
@@ -976,14 +942,6 @@ uint64 NMD::extr_uil3il3bs18Fmsb20(uint64 instruction)
 }
 
 
-uint64 NMD::extr_xil12il0bs1Fmsb0(uint64 instruction)
-{
-uint64 value = 0;
-value |= extract_bits(instruction, 12, 1);
-return value;
-}
-
-
 uint64 NMD::extr_uil0il2bs4Fmsb5(uint64 instruction)
 {
 uint64 value = 0;
@@ -1008,14 +966,6 @@ uint64 NMD::extr_uil0il2bs3Fmsb4(uint64 instruction)
 }
 
 
-uint64 NMD::extr_xil10il0bs1Fmsb0(uint64 instruction)
-{
-uint64 value = 0;
-value |= extract_bits(instruction, 10, 1);
-return value;
-}
-
-
 uint64 NMD::extract_rd3_3_2_1(uint64 instruction)
 {
 uint64 value = 0;
@@ -1048,22 +998,6 @@ uint64 NMD::extract_ru_7_6_5_4_3(uint64 instruction)
 }
 
 
-uint64 NMD::extr_xil21il0bs5Fmsb4(uint64 instruction)
-{
-uint64 value = 0;
-value |= extract_bits(instruction, 21, 5);
-return value;
-}
-
-
-uint64 NMD::extr_xil9il0bs3Fmsb2(uint64 instruction)
-{
-uint64 value = 0;
-value |= extract_bits(instruction, 9, 3);
-return value;
-}
-
-
 uint64 NMD::extract_u_17_to_0(uint64 instruction)
 {
 uint64 value = 0;
@@ -1072,15 +1006,6 @@ uint64 NMD::extract_u_17_to_0(uint64 instruction)
 }
 
 
-uint64 NMD::extr_xil14il0bs1_il15il0bs1Fmsb0(uint64 instruction)
-{
-uint64 value = 0;
-value |= extract_bits(instruction, 14, 1);
-value |= extract_bits(instruction, 15, 1);
-return value;
-}
-
-
 uint64 NMD::extract_rsz4_4_2_1_0(uint64 instruction)
 {
 uint64 value = 0;
@@ -1090,14 +1015,6 @@ uint64 NMD::extract_rsz4_4_2_1_0(uint64 instruction)
 }
 
 
-uint64 NMD::extr_xil24il0bs1Fmsb0(uint64 instruction)
-{
-uint64 value = 0;
-value |= extract_bits(instruction, 24, 1);
-return value;
-}
-
-
 int64 NMD::extr_sil0il21bs1_il1il1bs20Tmsb21(uint64 instruction)
 {
 int64 value = 0;
@@ -1150,15 +1067,6 @@ int64 NMD::extract_shift_21_20_19_18_17_16(uint64 
instruction)
 }
 
 
-uint64 NMD::extr_xil6il0bs3_il10il0bs1Fmsb2(uint64 instruction)
-{
-uint64 value = 0;
-value |= extract_bits(instruction, 6, 3);
-value |= extract_bits(instruction, 10, 1);
-return value;
-}
-
-
 uint64 NMD::extract_rd2_3_8(uint64 instruction)
 {
 uint64 value = 0;
@@ -1168,14 +1076,6 @@ uint64 NMD::extract_rd2_3_8(uint64 instruction)
 }
 
 
-uint64 NMD::extr_xil16il0bs5Fmsb4(uint64 instruction)
-{
-uint64 value = 0;
-value |= extract_bits(instruction, 16, 5);
-return value;
-}
-
-
 uint64 NMD::extract_code_17_to_0(uint64 instruction)
 {
 uint64 value = 0;
@@ -1184,14 +1084,6 @@ uint64 NMD::extract_code_17_to_0(uint64 instruction)
 }
 
 
-uint64 NMD::extr_xil0il0bs12Fmsb11(uint64 instruction)
-{
-uint64 value = 0;
-value |= extract_bits(instruction, 0, 12);
-return value;
-}
-
-
 uint64 NMD::extract_size_20_19_18_17_16(uint64 instruction)
 {
 uint64 value = 0;
@@ -1260,15 +1152,6 @@ uint64 NMD::extract_hs_20_19_18_17_16(uint64 instruction)
 }
 
 
-uint64 NMD::extr_xil10il0bs1_il14il0bs2Fmsb1(uint64 instruction)
-{
-uint64 value = 0;
-value |= extract_bits(instruction, 10, 1);
-value |= extract_bits(instruction, 14, 2);
-return value;
-}
-
-
 uint64 NMD::extract_sel_13_12_11(uint64 instruction)
 {
 uint64 value = 0;
@@ -1285,14 +1168,6 @@ uint64 

Re: [Qemu-devel] vfio failure with intel 760p 128GB nvme

[Alex Williamson]

On Thu, 27 Dec 2018 20:30:48 +0800
Dongli Zhang  wrote:

> Hi Alex,
> 
> On 12/02/2018 09:29 AM, Dongli Zhang wrote:
> > Hi Alex,
> > 
> > On 12/02/2018 03:29 AM, Alex Williamson wrote:  
> >> On Sat, 1 Dec 2018 10:52:21 -0800 (PST)
> >> Dongli Zhang  wrote:
> >>  
> >>> Hi,
> >>>
> >>> I obtained below error when assigning an intel 760p 128GB nvme to guest 
> >>> via
> >>> vfio on my desktop:
> >>>
> >>> qemu-system-x86_64: -device vfio-pci,host=:01:00.0: vfio 
> >>> :01:00.0: failed to add PCI capability 0x11[0x50]@0xb0: table & pba 
> >>> overlap, or they don't fit in BARs, or don't align
> >>>
> >>>
> >>> This is because the msix table is overlapping with pba. According to below
> >>> 'lspci -vv' from host, the distance between msix table offset and pba 
> >>> offset is
> >>> only 0x100, although there are 22 entries supported (22 entries need 
> >>> 0x160).
> >>> Looks qemu supports at most 0x800.
> >>>
> >>> # sudo lspci -vv
> >>> ... ...
> >>> 01:00.0 Non-Volatile memory controller: Intel Corporation Device f1a6 
> >>> (rev 03) (prog-if 02 [NVM Express])
> >>>   Subsystem: Intel Corporation Device 390b
> >>> ... ...
> >>>   Capabilities: [b0] MSI-X: Enable- Count=22 Masked-
> >>>   Vector table: BAR=0 offset=2000
> >>>   PBA: BAR=0 offset=2100
> >>>
> >>>
> >>>
> >>> A patch below could workaround the issue and passthrough nvme 
> >>> successfully.
> >>>
> >>> diff --git a/hw/vfio/pci.c b/hw/vfio/pci.c
> >>> index 5c7bd96..54fc25e 100644
> >>> --- a/hw/vfio/pci.c
> >>> +++ b/hw/vfio/pci.c
> >>> @@ -1510,6 +1510,11 @@ static void vfio_msix_early_setup(VFIOPCIDevice 
> >>> *vdev, Error **errp)
> >>>  msix->pba_offset = pba & ~PCI_MSIX_FLAGS_BIRMASK;
> >>>  msix->entries = (ctrl & PCI_MSIX_FLAGS_QSIZE) + 1;
> >>>  
> >>> +if (msix->table_bar == msix->pba_bar &&
> >>> +msix->table_offset + msix->entries * PCI_MSIX_ENTRY_SIZE > 
> >>> msix->pba_offset) {
> >>> +msix->entries = (msix->pba_offset - msix->table_offset) / 
> >>> PCI_MSIX_ENTRY_SIZE;
> >>> +}
> >>> +
> >>>  /*
> >>>   * Test the size of the pba_offset variable and catch if it extends 
> >>> outside
> >>>   * of the specified BAR. If it is the case, we need to apply a 
> >>> hardware
> >>>
> >>>
> >>> Would you please help confirm if this can be regarded as bug in qemu, or 
> >>> issue
> >>> with nvme hardware? Should we fix thin in qemu, or we should never use 
> >>> such buggy
> >>> hardware with vfio?  
> >>
> >> It's a hardware bug, is there perhaps a firmware update for the device
> >> that resolves it?  It's curious that a vector table size of 0x100 gives
> >> us 16 entries and 22 in hex is 0x16 (table size would be reported as
> >> 0x15 for the N-1 algorithm).  I wonder if there's a hex vs decimal
> >> mismatch going on.  We don't really know if the workaround above is
> >> correct, are there really 16 entries or maybe does the PBA actually
> >> start at a different offset?  We wouldn't want to generically assume
> >> one or the other.  I think we need Intel to tell us in which way their
> >> hardware is broken and whether it can or is already fixed in a firmware
> >> update.  Thanks,  
> > 
> > Thank you very much for the confirmation.
> > 
> > Just realized looks this would make trouble to my desktop as well when 17
> > vectors are used.
> > 
> > I will report to intel and confirm how this can happen and if there is any
> > firmware update available for this issue.
> >   
> 
> I found there is similar issue reported to kvm:
> 
> https://bugzilla.kernel.org/show_bug.cgi?id=202055
> 
> 
> I confirmed with my env again. By default, the msi-x count is 16.
> 
>   Capabilities: [b0] MSI-X: Enable+ Count=16 Masked-
>   Vector table: BAR=0 offset=2000
>   PBA: BAR=0 offset=2100
> 
> 
> The count is still 16 after the device is assigned to vfio (Enable- now):
> 
> # echo :01:00.0 > /sys/bus/pci/devices/\:01\:00.0/driver/unbind
> # echo "8086 f1a6" > /sys/bus/pci/drivers/vfio-pci/new_id
> 
> Capabilities: [b0] MSI-X: Enable- Count=16 Masked-
>   Vector table: BAR=0 offset=2000
>   PBA: BAR=0 offset=2100
> 
> 
> After I boot qemu with "-device vfio-pci,host=:01:00.0", count becomes 22.
> 
> Capabilities: [b0] MSI-X: Enable- Count=22 Masked-
>   Vector table: BAR=0 offset=2000
>   PBA: BAR=0 offset=2100
> 
> 
> 
> Another interesting observation is, vfio-based userspace nvme also changes 
> count
> from 16 to 22.
> 
> I reboot host and the count is reset to 16. Then I boot VM with "-drive
> file=nvme://:01:00.0/1,if=none,id=nvmedrive0 -device
> virtio-blk,drive=nvmedrive0,id=nvmevirtio0". As userspace nvme uses different
> vfio path, it boots successfully without issue.
> 
> However, the count becomes 22 then:
> 
> Capabilities: [b0] MSI-X: Enable- Count=22 Masked-
>   Vector table: BAR=0 offset=2000
>   PBA: BAR=0 

Re: [Qemu-devel] [PATCH v5 12/20] disas: nanoMIPS: Clean up handling of 16-bit logic instructions

[Aleksandar Rikalo]

> From: Aleksandar Markovic
> Sent: Thursday, December 27, 2018 2:18 PM
> To: Aleksandar Markovic; qemu-devel@nongnu.org; Aleksandar Rikalo
> Cc: aurel...@aurel32.net; Stefan Markovic
> Subject: Re: [PATCH v5 12/20] disas: nanoMIPS: Clean up handling of 16-bit 
> logic instructions
>
> > From: Aleksandar Markovic 
> > Subject: [PATCH v5 12/20] disas: nanoMIPS: Clean up handling of 16-bit 
> > logic instructions
>
> > Clean up handling of 16-bit logic nanoMIPS instructions:
>
> ...
> >
> > -return img::format("AND %s, %s", rs3, rt3);
> > +return img::format("AND[16] %s, %s", rs3, rt3);
> > }
>
> I wonder if this instruction should be displayed with two or three arguments 
> (by design of this instruction, the
> destination is the same register as one of sources, but would it be more 
> clear for end user to see three arguments,
> even if two of them are always the same?)

nanomips-linux-musl-objdump always shows three registers and generic mnemonic 
AND (without [16]).
On the other hand, inline assembler accepts syntax with two registers or/and 
instruction format specification.

We should decide whether we should follow objdump or assembler conventions.
In any case, the same rule should be applied consistently across this 
disassembler.

Thanks,
Aleksandar Rikalo

>
> Aleksandar
>

Re: [Qemu-devel] [PATCH v2 00/52] Audio 5.1 patches

[Kővágó Zoltán]

Hi,

I've pushed it to my github (modulo some random fixes not yet on the
mailing list):
https://github.com/DirtYiCE/qemu/tree/audio-51-2018

I don't have a mac so I have no idea whether it works or not.

Regards,
Zoltan

On 2018-12-26 12:24, Programmingkid wrote:
> 
>> On Dec 23, 2018, at 3:52 PM, qemu-devel-requ...@nongnu.org wrote:
>>
>> Message: 4
>> Date: Sun, 23 Dec 2018 21:51:36 +0100
>> From: "=?UTF-8?q?K=C5=91v=C3=A1g=C3=B3=2C=20Zolt=C3=A1n?="
>>  
>> To: qemu-devel@nongnu.org
>> Cc: Gerd Hoffmann 
>> Subject: [Qemu-devel] [PATCH v2 00/52] Audio 5.1 patches
>> Message-ID: 
>> Content-Type: text/plain; charset=UTF-8
>>
>> Hi,
>>
>> I've updated my audio patchset to the current git master. Other than that not
>> much happened since my last update [1], fixed a few small problems that I
>> noticed while rebasing my patches.
>>
>> Please review.
> 
> 
> 
> Hi I would like to run your patches. Do you have a repository that I may 
> clone? 
> 
> Also have you been able to test these patches using a Mac OS X guest yet? 
> 
> Thank you.
> 

Re: [Qemu-devel] [PATCH v5 12/20] disas: nanoMIPS: Clean up handling of 16-bit logic instructions

[Aleksandar Markovic]

> From: Aleksandar Markovic 
> Subject: [PATCH v5 12/20] disas: nanoMIPS: Clean up handling of 16-bit logic 
> instructions

> Clean up handling of 16-bit logic nanoMIPS instructions:

...
> 
> -return img::format("AND %s, %s", rs3, rt3);
> +return img::format("AND[16] %s, %s", rs3, rt3);
> }

I wonder if this instruction should be displayed with two or three arguments 
(by design of this instruction, the destination is the same register as one of 
sources, but would it be more clear for end user to see three arguments, even 
if two of them are always the same?)

Aleksandar

[Qemu-devel] [PATCH 2/2] tests: tcg: mips: Remove old directories after reorganization

[Aleksandar Markovic]

From: Aleksandar Markovic 

Remove old directories after reorganization of MIPS TCG tests.

Signed-off-by: Aleksandar Markovic 
---
 tests/tcg/mips/mips32-dsp/Makefile| 136 -
 tests/tcg/mips/mips32-dspr2/Makefile  |  71 ---
 tests/tcg/mips/mips64-dsp/Makefile| 306 --
 tests/tcg/mips/mips64-dsp/head.S  |  16 --
 tests/tcg/mips/mips64-dsp/io.h|  22 ---
 tests/tcg/mips/mips64-dsp/mips_boot.lds   |  31 ---
 tests/tcg/mips/mips64-dspr2/.directory|   2 -
 tests/tcg/mips/mips64-dspr2/Makefile  | 116 ---
 tests/tcg/mips/mips64-dspr2/head.S|  16 --
 tests/tcg/mips/mips64-dspr2/io.h  |  22 ---
 tests/tcg/mips/mips64-dspr2/mips_boot.lds |  31 ---
 tests/tcg/mips/mipsr5900/Makefile |  30 ---
 12 files changed, 799 deletions(-)
 delete mode 100644 tests/tcg/mips/mips32-dsp/Makefile
 delete mode 100644 tests/tcg/mips/mips32-dspr2/Makefile
 delete mode 100644 tests/tcg/mips/mips64-dsp/Makefile
 delete mode 100644 tests/tcg/mips/mips64-dsp/head.S
 delete mode 100644 tests/tcg/mips/mips64-dsp/io.h
 delete mode 100644 tests/tcg/mips/mips64-dsp/mips_boot.lds
 delete mode 100644 tests/tcg/mips/mips64-dspr2/.directory
 delete mode 100644 tests/tcg/mips/mips64-dspr2/Makefile
 delete mode 100644 tests/tcg/mips/mips64-dspr2/head.S
 delete mode 100644 tests/tcg/mips/mips64-dspr2/io.h
 delete mode 100644 tests/tcg/mips/mips64-dspr2/mips_boot.lds
 delete mode 100644 tests/tcg/mips/mipsr5900/Makefile

diff --git a/tests/tcg/mips/mips32-dsp/Makefile 
b/tests/tcg/mips/mips32-dsp/Makefile
deleted file mode 100644
index c3a0a00..000
--- a/tests/tcg/mips/mips32-dsp/Makefile
+++ /dev/null
@@ -1,136 +0,0 @@
--include ../../config-host.mak
-
-CROSS=mips64el-unknown-linux-gnu-
-
-SIM=qemu-mipsel
-SIM_FLAGS=-cpu 74Kf
-
-CC  = $(CROSS)gcc
-CFLAGS  = -mabi=32 -march=mips32r2 -mgp32 -mdsp -static
-
-TESTCASES = absq_s_ph.tst
-TESTCASES += absq_s_w.tst
-TESTCASES += addq_ph.tst
-TESTCASES += addq_s_ph.tst
-TESTCASES += addq_s_w.tst
-TESTCASES += addsc.tst
-TESTCASES += addu_qb.tst
-TESTCASES += addu_s_qb.tst
-TESTCASES += addwc.tst
-TESTCASES += bitrev.tst
-TESTCASES += bposge32.tst
-TESTCASES += cmp_eq_ph.tst
-TESTCASES += cmpgu_eq_qb.tst
-TESTCASES += cmpgu_le_qb.tst
-TESTCASES += cmpgu_lt_qb.tst
-TESTCASES += cmp_le_ph.tst
-TESTCASES += cmp_lt_ph.tst
-TESTCASES += cmpu_eq_qb.tst
-TESTCASES += cmpu_le_qb.tst
-TESTCASES += cmpu_lt_qb.tst
-TESTCASES += dpaq_sa_l_w.tst
-TESTCASES += dpaq_s_w_ph.tst
-TESTCASES += dpau_h_qbl.tst
-TESTCASES += dpau_h_qbr.tst
-TESTCASES += dpsq_sa_l_w.tst
-TESTCASES += dpsq_s_w_ph.tst
-TESTCASES += dpsu_h_qbl.tst
-TESTCASES += dpsu_h_qbr.tst
-TESTCASES += extp.tst
-TESTCASES += extpdp.tst
-TESTCASES += extpdpv.tst
-TESTCASES += extpv.tst
-TESTCASES += extr_rs_w.tst
-TESTCASES += extr_r_w.tst
-TESTCASES += extr_s_h.tst
-TESTCASES += extrv_rs_w.tst
-TESTCASES += extrv_r_w.tst
-TESTCASES += extrv_s_h.tst
-TESTCASES += extrv_w.tst
-TESTCASES += extr_w.tst
-TESTCASES += insv.tst
-TESTCASES += lbux.tst
-TESTCASES += lhx.tst
-TESTCASES += lwx.tst
-TESTCASES += madd.tst
-TESTCASES += maddu.tst
-TESTCASES += maq_sa_w_phl.tst
-TESTCASES += maq_sa_w_phr.tst
-TESTCASES += maq_s_w_phl.tst
-TESTCASES += maq_s_w_phr.tst
-TESTCASES += mfhi.tst
-TESTCASES += mflo.tst
-TESTCASES += modsub.tst
-TESTCASES += msub.tst
-TESTCASES += msubu.tst
-TESTCASES += mthi.tst
-TESTCASES += mthlip.tst
-TESTCASES += mtlo.tst
-TESTCASES += muleq_s_w_phl.tst
-TESTCASES += muleq_s_w_phr.tst
-TESTCASES += muleu_s_ph_qbl.tst
-TESTCASES += muleu_s_ph_qbr.tst
-TESTCASES += mulq_rs_ph.tst
-TESTCASES += mult.tst
-TESTCASES += multu.tst
-TESTCASES += packrl_ph.tst
-TESTCASES += pick_ph.tst
-TESTCASES += pick_qb.tst
-TESTCASES += precequ_ph_qbla.tst
-TESTCASES += precequ_ph_qbl.tst
-TESTCASES += precequ_ph_qbra.tst
-TESTCASES += precequ_ph_qbr.tst
-TESTCASES += preceq_w_phl.tst
-TESTCASES += preceq_w_phr.tst
-TESTCASES += preceu_ph_qbla.tst
-TESTCASES += preceu_ph_qbl.tst
-TESTCASES += preceu_ph_qbra.tst
-TESTCASES += preceu_ph_qbr.tst
-TESTCASES += precrq_ph_w.tst
-TESTCASES += precrq_qb_ph.tst
-TESTCASES += precrq_rs_ph_w.tst
-TESTCASES += precrqu_s_qb_ph.tst
-TESTCASES += raddu_w_qb.tst
-TESTCASES += rddsp.tst
-TESTCASES += repl_ph.tst
-TESTCASES += repl_qb.tst
-TESTCASES += replv_ph.tst
-TESTCASES += replv_qb.tst
-TESTCASES += shilo.tst
-TESTCASES += shilov.tst
-TESTCASES += shll_ph.tst
-TESTCASES += shll_qb.tst
-TESTCASES += shll_s_ph.tst
-TESTCASES += shll_s_w.tst
-TESTCASES += shllv_ph.tst
-TESTCASES += shllv_qb.tst
-TESTCASES += shllv_s_ph.tst
-TESTCASES += shllv_s_w.tst
-TESTCASES += shra_ph.tst
-TESTCASES += shra_r_ph.tst
-TESTCASES += shra_r_w.tst
-TESTCASES += shrav_ph.tst
-TESTCASES += shrav_r_ph.tst
-TESTCASES += shrav_r_w.tst
-TESTCASES += shrl_qb.tst
-TESTCASES += shrlv_qb.tst
-TESTCASES += subq_ph.tst
-TESTCASES += subq_s_ph.tst
-TESTCASES += subq_s_w.tst
-TESTCASES += subu_qb.tst
-TESTCASES += subu_s_qb.tst

[Qemu-devel] [PATCH 0/2] tests: Reorganize MIPS TCG directories and files

[Aleksandar Markovic]

From: Aleksandar Markovic 

Reorganize MIPS TCG directories and files. The file movement is done
using "git mv" command, so "git blame" will still display the original
information, regardles of the new names and locations of involved
files.

Aleksandar Markovic (2):
  tests: tcg: mips: Move source files to new location
  tests: tcg: mips: Remove old directories after reorganization

 tests/tcg/mips/mips32-dsp/Makefile | 136 -
 tests/tcg/mips/mips32-dsp/absq_s_ph.c  |  31 ---
 tests/tcg/mips/mips32-dsp/absq_s_w.c   |  37 ---
 tests/tcg/mips/mips32-dsp/addq_ph.c|  46 
 tests/tcg/mips/mips32-dsp/addq_s_ph.c  |  69 -
 tests/tcg/mips/mips32-dsp/addq_s_w.c   |  44 ---
 tests/tcg/mips/mips32-dsp/addsc.c  |  33 ---
 tests/tcg/mips/mips32-dsp/addu_qb.c|  35 ---
 tests/tcg/mips/mips32-dsp/addu_s_qb.c  |  35 ---
 tests/tcg/mips/mips32-dsp/addwc.c  |  49 
 tests/tcg/mips/mips32-dsp/bitrev.c |  20 --
 tests/tcg/mips/mips32-dsp/bposge32.c   |  44 ---
 tests/tcg/mips/mips32-dsp/cmp_eq_ph.c  |  35 ---
 tests/tcg/mips/mips32-dsp/cmp_le_ph.c  |  35 ---
 tests/tcg/mips/mips32-dsp/cmp_lt_ph.c  |  35 ---
 tests/tcg/mips/mips32-dsp/cmpgu_eq_qb.c|  31 ---
 tests/tcg/mips/mips32-dsp/cmpgu_le_qb.c|  31 ---
 tests/tcg/mips/mips32-dsp/cmpgu_lt_qb.c|  31 ---
 tests/tcg/mips/mips32-dsp/cmpu_eq_qb.c |  35 ---
 tests/tcg/mips/mips32-dsp/cmpu_le_qb.c |  35 ---
 tests/tcg/mips/mips32-dsp/cmpu_lt_qb.c |  35 ---
 tests/tcg/mips/mips32-dsp/dpaq_s_w_ph.c|  31 ---
 tests/tcg/mips/mips32-dsp/dpaq_sa_l_w.c| 125 -
 tests/tcg/mips/mips32-dsp/dpau_h_qbl.c |  27 --
 tests/tcg/mips/mips32-dsp/dpau_h_qbr.c |  27 --
 tests/tcg/mips/mips32-dsp/dpsq_s_w_ph.c|  45 ---
 tests/tcg/mips/mips32-dsp/dpsq_sa_l_w.c|  55 
 tests/tcg/mips/mips32-dsp/dpsu_h_qbl.c |  27 --
 tests/tcg/mips/mips32-dsp/dpsu_h_qbr.c |  27 --
 tests/tcg/mips/mips32-dsp/extp.c   |  62 -
 tests/tcg/mips/mips32-dsp/extpdp.c |  64 -
 tests/tcg/mips/mips32-dsp/extpdpv.c|  47 
 tests/tcg/mips/mips32-dsp/extpv.c  |  45 ---
 tests/tcg/mips/mips32-dsp/extr_r_w.c   |  94 ---
 tests/tcg/mips/mips32-dsp/extr_rs_w.c  | 117 
 tests/tcg/mips/mips32-dsp/extr_s_h.c   |  86 --
 tests/tcg/mips/mips32-dsp/extr_w.c |  94 ---
 tests/tcg/mips/mips32-dsp/extrv_r_w.c  |  79 --
 tests/tcg/mips/mips32-dsp/extrv_rs_w.c |  77 --
 tests/tcg/mips/mips32-dsp/extrv_s_h.c  |  88 --
 tests/tcg/mips/mips32-dsp/extrv_w.c|  80 --
 tests/tcg/mips/mips32-dsp/insv.c   |  36 ---
 tests/tcg/mips/mips32-dsp/lbux.c   |  25 --
 tests/tcg/mips/mips32-dsp/lhx.c|  25 --
 tests/tcg/mips/mips32-dsp/lwx.c|  25 --
 tests/tcg/mips/mips32-dsp/madd.c   |  31 ---
 tests/tcg/mips/mips32-dsp/maddu.c  |  31 ---
 tests/tcg/mips/mips32-dsp/main.c   |   6 -
 tests/tcg/mips/mips32-dsp/maq_s_w_phl.c|  55 
 tests/tcg/mips/mips32-dsp/maq_s_w_phr.c|  55 
 tests/tcg/mips/mips32-dsp/maq_sa_w_phl.c   |  55 
 tests/tcg/mips/mips32-dsp/maq_sa_w_phr.c   |  55 
 tests/tcg/mips/mips32-dsp/mfhi.c   |  21 --
 tests/tcg/mips/mips32-dsp/mflo.c   |  21 --
 tests/tcg/mips/mips32-dsp/modsub.c |  30 --
 tests/tcg/mips/mips32-dsp/msub.c   |  30 --
 tests/tcg/mips/mips32-dsp/msubu.c  |  30 --
 tests/tcg/mips/mips32-dsp/mthi.c   |  21 --
 tests/tcg/mips/mips32-dsp/mthlip.c |  58 
 tests/tcg/mips/mips32-dsp/mtlo.c   |  21 --
 tests/tcg/mips/mips32-dsp/muleq_s_w_phl.c  |  41 ---
 tests/tcg/mips/mips32-dsp/muleq_s_w_phr.c  |  40 ---
 tests/tcg/mips/mips32-dsp/muleu_s_ph_qbl.c |  25 --
 tests/tcg/mips/mips32-dsp/muleu_s_ph_qbr.c |  25 --
 tests/tcg/mips/mips32-dsp/mulq_rs_ph.c |  42 ---
 tests/tcg/mips/mips32-dsp/mult.c   |  24 --
 tests/tcg/mips/mips32-dsp/multu.c  |  24 --
 tests/tcg/mips/mips32-dsp/packrl_ph.c  |  21 --
 tests/tcg/mips/mips32-dsp/pick_ph.c|  49 
 tests/tcg/mips/mips32-dsp/pick_qb.c|  36 ---
 tests/tcg/mips/mips32-dsp/preceq_w_phl.c   |  20 --
 tests/tcg/mips/mips32-dsp/preceq_w_phr.c   |  20 --
 tests/tcg/mips/mips32-dsp/precequ_ph_qbl.c |  20 --
 tests/tcg/mips/mips32-dsp/precequ_ph_qbla.c|  

Re: [Qemu-devel] [PATCH v3 4/4] MAINTAINERS: Add Aleksandar Rikalo as a reviewer for MIPS content

[Aleksandar Rikalo]

> From: Aleksandar Markovic 
> Sent: Wednesday, December 26, 2018 6:15 PM
> To: qemu-devel@nongnu.org
> Cc: aurel...@aurel32.net; Paul Burton; hpous...@reactos.org; 
> jho...@kernel.org; Aleksandar Markovic; Stefan Markovic; > Aleksandar Rikalo
> Subject: [PATCH v3 4/4] MAINTAINERS: Add Aleksandar Rikalo as a reviewer for 
> MIPS content
>
> From: Aleksandar Markovic 
>
> Add Aleksandar Rikalo as a reviewer for MIPS content. Aleksandar
> brings to us more than six years of experience in working on a variety
> of development tools for MIPS architectures, and will greatly help
> QEMU community understand and support intricacies of MIPS better.
>
> Signed-off-by: Aleksandar Markovic 
> ---
>  MAINTAINERS | 9 +
>  1 file changed, 9 insertions(+)

Acked-by: Aleksandar Rikalo 
Reviewed-by: Aleksandar Rikalo 

>
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 39fb1ae..b06f534 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -205,6 +205,7 @@ F: disas/microblaze.c
>  MIPS
>  M: Aurelien Jarno 
>  M: Aleksandar Markovic 
> +R: Aleksandar Rikalo 
>  R: Stefan Markovic 
>  S: Maintained
>  F: target/mips/
> @@ -362,6 +363,7 @@ F: target/arm/kvm.c
>
>  MIPS
>  M: James Hogan 
> +R: Aleksandar Rikalo 
>  R: Stefan Markovic 
>  S: Maintained
>  F: target/mips/kvm.c
> @@ -871,6 +873,7 @@ MIPS Machines
>  -
>  Jazz
>  M: Hervé Poussineau 
> +R: Aleksandar Rikalo 
>  R: Stefan Markovic 
>  S: Maintained
>  F: hw/mips/mips_jazz.c
> @@ -879,12 +882,14 @@ F: hw/dma/rc4030.c
>
>  Malta
>  M: Aurelien Jarno 
> +R: Aleksandar Rikalo 
>  R: Stefan Markovic 
>  S: Maintained
>  F: hw/mips/mips_malta.c
>
>  Mipssim
>  M: Aleksandar Markovic 
> +R: Aleksandar Rikalo 
>  R: Stefan Markovic 
>  S: Odd Fixes
>  F: hw/mips/mips_mipssim.c
> @@ -892,12 +897,14 @@ F: hw/net/mipsnet.c
>
>  R4000
>  M: Aurelien Jarno 
> +R: Aleksandar Rikalo 
>  R: Stefan Markovic 
>  S: Maintained
>  F: hw/mips/mips_r4k.c
>
>  Fulong 2E
>  M: Aleksandar Markovic 
> +R: Aleksandar Rikalo 
>  R: Stefan Markovic 
>  S: Odd Fixes
>  F: hw/mips/mips_fulong2e.c
> @@ -907,6 +914,7 @@ F: include/hw/isa/vt82c686.h
>
>  Boston
>  M: Paul Burton 
> +R: Aleksandar Rikalo 
>  R: Stefan Markovic 
>  S: Maintained
>  F: hw/core/loader-fit.c
> @@ -2163,6 +2171,7 @@ F: disas/i386.c
>
>  MIPS target
>  M: Aurelien Jarno 
> +R: Aleksandar Rikalo 
>  R: Stefan Markovic 
>  S: Maintained
>  F: tcg/mips/
> --
> 2.7.4
>

Re: [Qemu-devel] [PATCH v2 23/52] audio: remove audio_MIN, audio_MAX

[Kővágó Zoltán]

On 2018-12-25 11:40, Philippe Mathieu-Daudé wrote:
> On 12/24/18 9:48 PM, Kővágó Zoltán wrote:
>> On 2018-12-24 18:16, Philippe Mathieu-Daudé wrote:
>>> On 12/24/18 3:16 AM, Zoltán Kővágó wrote:
 Hi Phil,

 On 2018-12-24 00:49, Philippe Mathieu-Daudé wrote:
> Hi Zoltán,
>
> On 12/23/18 9:51 PM, Kővágó, Zoltán wrote:
>> There's already a MIN and MAX macro in include/qemu/osdep.h, use them
>> instead.
>>
>> Signed-off-by: Kővágó, Zoltán 
>>
>> ---
>>
>> Changes from v1:
>> * removed audio_MIN, audio_MAX macros
>> ---
> [...]>
>> diff --git a/audio/audio.h b/audio/audio.h
>> index ccfef9e10a..bcbe56d639 100644
>> --- a/audio/audio.h
>> +++ b/audio/audio.h
>> @@ -148,23 +148,6 @@ static inline void *advance (void *p, int incr)
>>  return (d + incr);
>>  }
>>  
>> -#ifdef __GNUC__
>> -#define audio_MIN(a, b) ( __extension__ ({  \
>> -__typeof (a) ta = a;\
>> -__typeof (b) tb = b;\
>> -((ta)>(tb)?(tb):(ta));  \
>> -}))
>> -
>> -#define audio_MAX(a, b) ( __extension__ ({  \
>> -__typeof (a) ta = a;\
>> -__typeof (b) tb = b;\
>> -((ta)<(tb)?(tb):(ta));  \
>> -}))
>> -#else
>> -#define audio_MIN(a, b) ((a)>(b)?(b):(a))
>> -#define audio_MAX(a, b) ((a)<(b)?(b):(a))
>> -#endif
>> -
>
> Those MIN/MAX are smarter than the ones in "qemu/osdep.h", I'd keep them
> moving them there.

 Yes, but only when using gcc (or clang when it emulates gcc).
 Unfortunately, they work differently when one of the expressions has
 side effects, which is a disaster waiting to happen (when some poor folk
 finally tries to compile it with a non-gcc compiler).
>>>
>>> We already use the typeof extension:
>>>
>>> $ git grep typeof|wc -l
>>> 145
>>>
>>> For MIN/MAX I'd use rather use the __auto_type extension.
>>>
 Or do we support any compilers beside gcc and clang? Because if not,
 sure, do it, just remove the #ifdef and keep only the gcc version.
>>>
>>> Yes, this is checked by the ./configure script:
>>>
>>> 1850 # Check whether the compiler matches our minimum requirements:
>>> ...
>>> 1859 #   error You need at least Clang v3.4 to compile QEMU
>>> ...
>>> 1864 #  error You need at least GCC v4.8 to compile QEMU
>>> ...
>>> 1867 # error You either need GCC or Clang to compiler QEMU
>>
>> Fair enough. I've tried to check the documentation for supported
>> compilers, but I haven't found any info. Well, I didn't look at the
>> configure script, I admit that.
> 
> You haven't found any info because the minimum requirements are not well
> documented on the wiki.
> 
>>
>> This is what I came up with:
>>
>> #ifndef MIN
>> #define MIN(a, b) ( __extension__ ({  \
>> __auto_type _a = (a); \
>> __auto_type _b = (b); \
>> _a > _b ? _b : _a;\
>> }))
>> #endif
>> #ifndef MAX
>> #define MAX(a, b) ( __extension__ ({  \
>> __auto_type _a = (a); \
>> __auto_type _b = (b); \
>> _a < _b ? _b : _a;\
>> }))
>> #endif
>>
>>
>> I changed it a bit, since a and b are the macro parameters, so they are
>> the variables that we should put into parentheses, and I renamed ta/tb
>> to _a/_b, this way they're less likely to clobber some other variables.
> 
> Sounds good. Now the parentheses around a/b are not necessary.
> 
> I wonder however if it wouldn't be cleaner to previously add:
> 
> #ifdef MIN
> # undef MIN
> #endif
> 
> and for MAX, rather than only use these macros if undefs.

Um, this broke a few things. It also means until now in some cases it
used some random definition of MIN/MAX instead of the one in the header.

/home/dirty_ice/qemu/include/qemu/osdep.h:240:5: error: ‘__auto_type’
used with a bit-field initializer
/home/dirty_ice/qemu/include/qemu/osdep.h:247:35: error: braced-group
within expression allowed only inside a function

The first one is fixable with an explicit cast (ugly but works), but the
second one is more problematic. It means we can't write stuff like

USBPort  uports[MAX(MAXPORTS_2, MAXPORTS_3)];

when not in a function. So we either need a dumb version of MIN/MAX, or
scrape the idea altogether.

> 
>> To be honest, we could probably drop the __extension__ keyword too,
>> we're not compiling with -pedantic. Other than audio_MIN and audio_MAX,
>> it only appears in the DO_UPCAST macro.
> 
> Fine with me!
> 
> If you have this patch ready, you can send it alone out of this series,
> no need to resend this whole series for this patch.

There will be adjustmets to other patches too, so I think I'll just
consolidate them.

Regards,
Zoltan

Re: [Qemu-devel] vfio failure with intel 760p 128GB nvme

[Dongli Zhang]

Hi Alex,

On 12/02/2018 09:29 AM, Dongli Zhang wrote:
> Hi Alex,
> 
> On 12/02/2018 03:29 AM, Alex Williamson wrote:
>> On Sat, 1 Dec 2018 10:52:21 -0800 (PST)
>> Dongli Zhang  wrote:
>>
>>> Hi,
>>>
>>> I obtained below error when assigning an intel 760p 128GB nvme to guest via
>>> vfio on my desktop:
>>>
>>> qemu-system-x86_64: -device vfio-pci,host=:01:00.0: vfio :01:00.0: 
>>> failed to add PCI capability 0x11[0x50]@0xb0: table & pba overlap, or they 
>>> don't fit in BARs, or don't align
>>>
>>>
>>> This is because the msix table is overlapping with pba. According to below
>>> 'lspci -vv' from host, the distance between msix table offset and pba 
>>> offset is
>>> only 0x100, although there are 22 entries supported (22 entries need 0x160).
>>> Looks qemu supports at most 0x800.
>>>
>>> # sudo lspci -vv
>>> ... ...
>>> 01:00.0 Non-Volatile memory controller: Intel Corporation Device f1a6 (rev 
>>> 03) (prog-if 02 [NVM Express])
>>> Subsystem: Intel Corporation Device 390b
>>> ... ...
>>> Capabilities: [b0] MSI-X: Enable- Count=22 Masked-
>>> Vector table: BAR=0 offset=2000
>>> PBA: BAR=0 offset=2100
>>>
>>>
>>>
>>> A patch below could workaround the issue and passthrough nvme successfully.
>>>
>>> diff --git a/hw/vfio/pci.c b/hw/vfio/pci.c
>>> index 5c7bd96..54fc25e 100644
>>> --- a/hw/vfio/pci.c
>>> +++ b/hw/vfio/pci.c
>>> @@ -1510,6 +1510,11 @@ static void vfio_msix_early_setup(VFIOPCIDevice 
>>> *vdev, Error **errp)
>>>  msix->pba_offset = pba & ~PCI_MSIX_FLAGS_BIRMASK;
>>>  msix->entries = (ctrl & PCI_MSIX_FLAGS_QSIZE) + 1;
>>>  
>>> +if (msix->table_bar == msix->pba_bar &&
>>> +msix->table_offset + msix->entries * PCI_MSIX_ENTRY_SIZE > 
>>> msix->pba_offset) {
>>> +msix->entries = (msix->pba_offset - msix->table_offset) / 
>>> PCI_MSIX_ENTRY_SIZE;
>>> +}
>>> +
>>>  /*
>>>   * Test the size of the pba_offset variable and catch if it extends 
>>> outside
>>>   * of the specified BAR. If it is the case, we need to apply a hardware
>>>
>>>
>>> Would you please help confirm if this can be regarded as bug in qemu, or 
>>> issue
>>> with nvme hardware? Should we fix thin in qemu, or we should never use such 
>>> buggy
>>> hardware with vfio?
>>
>> It's a hardware bug, is there perhaps a firmware update for the device
>> that resolves it?  It's curious that a vector table size of 0x100 gives
>> us 16 entries and 22 in hex is 0x16 (table size would be reported as
>> 0x15 for the N-1 algorithm).  I wonder if there's a hex vs decimal
>> mismatch going on.  We don't really know if the workaround above is
>> correct, are there really 16 entries or maybe does the PBA actually
>> start at a different offset?  We wouldn't want to generically assume
>> one or the other.  I think we need Intel to tell us in which way their
>> hardware is broken and whether it can or is already fixed in a firmware
>> update.  Thanks,
> 
> Thank you very much for the confirmation.
> 
> Just realized looks this would make trouble to my desktop as well when 17
> vectors are used.
> 
> I will report to intel and confirm how this can happen and if there is any
> firmware update available for this issue.
> 

I found there is similar issue reported to kvm:

https://bugzilla.kernel.org/show_bug.cgi?id=202055


I confirmed with my env again. By default, the msi-x count is 16.

Capabilities: [b0] MSI-X: Enable+ Count=16 Masked-
Vector table: BAR=0 offset=2000
PBA: BAR=0 offset=2100


The count is still 16 after the device is assigned to vfio (Enable- now):

# echo :01:00.0 > /sys/bus/pci/devices/\:01\:00.0/driver/unbind
# echo "8086 f1a6" > /sys/bus/pci/drivers/vfio-pci/new_id

Capabilities: [b0] MSI-X: Enable- Count=16 Masked-
Vector table: BAR=0 offset=2000
PBA: BAR=0 offset=2100


After I boot qemu with "-device vfio-pci,host=:01:00.0", count becomes 22.

Capabilities: [b0] MSI-X: Enable- Count=22 Masked-
Vector table: BAR=0 offset=2000
PBA: BAR=0 offset=2100



Another interesting observation is, vfio-based userspace nvme also changes count
from 16 to 22.

I reboot host and the count is reset to 16. Then I boot VM with "-drive
file=nvme://:01:00.0/1,if=none,id=nvmedrive0 -device
virtio-blk,drive=nvmedrive0,id=nvmevirtio0". As userspace nvme uses different
vfio path, it boots successfully without issue.

However, the count becomes 22 then:

Capabilities: [b0] MSI-X: Enable- Count=22 Masked-
Vector table: BAR=0 offset=2000
PBA: BAR=0 offset=2100


Both vfio and userspace nvme (based on vfio) would change the count from 16 to 
22.

Dongli Zhang

Re: [Qemu-devel] vfio failure with intel 760p 128GB nvme

[Dongli Zhang]

Hi Alex,

On 12/02/2018 09:29 AM, Dongli Zhang wrote:
> Hi Alex,
> 
> On 12/02/2018 03:29 AM, Alex Williamson wrote:
>> On Sat, 1 Dec 2018 10:52:21 -0800 (PST)
>> Dongli Zhang  wrote:
>>
>>> Hi,
>>>
>>> I obtained below error when assigning an intel 760p 128GB nvme to guest via
>>> vfio on my desktop:
>>>
>>> qemu-system-x86_64: -device vfio-pci,host=:01:00.0: vfio :01:00.0: 
>>> failed to add PCI capability 0x11[0x50]@0xb0: table & pba overlap, or they 
>>> don't fit in BARs, or don't align
>>>
>>>
>>> This is because the msix table is overlapping with pba. According to below
>>> 'lspci -vv' from host, the distance between msix table offset and pba 
>>> offset is
>>> only 0x100, although there are 22 entries supported (22 entries need 0x160).
>>> Looks qemu supports at most 0x800.
>>>
>>> # sudo lspci -vv
>>> ... ...
>>> 01:00.0 Non-Volatile memory controller: Intel Corporation Device f1a6 (rev 
>>> 03) (prog-if 02 [NVM Express])
>>> Subsystem: Intel Corporation Device 390b
>>> ... ...
>>> Capabilities: [b0] MSI-X: Enable- Count=22 Masked-
>>> Vector table: BAR=0 offset=2000
>>> PBA: BAR=0 offset=2100
>>>
>>>
>>>
>>> A patch below could workaround the issue and passthrough nvme successfully.
>>>
>>> diff --git a/hw/vfio/pci.c b/hw/vfio/pci.c
>>> index 5c7bd96..54fc25e 100644
>>> --- a/hw/vfio/pci.c
>>> +++ b/hw/vfio/pci.c
>>> @@ -1510,6 +1510,11 @@ static void vfio_msix_early_setup(VFIOPCIDevice 
>>> *vdev, Error **errp)
>>>  msix->pba_offset = pba & ~PCI_MSIX_FLAGS_BIRMASK;
>>>  msix->entries = (ctrl & PCI_MSIX_FLAGS_QSIZE) + 1;
>>>  
>>> +if (msix->table_bar == msix->pba_bar &&
>>> +msix->table_offset + msix->entries * PCI_MSIX_ENTRY_SIZE > 
>>> msix->pba_offset) {
>>> +msix->entries = (msix->pba_offset - msix->table_offset) / 
>>> PCI_MSIX_ENTRY_SIZE;
>>> +}
>>> +
>>>  /*
>>>   * Test the size of the pba_offset variable and catch if it extends 
>>> outside
>>>   * of the specified BAR. If it is the case, we need to apply a hardware
>>>
>>>
>>> Would you please help confirm if this can be regarded as bug in qemu, or 
>>> issue
>>> with nvme hardware? Should we fix thin in qemu, or we should never use such 
>>> buggy
>>> hardware with vfio?
>>
>> It's a hardware bug, is there perhaps a firmware update for the device
>> that resolves it?  It's curious that a vector table size of 0x100 gives
>> us 16 entries and 22 in hex is 0x16 (table size would be reported as
>> 0x15 for the N-1 algorithm).  I wonder if there's a hex vs decimal
>> mismatch going on.  We don't really know if the workaround above is
>> correct, are there really 16 entries or maybe does the PBA actually
>> start at a different offset?  We wouldn't want to generically assume
>> one or the other.  I think we need Intel to tell us in which way their
>> hardware is broken and whether it can or is already fixed in a firmware
>> update.  Thanks,
> 
> Thank you very much for the confirmation.
> 
> Just realized looks this would make trouble to my desktop as well when 17
> vectors are used.
> 
> I will report to intel and confirm how this can happen and if there is any
> firmware update available for this issue.
> 

I found there is similar issue reported to kvm:

https://bugzilla.kernel.org/show_bug.cgi?id=202055


I confirmed with my env again. By default, the msi-x count is 16.

Capabilities: [b0] MSI-X: Enable+ Count=16 Masked-
Vector table: BAR=0 offset=2000
PBA: BAR=0 offset=2100


The count is still 16 after the device is assigned to vfio (Enable- now):

# echo :01:00.0 > /sys/bus/pci/devices/\:01\:00.0/driver/unbind
# echo "8086 f1a6" > /sys/bus/pci/drivers/vfio-pci/new_id

Capabilities: [b0] MSI-X: Enable- Count=16 Masked-
Vector table: BAR=0 offset=2000
PBA: BAR=0 offset=2100


After I boot qemu with "-device vfio-pci,host=:01:00.0", count becomes 22.

Capabilities: [b0] MSI-X: Enable- Count=22 Masked-
Vector table: BAR=0 offset=2000
PBA: BAR=0 offset=2100



Another interesting observation is, vfio-based userspace nvme also changes count
from 16 to 22.

I reboot host and the count is reset to 16. Then I boot VM with "-drive
file=nvme://:01:00.0/1,if=none,id=nvmedrive0 -device
virtio-blk,drive=nvmedrive0,id=nvmevirtio0". As userspace nvme uses different
vfio path, it boots successfully without issue.

However, the count becomes 22 then:

Capabilities: [b0] MSI-X: Enable- Count=22 Masked-
Vector table: BAR=0 offset=2000
PBA: BAR=0 offset=2100


Both vfio and userspace nvme (based on vfio) would change the count from 16 to 
22.

Dongli Zhang

[Qemu-devel] [PATCH] smbus_eeprom: Limit data writes to 255 bytes

[Michael Hanselmann]

The "eeprom_write_data" function in "smbus_eeprom.c" had no provisions
to limit the length of data written. If a caller were able to manipulate
the "len" parameter they could potentially write before or after the
target buffer.
---
 hw/i2c/smbus_eeprom.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/hw/i2c/smbus_eeprom.c b/hw/i2c/smbus_eeprom.c
index f18aa3de35..74fa1c328c 100644
--- a/hw/i2c/smbus_eeprom.c
+++ b/hw/i2c/smbus_eeprom.c
@@ -76,6 +76,7 @@ static void eeprom_write_data(SMBusDevice *dev, uint8_t cmd, 
uint8_t *buf, int l
It is a block write without a length byte.  Fortunately we
get the full block anyway.  */
 /* TODO: Should this set the current location?  */
+len &= 0xff;
 if (cmd + len > 256)
 n = 256 - cmd;
 else
-- 
2.11.0

Re: [Qemu-devel] [RFC PATCH 04/13] tests/tcg/mips: enable mips32-dsp/mips32-dspr2/mipsr5900 linux-user (WIP)

[Aleksandar Markovic]

HI, Alex, just a heads up that I plan to submit directory and file
reorganization of tests/tcg/mips mini patch series today or tomorrow.
Aleksandar

On Wednesday, December 19, 2018, Alex Bennée  wrote:

>
> Aleksandar Markovic  writes:
>
> > On Dec 10, 2018 4:29 PM, "Alex Bennée"  wrote:
> >>
> >> Convert the existing tests to use our common cross build
> >> infrastructure.
> >>
> >> [WIP: mips32r2 disabled to avoid name clash]
> >> [WIP: mipsr5900 disabled due to clashing build flags]
> >>
> >> Signed-off-by: Alex Bennée 
> >> ---
> >>  tests/tcg/mips/Makefile.target   |  15 ++-
> >>  tests/tcg/mips/mips32-dsp/Makefile   | 166 +--
> >>  tests/tcg/mips/mips32-dspr2/Makefile |  83 +++---
> >>  tests/tcg/mips/mipsr5900/Makefile|  40 +++
> >>  4 files changed, 75 insertions(+), 229 deletions(-)
> >>
> >
> > Alex,
> >
> > How about reorganizing directories in tests/tcg/mips altogether, and make
> > it less confusing, and easier for future developers to approach an work
> on?
> >
> > Let's say like this:
> >
> > tests/tcg/mips
> > user
> > isa
> > r5900
> > ase
> > dsp
> > dsp_r2
> > system
> > isa   《for now empty》
> > ase
> > dsp
> > dsp_r2
>
> Yeah sounds like a plan. I'm going to do the same with cris (bare and
> libc).
>
> >
> > Thanks,
> > Aleksandar
>
>
> --
> Alex Bennée
>

Re: [Qemu-devel] Qemu the right way -[Subthread Cores]

[Andrew Randrianasulu]

> Since I do not have networking sorted out yet I cannot update win7 pro, and 
> it 
might be the updates which are needed for allowing more than two cpus.

hm, brief search on my side resulted in this tip:

https://answers.microsoft.com/en-us/windows/forum/windows_7-hardware/windows-7-professional-x64-only-showing-2-of-8/0155f525-df73-4642-a828-21b80d1564b0

--
Some recommendations (in Windows, make sure you are running as Administrator):
 
- Run MSConfig -> Change to Boot tab -> Advanced Options -> "Number of 
Processors", make sure there is no check mark.
- Delete processor entries listed in Device Manager, then reboot.

-

(I don't think BIOS options from this answer really apply directly to qemu case)

also, if win (or some applications inside it) keep crashing with -cpu host, you 
can try to reload host (Linux) kvm module with additional option:

"options kvm ignore_msrs=1" line (without quotes) should be added to
 /etc/modprobe.d/kvm.conf

from 
https://www.passmark.com/forum/performancetest/4748-startup-error-number-4-on-qemu-bsod

Re: [Qemu-devel] [RFC PATCH 0/7] virtio-fs: shared file system for virtual machines3

[Vivek Goyal]

On Sat, Dec 22, 2018 at 05:27:28PM +0800, jiangyiwen wrote:
> On 2018/12/11 1:31, Dr. David Alan Gilbert (git) wrote:
> > From: "Dr. David Alan Gilbert" 
> > 
> > Hi,
> >   This is the first RFC for the QEMU side of 'virtio-fs';
> > a new mechanism for mounting host directories into the guest
> > in a fast, consistent and secure manner.  Our primary use
> > case is kata containers, but it should be usable in other scenarios
> > as well.
> > 
> > There are corresponding patches being posted to Linux kernel,
> > libfuse and kata lists.
> > 
> > For a fuller design description, and benchmark numbers, please see
> > Vivek's posting of the kernel set here:
> > 
> > https://marc.info/?l=linux-kernel=154446243024251=2
> > 
> > We've got a small website with instructions on how to use it, here:
> > 
> > https://virtio-fs.gitlab.io/
> > 
> > and all the code is available on gitlab at:
> > 
> > https://gitlab.com/virtio-fs
> > 
> > QEMU's changes
> > --
> > 
> > The QEMU changes are pretty small; 
> > 
> > There's a new vhost-user device, which is used to carry a stream of
> > FUSE messages to an external daemon that actually performs
> > all the file IO.  The FUSE daemon is an external process in order to
> > achieve better isolation for security and resource control (e.g. number
> > of file descriptors) and also because it's cleaner than trying to
> > integrate libfuse into QEMU.
> > 
> > This device has an extra BAR that contains (up to) 3 regions:
> > 
> >  a) a DAX mapping range ('the cache') - into which QEMU mmap's
> > files on behalf of the external daemon; those files are
> > then directly mapped by the guest in a way similar to a DAX
> > backed file system;  one advantage of this is that multiple
> > guests all accessing the same files should all be sharing
> > those pages of host cache.
> > 
> >  b) An experimental set of mappings for use by a metadata versioning
> > daemon;  this mapping is shared between multiple guests and
> > the daemon, but only contains a set of version counters that
> > allow a guest to quickly tell if its metadata is stale.
> > 
> > TODO
> > 
> > 
> > This is the first RFC, we know we have a bunch of things to clear up:
> > 
> >   a) The virtio device specificiation is still in flux and is expected
> >  to change
> > 
> >   b) We'd like to find ways of reducing the map/unmap latency for DAX
> > 
> >   c) The metadata versioning scheme needs to settle out.
> > 
> >   d) mmap'ing host files has some interesting side effects; for example
> >  if the file gets truncated by the host and then the guest accesses
> >  the mapping, KVM can fail the guest hard.
> > 
> > Dr. David Alan Gilbert (6):
> >   virtio: Add shared memory capability
> >   virtio-fs: Add cache BAR
> >   virtio-fs: Add vhost-user slave commands for mapping
> >   virtio-fs: Fill in slave commands for mapping
> >   virtio-fs: Allow mapping of meta data version table
> >   virtio-fs: Allow mapping of journal
> > 
> > Stefan Hajnoczi (1):
> >   virtio: add vhost-user-fs-pci device
> > 
> >  configure   |  10 +
> >  contrib/libvhost-user/libvhost-user.h   |   3 +
> >  docs/interop/vhost-user.txt |  35 ++
> >  hw/virtio/Makefile.objs |   1 +
> >  hw/virtio/vhost-user-fs.c   | 517 
> >  hw/virtio/vhost-user.c  |  16 +
> >  hw/virtio/virtio-pci.c  | 115 +
> >  hw/virtio/virtio-pci.h  |  19 +
> >  include/hw/pci/pci.h|   1 +
> >  include/hw/virtio/vhost-user-fs.h   |  79 +++
> >  include/standard-headers/linux/virtio_fs.h  |  48 ++
> >  include/standard-headers/linux/virtio_ids.h |   1 +
> >  include/standard-headers/linux/virtio_pci.h |   9 +
> >  13 files changed, 854 insertions(+)
> >  create mode 100644 hw/virtio/vhost-user-fs.c
> >  create mode 100644 include/hw/virtio/vhost-user-fs.h
> >  create mode 100644 include/standard-headers/linux/virtio_fs.h
> > 
> 
> Hi Dave,
> 
> I encounter a problem after running qemu with virtio-fs,
> 
> I find I only can mount virtio-fs using the following command:
> mount -t virtio_fs /dev/null /mnt/virtio_fs/ -o 
> tag=myfs,rootmode=04,user_id=0,group_id=0
> or mount -t virtio_fs /dev/null /mnt/virtio_fs/ -o 
> tag=myfs,rootmode=04,user_id=0,group_id=0,dax
> 
> Then, I want to know how to use "cache=always" or "cache=none", even 
> "cache=auto", "cache=writeback"?
> 
> Thanks,
> Yiwen.

Hi Yiwen,

As of now, cache options are libfuse daemon options. So while starting
daemon, specify "-o cache=none" or "-o cache=always" etc. One can not
specify caching option at virtio-fs mount time.

Thanks
Vivek