On 04/04/2023 7:37 am, Jan Beulich wrote:
> x86_emulate is a real (directory) target.
>
> Signed-off-by: Jan Beulich
Acked-by: Andrew Cooper
On 04/04/2023 7:37 am, Jan Beulich wrote:
> The latter of the two commits referenced below converted x86_emulate
> from a symlinked dir to a real one, holding symlinked files. Yet even
> before that the split between distclean and clean was suspicious: A
> similar split, removing symlinks only in d
PHYSDEVOP_pirq_eoi_gmfn_v accepting just a single GFN implies that no
more than 32k pIRQ-s can be used by a domain. Document this upper bound.
Signed-off-by: Jan Beulich
---
I was uncertain about also introducing a bounds check in code: We don't
check for bogus / abusive values elsewhere either.
On 03.04.2023 20:40, Oleksii wrote:
> Hello Julien,
> On Fri, 2023-03-31 at 22:05 +0100, Julien Grall wrote:
>> Hi Oleksii,
>>
>> I was going to ack the patch but then I spotted something that would
>> want some clarification.
>>
>> On 29/03/2023 11:50, Oleksii Kurochko wrote:
>>> diff --git a/xe
x86_emulate is a real (directory) target.
Signed-off-by: Jan Beulich
--- a/tools/tests/x86_emulator/Makefile
+++ b/tools/tests/x86_emulator/Makefile
@@ -278,7 +278,6 @@ else
run32 clean32: %32: %
endif
-.PHONY: x86_emulate
x86_emulate:
mkdir -p $@
ln -sf $(XEN_ROOT)/xen/arch
The latter of the two commits referenced below converted x86_emulate
from a symlinked dir to a real one, holding symlinked files. Yet even
before that the split between distclean and clean was suspicious: A
similar split, removing symlinks only in distclean, doesn't exist
anywhere else in the tree
flight 180126 xen-unstable real [real]
flight 180132 xen-unstable real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/180126/
http://logs.test-lab.xenproject.org/osstest/logs/180132/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
test-amd6
flight 180130 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/180130/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-freebsd12-amd64 17 guest-localmigrate fail REGR. vs. 180116
test-amd64-amd64-li
On 3/24/23 16:22, Huang Rui wrote:
> On Thu, Mar 16, 2023 at 07:14:47AM +0800, Dmitry Osipenko wrote:
>> On 3/13/23 18:55, Huang Rui wrote:
>>> On Mon, Mar 13, 2023 at 01:51:03AM +0800, Dmitry Osipenko wrote:
On 3/12/23 12:22, Huang Rui wrote:
> From: Antonio Caggiano
>
> Request
On 3/4/23 20:29, Stefan Hajnoczi wrote:
Only report a transport reset event to the guest after the SCSIDevice
has been unrealized by qdev_simple_device_unplug_cb().
qdev_simple_device_unplug_cb() sets the SCSIDevice's qdev.realized field
to false so that scsi_device_find/get() no longer see it.
Am 3. April 2023 12:27:14 UTC schrieb Jason Andryuk :
>On Mon, Apr 3, 2023 at 5:33 AM Anthony PERARD
>wrote:
>>
>> On Sat, Apr 01, 2023 at 10:36:45PM +, Bernhard Beschow wrote:
>> >
>> >
>> > Am 30. März 2023 13:00:25 UTC schrieb Anthony PERARD
>> > :
>> > >On Sun, Mar 12, 2023 at 01:02:1
flight 180127 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/180127/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 26997800c991f934b57ebd91de2edcd93312f756
baseline version:
ovmf fc00ff286a541c047b7d3
Hello Julien,
On Fri, 2023-03-31 at 22:05 +0100, Julien Grall wrote:
> Hi Oleksii,
>
> I was going to ack the patch but then I spotted something that would
> want some clarification.
>
> On 29/03/2023 11:50, Oleksii Kurochko wrote:
> > diff --git a/xen/arch/arm/include/asm/bug.h
> > b/xen/arch/
These functions must be called with the AioContext acquired:
/* Callers must hold exp->ctx lock */
void blk_exp_ref(BlockExport *exp)
...
/* Callers must hold exp->ctx lock */
void blk_exp_unref(BlockExport *exp)
Signed-off-by: Stefan Hajnoczi
---
block/export/fuse.c | 4
1 file
All callers now pass is_external=false to aio_set_fd_handler() and
aio_set_event_notifier(). The aio_disable_external() API that
temporarily disables fd handlers that were registered is_external=true
is therefore dead code.
Remove aio_disable_external(), aio_enable_external(), and the
is_external
vduse_blk_detach_ctx() waits for in-flight requests using
AIO_WAIT_WHILE(). This is not allowed according to a comment in
bdrv_set_aio_context_commit():
/*
* Take the old AioContex when detaching it from bs.
* At this point, new_context lock is already acquired, and we are now
* also ta
This is part of ongoing work to remove the aio_disable_external() API.
Use BlockDevOps .drained_begin/end/poll() instead of
aio_set_fd_handler(is_external=true).
As a side-effect the FUSE export now follows AioContext changes like the
other export types.
Signed-off-by: Stefan Hajnoczi
---
bloc
The aio_disable_external() API temporarily suspends file descriptor monitoring
in the event loop. The block layer uses this to prevent new I/O requests being
submitted from the guest and elsewhere between bdrv_drained_begin() and
bdrv_drained_end().
While the block layer still needs to prevent new
Host notifiers trigger virtqueue processing. There are critical sections
when new I/O requests must not be submitted because they would cause
interference.
In the past this was solved using aio_set_event_notifiers()
is_external=true argument, which disables fd monitoring between
aio_disable/enable
There is no need to suspend activity between aio_disable_external() and
aio_enable_external(), which is mainly used for the block layer's drain
operation.
This is part of ongoing work to remove the aio_disable_external() API.
Signed-off-by: Stefan Hajnoczi
---
hw/i386/kvm/xen_xenstore.c | 2 +-
The VuServer object has a refcount field and ref/unref APIs. The name is
confusing because it's actually an in-flight request counter instead of
a refcount.
Normally a refcount destroys the object upon reaching zero. The VuServer
counter is used to wake up the vhost-user coroutine when there are n
is_external=true suspends fd handlers between aio_disable_external() and
aio_enable_external(). The block layer's drain operation uses this
mechanism to prevent new I/O from sneaking in between
bdrv_drained_begin() and bdrv_drained_end().
The xen-block device actually works fine with is_external=f
This patch is part of an effort to remove the aio_disable_external()
API because it does not fit in a multi-queue block layer world where
many AioContexts may be submitting requests to the same disk.
The SCSI emulation code is already in good shape to stop using
aio_disable_external(). It was only
Only report a transport reset event to the guest after the SCSIDevice
has been unrealized by qdev_simple_device_unplug_cb().
qdev_simple_device_unplug_cb() sets the SCSIDevice's qdev.realized field
to false so that scsi_device_find/get() no longer see it.
scsi_target_emulate_report_luns() also ne
vhost_user_server_stop() uses AIO_WAIT_WHILE(). AIO_WAIT_WHILE()
requires that AioContext is only acquired once.
Since blk_exp_request_shutdown() already acquires the AioContext it
shouldn't be acquired again in vhost_user_server_stop().
Signed-off-by: Stefan Hajnoczi
---
util/vhost-user-server
vhost-user activity must be suspended during bdrv_drained_begin/end().
This prevents new requests from interfering with whatever is happening
in the drained section.
Previously this was done using aio_set_fd_handler()'s is_external
argument. In a multi-queue block layer world the aio_disable_exter
Each vhost-user-blk request runs in a coroutine. When the BlockBackend
enters a drained section we need to enter a quiescent state. Currently
any in-flight requests race with bdrv_drained_begin() because it is
unaware of vhost-user-blk requests.
When blk_co_preadv/pwritev()/etc returns it wakes th
Update the help text of the CONFIG_DEBUG_INFO option to be a little
bit more specific.
Signed-off-by: Juergen Gross
---
V2:
- expand help text, especially mentioning INSTALL_EFI_STRIP
(Jan Beulich)
---
xen/Kconfig.debug | 10 --
1 file changed, 8 insertions(+), 2 deletions(-)
diff --g
In order to support hypervisor analysis of crash dumps, xen-syms needs
to contain debug_info. It should be allowed to configure the hypervisor
to be built with CONFIG_DEBUG_INFO in non-debug builds without having
to enable EXPERT.
Using a rather oldish gcc (7.5) it was verified that code generatio
Enabling crash dump analysis of the hypervisor requires the hypervisor
having been built with CONFIG_DEBUG_INFO enabled. Today this requires
either CONFIG_DEBUG or CONFIG_EXPERT set, which are both not security
supported.
This small series changes that in order to allow security supported
Xen buil
On 03.04.2023 17:38, Roger Pau Monné wrote:
> On Mon, Apr 03, 2023 at 05:32:39PM +0200, Jan Beulich wrote:
>> On 03.04.2023 12:14, Roger Pau Monne wrote:
>>> Global p2m type recalculations (as triggered by logdirty) can create
>>> so much contention on the p2m lock that simple guest operations like
On Mon, Apr 03, 2023 at 05:30:37PM +0200, Jan Beulich wrote:
> On 03.04.2023 16:27, Roger Pau Monné wrote:
> > On Mon, Apr 03, 2023 at 02:39:08PM +0200, Jan Beulich wrote:
> >> On 03.04.2023 12:14, Roger Pau Monne wrote:
> >>> --- a/xen/arch/x86/mm/p2m-pt.c
> >>> +++ b/xen/arch/x86/mm/p2m-pt.c
> >>
On Mon, Apr 03, 2023 at 05:32:39PM +0200, Jan Beulich wrote:
> On 03.04.2023 12:14, Roger Pau Monne wrote:
> > Global p2m type recalculations (as triggered by logdirty) can create
> > so much contention on the p2m lock that simple guest operations like
> > VCPUOP_set_singleshot_timer on guests with
On 03.04.2023 12:14, Roger Pau Monne wrote:
> Global p2m type recalculations (as triggered by logdirty) can create
> so much contention on the p2m lock that simple guest operations like
> VCPUOP_set_singleshot_timer on guests with a high amount of vCPUs (32)
> will cease to work in a timely manner,
On 03.04.2023 16:27, Roger Pau Monné wrote:
> On Mon, Apr 03, 2023 at 02:39:08PM +0200, Jan Beulich wrote:
>> On 03.04.2023 12:14, Roger Pau Monne wrote:
>>> --- a/xen/arch/x86/mm/p2m-pt.c
>>> +++ b/xen/arch/x86/mm/p2m-pt.c
>>> @@ -486,9 +486,6 @@ static int cf_check do_recalc(struct p2m_domain *p2
Naming of some of the builtins isn't fully consistent with that of pre-
existing ones, so there's a need for a new BR2() wrapper macro.
With the tests providing some proof of proper functioning of the
emulator code also enable use of the feature by guests, as there's no
other infrastructure involv
Signed-off-by: Jan Beulich
--- a/tools/tests/x86_emulator/evex-disp8.c
+++ b/tools/tests/x86_emulator/evex-disp8.c
@@ -612,18 +612,36 @@ static const struct test avx512_fp16_all
INSN(cmpph, , 0f3a, c2,vl, fp16, vl),
INSN(cmpsh, f3, 0f3a, c2,el, fp16, el),
Signed-off-by: Jan Beulich
Acked-by: Andrew Cooper
--- a/tools/tests/x86_emulator/evex-disp8.c
+++ b/tools/tests/x86_emulator/evex-disp8.c
@@ -612,8 +612,16 @@ static const struct test avx512_fp16_all
INSN(cmpph, , 0f3a, c2,vl, fp16, vl),
INSN(cmpsh, f3, 0f3a, c2,
These are easiest in that they have same-size source and destination
vectors, yet they're different from other conversion insns in that they
use opcodes which have different meaning in the 0F encoding space
({,V}H{ADD,SUB}P{S,D}), hence requiring a little bit of overriding.
Signed-off-by: Jan Beul
Aspects to consider are that these have 32-bit element size (pairs of
FP16) and that there are restrictions on the registers valid to use.
Signed-off-by: Jan Beulich
Acked-by: Andrew Cooper
--- a/tools/tests/x86_emulator/evex-disp8.c
+++ b/tools/tests/x86_emulator/evex-disp8.c
@@ -614,12 +614,1
While, as before, this leverages that the Map6 encoding space is a very
sparse clone of the "0f38" one, switch around the simd_size overriding
for opcode 2D. This way fewer separate overrides are needed.
Signed-off-by: Jan Beulich
Acked-by: Andrew Cooper
--- a/tools/tests/x86_emulator/evex-disp
The Map6 encoding space is a very sparse clone of the "0f38" one. Once
again re-use that table, as the entries corresponding to invalid opcodes
in Map6 are simply benign with simd_size forced to other than simd_none
(preventing undue memory reads in SrcMem handling early in
x86_emulate()).
Signed-
Signed-off-by: Jan Beulich
--- a/tools/tests/x86_emulator/evex-disp8.c
+++ b/tools/tests/x86_emulator/evex-disp8.c
@@ -622,6 +622,8 @@ static const struct test avx512_fp16_all
INSN(maxsh, f3, map5, 5f,el, fp16, el),
INSN(minph, , map5, 5d,vl, fp16, vl),
IN
This encoding space is a very sparse clone of the "twobyte" one. Re-use
that table, as the entries corresponding to invalid opcodes in Map5 are
simply benign with simd_size forced to other than simd_none (preventing
undue memory reads in SrcMem handling early in x86_emulate()).
Signed-off-by: Jan
In order to re-use (also in subsequent patches) existing code and tables
as much as possible, simply introduce a new boolean field in emulator
state indicating whether an insn is one with a half-precision source.
Everything else then follows "naturally".
Signed-off-by: Jan Beulich
---
SDE: -spr o
While I (quite obviously) don't have any suitable hardware, Intel's
SDE allows testing the implementation. And since there's no new
state (registers) associated with this ISA extension, this should
suffice for integration.
01: handle AVX512-FP16 insns encoded in 0f3a opcode map
02: handle AVX512-F
flight 180119 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/180119/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-libvirt 15 migrate-support-checkfail never pass
test-arm64-arm64-xl-xsm 1
On Mon, Apr 03, 2023 at 02:39:08PM +0200, Jan Beulich wrote:
> On 03.04.2023 12:14, Roger Pau Monne wrote:
> > --- a/xen/arch/x86/mm/p2m-pt.c
> > +++ b/xen/arch/x86/mm/p2m-pt.c
> > @@ -486,9 +486,6 @@ static int cf_check do_recalc(struct p2m_domain *p2m,
> > unsigned long gfn)
> > p2m_typ
On Wed, Mar 29, 2023 at 10:29 PM Johnson, Ethan
wrote:
>
> On 2023-03-16 02:14:18 +, Andrew Cooper wrote:
> > Ok, so there is a lot here. Apologies in advance for the overly long
> > answer.
> >
> > First, while altp2m was developed in parallel with EPTP-switching, we
> > took care to split t
On Mon, Apr 03, 2023 at 11:16:52AM +0100, Andrew Cooper wrote:
> On 03/04/2023 9:57 am, Roger Pau Monné wrote:
> > On Fri, Mar 31, 2023 at 06:57:19PM +0100, Andrew Cooper wrote:
> >> This started by noticing the dubious Fam17h check in
> >> arch_ioreq_server_get_type_addr(), and then realising that
On 31.03.2023 19:57, Andrew Cooper wrote:
> This started by noticing the dubious Fam17h check in
> arch_ioreq_server_get_type_addr(), and then realising that checking the host
> CF8_EXT setting is utterly bogus for the guest <-> qemu emulation path.
>
> What should be consulted here is the guest's
flight 180116 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/180116/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-xl-qemut-win7-amd64 19 guest-stopfail like 180113
test-amd64-amd64-xl-qemuu-win7-amd64
flight 180117 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/180117/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64 6 xen-buildfail REGR. vs. 180085
Tests which
On 30/03/2023 22:27, Julien Grall wrote:
CAUTION: This message has originated from an External Source. Please
use proper judgment and caution when opening attachments, clicking
links, or responding to this email.
Hi Ayan,
Hi Julien,
On 21/03/2023 14:03, Ayan Kumar Halder wrote:
Refer AR
On 03.04.2023 12:14, Roger Pau Monne wrote:
> --- a/xen/arch/x86/mm/p2m-pt.c
> +++ b/xen/arch/x86/mm/p2m-pt.c
> @@ -486,9 +486,6 @@ static int cf_check do_recalc(struct p2m_domain *p2m,
> unsigned long gfn)
> p2m_type_t ot, nt;
> unsigned long mask = ~0UL << (level * PAGETABLE_OR
On 03.04.2023 14:25, Andrew Cooper wrote:
> Trying to build the test harness fails with:
>
> x86_emulate/blk.c: In function 'x86_emul_blk':
> x86_emulate/blk.c:74:15: error: expected ':' or ')' before 'ASM_FLAG_OUT'
> 74 | ASM_FLAG_OUT(, "; setz %[zf]")
> |
On Mon, Apr 3, 2023 at 5:33 AM Anthony PERARD wrote:
>
> On Sat, Apr 01, 2023 at 10:36:45PM +, Bernhard Beschow wrote:
> >
> >
> > Am 30. März 2023 13:00:25 UTC schrieb Anthony PERARD
> > :
> > >On Sun, Mar 12, 2023 at 01:02:17PM +0100, Bernhard Beschow wrote:
> > >> This is a preparational p
Trying to build the test harness fails with:
x86_emulate/blk.c: In function 'x86_emul_blk':
x86_emulate/blk.c:74:15: error: expected ':' or ')' before 'ASM_FLAG_OUT'
74 | ASM_FLAG_OUT(, "; setz %[zf]")
| ^~~~
This is because ASM_FLAG_OUT() is s
On 03.04.2023 13:44, Roger Pau Monné wrote:
> On Mon, Apr 03, 2023 at 01:26:41PM +0200, Jan Beulich wrote:
>> On 03.04.2023 13:09, Roger Pau Monné wrote:
>>> On Thu, Mar 30, 2023 at 12:40:38PM +0200, Jan Beulich wrote:
+bool is_cmos_port(unsigned int port, unsigned int bytes, const struct
>>>
On 03/04/2023 12:47 pm, Roger Pau Monné wrote:
> On Mon, Apr 03, 2023 at 11:55:57AM +0100, Andrew Cooper wrote:
>> On 30/03/2023 3:43 pm, Roger Pau Monné wrote:
>>> On Thu, Mar 30, 2023 at 01:59:37PM +0100, Andrew Cooper wrote:
On 30/03/2023 12:07 pm, Roger Pau Monné wrote:
> On Wed, Mar 2
On Mon, Apr 03, 2023 at 11:55:57AM +0100, Andrew Cooper wrote:
> On 30/03/2023 3:43 pm, Roger Pau Monné wrote:
> > On Thu, Mar 30, 2023 at 01:59:37PM +0100, Andrew Cooper wrote:
> >> On 30/03/2023 12:07 pm, Roger Pau Monné wrote:
> >>> On Wed, Mar 29, 2023 at 09:51:28PM +0100, Andrew Cooper wrote:
On Mon, Apr 03, 2023 at 01:26:41PM +0200, Jan Beulich wrote:
> On 03.04.2023 13:09, Roger Pau Monné wrote:
> > On Thu, Mar 30, 2023 at 12:40:38PM +0200, Jan Beulich wrote:
> >> ... in order to also intercept Dom0 accesses through the alias ports.
> >>
> >> Also stop intercepting accesses to the CMO
On 03.04.2023 13:09, Roger Pau Monné wrote:
> On Thu, Mar 30, 2023 at 12:40:38PM +0200, Jan Beulich wrote:
>> ... in order to also intercept Dom0 accesses through the alias ports.
>>
>> Also stop intercepting accesses to the CMOS ports if we won't ourselves
>> use the CMOS RTC, because of there bei
On 03.04.2023 06:21, Marek Marczykowski-Górecki wrote:
> On Tue, Mar 28, 2023 at 03:03:17PM +0200, Jan Beulich wrote:
>> On 28.03.2023 14:52, Marek Marczykowski-Górecki wrote:
>>> I mean, technically I can probably merge those two handlers together,
>>> but I don't think it will result in nicer cod
On Thu, Mar 30, 2023 at 12:40:38PM +0200, Jan Beulich wrote:
> ... in order to also intercept Dom0 accesses through the alias ports.
>
> Also stop intercepting accesses to the CMOS ports if we won't ourselves
> use the CMOS RTC, because of there being none.
So it's fine for dom0 to switch off NMI
On 31.03.2023 09:37, Roger Pau Monné wrote:
> On Fri, Mar 31, 2023 at 08:51:46AM +0200, Jan Beulich wrote:
>> On 30.03.2023 18:17, Roger Pau Monné wrote:
>>> On Thu, Mar 30, 2023 at 06:07:57PM +0200, Jan Beulich wrote:
On 30.03.2023 17:44, Roger Pau Monné wrote:
> I guess I'm slightly conf
On 30/03/2023 3:43 pm, Roger Pau Monné wrote:
> On Thu, Mar 30, 2023 at 01:59:37PM +0100, Andrew Cooper wrote:
>> On 30/03/2023 12:07 pm, Roger Pau Monné wrote:
>>> On Wed, Mar 29, 2023 at 09:51:28PM +0100, Andrew Cooper wrote:
tl;dr to add MSR_ARCH_CAPS features sensibly, cpu_{featureset<->po
On 03/04/2023 9:57 am, Roger Pau Monné wrote:
> On Fri, Mar 31, 2023 at 06:57:19PM +0100, Andrew Cooper wrote:
>> This started by noticing the dubious Fam17h check in
>> arch_ioreq_server_get_type_addr(), and then realising that checking the host
>> CF8_EXT setting is utterly bogus for the guest <-
Global p2m type recalculations (as triggered by logdirty) can create
so much contention on the p2m lock that simple guest operations like
VCPUOP_set_singleshot_timer on guests with a high amount of vCPUs (32)
will cease to work in a timely manner, up to the point that Linux
kernel versions that sil
On Sat, Apr 01, 2023 at 10:36:45PM +, Bernhard Beschow wrote:
>
>
> Am 30. März 2023 13:00:25 UTC schrieb Anthony PERARD
> :
> >On Sun, Mar 12, 2023 at 01:02:17PM +0100, Bernhard Beschow wrote:
> >> This is a preparational patch for the next one to make the following
> >> more obvious:
> >>
bind_evtchn_to_irqhandler() shouldn't be called under spinlock, as it
can sleep.
This requires to move the calls of create_active() out of the locked
regions. This is no problem, as the worst which could happen would be
a spurious call of the interrupt handler, causing a spurious wake_up().
Repor
flight 180115 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/180115/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
test-amd64-i386-xl-qemut-debianhvm-amd64 20 guest-start/debianhvm.repeat fail
pass in 180110
test-amd64-i386-x
On Fri, Mar 31, 2023 at 06:57:19PM +0100, Andrew Cooper wrote:
> This started by noticing the dubious Fam17h check in
> arch_ioreq_server_get_type_addr(), and then realising that checking the host
> CF8_EXT setting is utterly bogus for the guest <-> qemu emulation path.
>
> What should be consulte
Am 1. April 2023 22:36:45 UTC schrieb Bernhard Beschow :
>
>
>Am 30. März 2023 13:00:25 UTC schrieb Anthony PERARD
>:
>>On Sun, Mar 12, 2023 at 01:02:17PM +0100, Bernhard Beschow wrote:
>>> This is a preparational patch for the next one to make the following
>>> more obvious:
>>>
>>> First, pc
During the last patches, TYPE_PIIX3_XEN_DEVICE turned into a clone of
TYPE_PIIX3_DEVICE. Remove this redundancy.
Signed-off-by: Bernhard Beschow
Reviewed-by: Michael S. Tsirkin
Reviewed-by: Anthony PERARD
Tested-by: Chuck Zmudzinski
Message-Id: <20230312120221.99183-7-shen...@gmail.com>
---
i
The previous patch unified handling of piix3_write_config() accross the
PIIX3 device models which allows for assigning k->config_write once in the
base class.
Signed-off-by: Bernhard Beschow
Reviewed-by: Michael S. Tsirkin
Reviewed-by: Anthony PERARD
Tested-by: Chuck Zmudzinski
Message-Id: <20
xen_intx_set_irq() doesn't depend on PIIX3State. In order to resolve
TYPE_PIIX3_XEN_DEVICE and in order to make Xen agnostic about the
precise south bridge being used, set up Xen's PCI IRQ handling of PIIX3
in the board.
Signed-off-by: Bernhard Beschow
Reviewed-by: Michael S. Tsirkin
Reviewed-by
Subscribe to pci_bus_fire_intx_routing_notifier() instead which allows for
having a common piix3_write_config() for the PIIX3 device models.
While at it, move the subscription into machine code to facilitate resolving
TYPE_PIIX3_XEN_DEVICE.
In a possible future followup, pci_bus_fire_intx_routing
This is a preparational patch for the next one to make the following
more obvious:
First, pci_bus_irqs() is now called twice in case of Xen where the
second call overrides the pci_set_irq_fn with the Xen variant.
Second, pci_bus_set_route_irq_fn() is now also called in Xen mode.
Signed-off-by: B
There is currently a dedicated PIIX3 device model for use under Xen. By reusing
existing PCI API during initialization this device model can be eliminated and
the plain PIIX3 device model can be used instead.
Resolving TYPE_PIIX3_XEN_DEVICE results in less code while also making Xen
agnostic towar
When calling pci_bus_irqs() multiple times on the same object without calling
pci_bus_irqs_cleanup() in between PCIBus::irq_count[] is currently leaked.
Let's fix this because Xen will do just that in a few commits, and because
calling pci_bus_irqs_cleanup() in between seems fragile and cumbersome.
xen_piix3_set_irq() isn't PIIX specific: PIIX is a single PCI device
while xen_piix3_set_irq() maps multiple PCI devices to their respective
IRQs, which is board-specific. Rename xen_piix3_set_irq() to communicate
this.
Also rename XEN_PIIX_NUM_PIRQS to XEN_IOAPIC_NUM_PIRQS since the Xen's
IOAPIC
82 matches
Mail list logo
