From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 3D1A7C433F5 for ; Mon, 11 Oct 2021 12:20:56 +0000 (UTC) Received: from lists.gnu.org (lists.gnu.org [209.51.188.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 9436C60F92 for ; Mon, 11 Oct 2021 12:20:55 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org 9436C60F92 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=redhat.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=nongnu.org Received: from localhost ([::1]:52962 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1mZuIW-0008N4-QB for qemu-devel@archiver.kernel.org; Mon, 11 Oct 2021 08:20:52 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:41462) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mZuGx-0007RH-7Q for qemu-devel@nongnu.org; Mon, 11 Oct 2021 08:19:15 -0400 Received: from us-smtp-delivery-124.mimecast.com ([170.10.133.124]:40124) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mZuGr-0003lC-Hk for qemu-devel@nongnu.org; Mon, 11 Oct 2021 08:19:13 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1633954748; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=Jb7CpB0d+Wl1ehagdarIsNFaoEb0mjOUCUsG+KBIjIE=; b=MBy0eG6ipWaQlrsaGxUcXojGQvEmvnkSwqkrHyloHSHKzP1bpeITA0DUlfWDtGtr5KqLgH ApILYQlg/16c5AwYpexTv8VpymCPuQLiYonDqFL4rQ9pSOBxnJDf06smJNYCDwtQ2mMIwY 9fQ46zRuYDUvuxkBS/hSq5cxpU7q3uM= Received: from mail-ed1-f70.google.com (mail-ed1-f70.google.com [209.85.208.70]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-44-timbkqMyOFGnwdcMyIr5QQ-1; Mon, 11 Oct 2021 08:19:06 -0400 X-MC-Unique: timbkqMyOFGnwdcMyIr5QQ-1 Received: by mail-ed1-f70.google.com with SMTP id e14-20020a056402088e00b003db6ebb9526so6124893edy.22 for ; Mon, 11 Oct 2021 05:19:06 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:content-transfer-encoding :in-reply-to; bh=Jb7CpB0d+Wl1ehagdarIsNFaoEb0mjOUCUsG+KBIjIE=; b=qtfVNME4BY8skPmrxguihksxhSqAMscaLqlJK09zaNDuxObKVglTWdYaEeVPwfOyxh uJPtguRwNpx/NkmSz3IzLqHLoxxMXD03DWf6vFfmvoajjF1GjheD5P9NWax7vW/BOM+c TTYN7Le6LI6TpugSXeiQIyNujddcGAkevYP6uVnVERO7xTUVerwx7Gt8MHmZYoH4RHCS 7OOztirqbRsM2iMlMkyno+5iGK+EBZB14SrTyomfsXq7rzcFmCBMkGlVYHqsvD5ZiePR MNAWybyzZCmIRjVm12a46xYyo/1oXf0PcSCuM2SPPnvpVn8rNQaMFdfY8ed64i7OOG4X S3WA== X-Gm-Message-State: AOAM532unzVcahpcjsVfSgqscZaz01qdPxPkoyxL92xpLv238jdc2HXT bZcanoaqfC9w1wxucTk2pwqYxmyQd8LRzNV3I+y+apN5vj2qmNx5KRG9GHsCojk8xvC5SpOUxVJ SfFfa9mOAdOQioyI= X-Received: by 2002:a17:906:4e89:: with SMTP id v9mr18223681eju.354.1633954745723; Mon, 11 Oct 2021 05:19:05 -0700 (PDT) X-Google-Smtp-Source: ABdhPJybvghp/xcOq6rQW31hAX6ZkytN056s3dyc0EzVdYDjJ7JFYaZ/q5iwOloQoE2inocKC9VT+A== X-Received: by 2002:a17:906:4e89:: with SMTP id v9mr18223644eju.354.1633954745387; Mon, 11 Oct 2021 05:19:05 -0700 (PDT) Received: from redhat.com ([2.55.159.57]) by smtp.gmail.com with ESMTPSA id dh16sm4069638edb.63.2021.10.11.05.19.03 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 11 Oct 2021 05:19:04 -0700 (PDT) Date: Mon, 11 Oct 2021 08:19:01 -0400 From: "Michael S. Tsirkin" To: BALATON Zoltan Subject: Re: ACPI endianness Message-ID: <20211011080528-mutt-send-email-mst@kernel.org> References: <957db5ec-fc70-418-44d9-da4f81f5b98@eik.bme.hu> <612d2f0b-f312-073d-b796-c76357ba51a2@redhat.com> MIME-Version: 1.0 In-Reply-To: Authentication-Results: relay.mimecast.com; auth=pass smtp.auth=CUSA124A263 smtp.mailfrom=mst@redhat.com X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit Received-SPF: pass client-ip=170.10.133.124; envelope-from=mst@redhat.com; helo=us-smtp-delivery-124.mimecast.com X-Spam_score_int: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.1 / 5.0 requ) BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.049, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: qemu-devel@nongnu.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Igor Mammedov , Philippe =?iso-8859-1?Q?Mathieu-Daud=E9?= , qemu-devel@nongnu.org, pbonzini@redhat.com Errors-To: qemu-devel-bounces+qemu-devel=archiver.kernel.org@nongnu.org Sender: "Qemu-devel" On Mon, Oct 11, 2021 at 12:13:55PM +0200, BALATON Zoltan wrote: > On Mon, 11 Oct 2021, Philippe Mathieu-Daudé wrote: > > On 10/10/21 15:24, BALATON Zoltan wrote: > > > Hello, > > > > > > I'm trying to fix shutdown and reboot on pegasos2 which uses ACPI as > > > part of the VIA VT8231 (similar to and modelled in hw/isa/vt82c686b.c) > > > and found that the guest writes to ACPI PM1aCNT register come out with > > > wrong endianness but not shure why. I have this: > > > > > > $ qemu-system-ppc -M pegasos2 -monitor stdio > > > (qemu) info mtree > > > [...] > > > memory-region: pci1-io > > >   0000000000000000-000000000000ffff (prio 0, i/o): pci1-io > > > [...] > > >     0000000000000f00-0000000000000f7f (prio 0, i/o): via-pm > > >       0000000000000f00-0000000000000f03 (prio 0, i/o): acpi-evt > > >       0000000000000f04-0000000000000f05 (prio 0, i/o): acpi-cnt > > >       0000000000000f08-0000000000000f0b (prio 0, i/o): acpi-tmr > > > > > > memory-region: system > > >   0000000000000000-ffffffffffffffff (prio 0, i/o): system > > >     0000000000000000-000000001fffffff (prio 0, ram): pegasos2.ram > > >     0000000080000000-00000000bfffffff (prio 0, i/o): alias pci1-mem0-win > > > @pci1-mem 0000000080000000-00000000bfffffff > > >     00000000c0000000-00000000dfffffff (prio 0, i/o): alias pci0-mem0-win > > > @pci0-mem 00000000c0000000-00000000dfffffff > > >     00000000f1000000-00000000f100ffff (prio 0, i/o): mv64361 > > >     00000000f8000000-00000000f8ffffff (prio 0, i/o): alias pci0-io-win > > > @pci0-io 0000000000000000-0000000000ffffff > > >     00000000f9000000-00000000f9ffffff (prio 0, i/o): alias pci0-mem1-win > > > @pci0-mem 0000000000000000-0000000000ffffff > > >     00000000fd000000-00000000fdffffff (prio 0, i/o): alias pci1-mem1-win > > > @pci1-mem 0000000000000000-0000000000ffffff > > >     00000000fe000000-00000000feffffff (prio 0, i/o): alias pci1-io-win > > > @pci1-io 0000000000000000-0000000000ffffff > > >     00000000ff800000-00000000ffffffff (prio 0, i/o): alias pci1-mem3-win > > > @pci1-mem 00000000ff800000-00000000ffffffff > > >     00000000fff00000-00000000fff7ffff (prio 0, rom): pegasos2.rom > > > > > > The guest (which is big endian PPC and I think wotks on real hardware) > > > writes to 0xf05 in the io region which should be the high byte of the > > > little endian register but in the acpi code it comes out wrong, instead > > > of 0x2800 I get in acpi_pm1_cnt_write: val=0x28 > > > > Looks like a northbridge issue (MV64340). > > Does Pegasos2 enables bus swapping? > > See hw/pci-host/mv64361.c:585: > > > > static void warn_swap_bit(uint64_t val) > > { > > if ((val & 0x3000000ULL) >> 24 != 1) { > > qemu_log_mask(LOG_UNIMP, "%s: Data swap not implemented", __func__); > > } > > } > > No, guests don't use this feature just byteswap themselves and write little > endian values to the mapped io region. (Or in this case just write one byte > of the 16 bit value, it specifically writes 0x28 to 0xf05.) That's why I > think the device model should not byteswap itself so the acpi regions should > be declared native endian and let the guest handle it. Some mentions I've > found say that native endian means don't byteswap, little endian means > byteswap if vcpu is big endian and big endian means byteswap if vcpu is > little endian. Since guests already account for this and write little endian > values to these regions there's no need to byteswap in device model and > changing to native endian should not affect little endian machines so unless > there's a better argument I'll try sending a patch. > > Regards, > BALATON Zoltan native endian means endian-ness is open-coded in the device handler itself. I think you just found a bug in memory core. static const MemoryRegionOps acpi_pm_cnt_ops = { .read = acpi_pm_cnt_read, .write = acpi_pm_cnt_write, .impl.min_access_size = 2, .valid.min_access_size = 1, .valid.max_access_size = 2, .endianness = DEVICE_LITTLE_ENDIAN, }; Because of that .impl.min_access_size = 2, the 1 byte write should be converted to a 2 byte read+2 byte write. docs/devel/memory.rst just says: - .impl.min_access_size, .impl.max_access_size define the access sizes (in bytes) supported by the *implementation*; other access sizes will be emulated using the ones available. For example a 4-byte write will be emulated using four 1-byte writes, if .impl.max_access_size = 1. Instead what we have is: MemTxResult memory_region_dispatch_write(MemoryRegion *mr, hwaddr addr, uint64_t data, MemOp op, MemTxAttrs attrs) { unsigned size = memop_size(op); if (!memory_region_access_valid(mr, addr, size, true, attrs)) { unassigned_mem_write(mr, addr, data, size); return MEMTX_DECODE_ERROR; } adjust_endianness(mr, &data, op); --- static void adjust_endianness(MemoryRegion *mr, uint64_t *data, MemOp op) { if ((op & MO_BSWAP) != devend_memop(mr->ops->endianness)) { switch (op & MO_SIZE) { case MO_8: break; case MO_16: *data = bswap16(*data); break; case MO_32: *data = bswap32(*data); break; case MO_64: *data = bswap64(*data); break; default: g_assert_not_reached(); } } } so the byte swap is based on size before extending it to .impl.min_access_size, not after. Also, no read happens which I suspect is also a bug, but could be harmless ... Paolo, any feedback here? -- MST