On 04.02.2025 09:19, Juergen Gross wrote:
> On 03.02.25 23:43, Stefano Stabellini wrote:
>> +Xen maintainers
>>
>>
>> On Mon, 3 Feb 2025, Richard Henderson wrote:
>>> On 2/3/25 04:54, Paolo Bonzini wrote:
On 2/3/25 04:18, Richard Henderson wrote:
> v1: 20250128004254.33442-1-richard.hender
On 09.11.2023 18:40, Thomas Huth wrote:
> --- a/include/hw/xen/interface/hvm/params.h
> +++ b/include/hw/xen/interface/hvm/params.h
> @@ -255,7 +255,7 @@
> * Note that 'mixed' mode has not been evaluated for safety from a
> * security perspective. Before using this mode in a
> * security-cri
On 17.11.2022 04:34, Marek Marczykowski-Górecki wrote:
> Ok, I found what is wrong. Enabling MSI-X is refused, because INTx isn't
> disabled at this point yet. And apparently I was testing this with
> permissive=1...
>
> Linux does this:
> https://github.com/torvalds/linux/blob/master/drivers/pci/
On 15.11.2022 12:38, Marek Marczykowski-Górecki wrote:
> On Tue, Nov 15, 2022 at 09:14:07AM +0100, Jan Beulich wrote:
>> On 14.11.2022 20:20, Marek Marczykowski-Górecki wrote:
>>> The /dev/mem is used for two purposes:
>>> - reading PCI_MSIX_ENTRY_CTRL_MASKBIT
>&
On 14.11.2022 20:20, Marek Marczykowski-Górecki wrote:
> The /dev/mem is used for two purposes:
> - reading PCI_MSIX_ENTRY_CTRL_MASKBIT
> - reading Pending Bit Array (PBA)
>
> The first one was originally done because when Xen did not send all
> vector ctrl writes to the device model, so QEMU mi
On 17.10.2022 10:12, Arthur Borsboom wrote:
> Xen 4.16.1, 4.16.2 and 4.17.0-rc1 don't build anymore in Arch Linux.
That is, qemu doesn't build. That's something to be taken care of there,
not in Xen, I think.
Jan
> I believe it is caused by the missing function
> bpf_program__set_socket_filter p
On 14.02.2022 16:02, Dario Faggioli wrote:
> We have run into an issue when trying to use PCI passthrough for a Xen
> VM running on an host where dom0 kernel is 5.14.21 (but we think it
> could be any kernel > 5.4) and SecureBoot is enabled.
>
> The error we get, when (for instance) trying to atta
On 29.08.2019 11:02, Chao Gao wrote:
> Currently, for a HVM on Xen, no reset method is virtualized. So in a VM's
> perspective, assigned devices cannot be reset. But some devices rely on PCI
> reset to recover from hardware hangs. When being assigned to a VM, those
> devices cannot be reset and won
>>> On 23.11.18 at 11:19, wrote:
> Adding Jan in case he has an opinion on my reply below.
I agree, fwiw.
Jan
> On Fri, Nov 23, 2018 at 12:04:51AM -0500, Zhao Yan wrote:
>> On Thu, Nov 22, 2018 at 03:18:05PM +0100, Roger Pau Monné wrote:
>> > On Thu, Nov 22, 2018 at 08:11:20AM -0500, Zhao Yan w
>>> On 18.05.18 at 15:51, wrote:
>> Sent: 18 May 2018 14:34
>> To: Paul Durrant
>> >>> On 18.05.18 at 15:00, wrote:
>> > +QLIST_FOREACH(xendev, &state->dev_list, entry) {
>> > +unsigned int i;
>> > +uint32_t tmp;
>> > +
>> > +if (xendev->sbdf != sbdf) {
>> > +
>>> On 18.05.18 at 15:00, wrote:
> @@ -903,6 +926,80 @@ static void cpu_ioreq_move(ioreq_t *req)
> }
> }
>
> +static void rw_config_req_item(XenPciDevice *xendev, ioreq_t *req,
It looks to me as if both parameters could be constified.
> + uint32_t i, uint32_
sed's -E option may not be supported by older distros. As there's no
point using sed here at all, use just shell mechanisms to establish the
variable values, starting from the stem instead of the full target.
Signed-off-by: Jan Beulich
--- a/Makefile
+++ b/Makefile
@@ -24
>>> On 13.10.17 at 13:13, wrote:
> To Jan, Andrew, Stefano and Anthony,
>
> what do you think about allowing QEMU to build the entire guest ACPI
> and letting SeaBIOS to load it? ACPI builder code in hvmloader is
> still there and just bypassed in this case.
Well, if that can be made work in a n
>>> On 03.10.17 at 02:12, wrote:
> On Thu, Sep 28, 2017 at 10:12:34AM -0300, Eduardo Habkost wrote:
>> On Thu, Sep 28, 2017 at 02:33:57AM -0600, Jan Beulich wrote:
>> > >>> On 27.09.17 at 21:56, wrote:
>> > > --- a/hw/xen/xen_pt.c
>> > &
>>> On 27.09.17 at 21:56, wrote:
> --- a/hw/xen/xen_pt.c
> +++ b/hw/xen/xen_pt.c
> @@ -964,6 +964,10 @@ static const TypeInfo xen_pci_passthrough_info = {
> .instance_size = sizeof(XenPCIPassthroughState),
> .instance_finalize = xen_pci_passthrough_finalize,
> .class_init = xen_pci_
>>> On 21.09.17 at 03:12, wrote:
> On Fri, 1 Sep 2017, Jan Beulich wrote:
>> --- a/hw/xen/xen_pt_msi.c
>> +++ b/hw/xen/xen_pt_msi.c
>> @@ -18,6 +18,11 @@
>>
>> #define XEN_PT_AUTO_ASSIGN -1
>>
>> +#ifndef XEN_DOMCTL_VMSI_X86_DEST_ID_M
Prefer g_new() / g_new0() to be farther backwards compatible with older
glib versions. As there's no point in zeroing the allocation here (the
loop right afterwards fully initializes the memory), use the former.
Signed-off-by: Jan Beulich
--- a/hw/block/xen_disk.c
+++ b/hw/block/xen_d
>>> On 04.09.17 at 11:23, wrote:
> On Mon, Sep 04, 2017 at 03:04:41AM -0600, Jan Beulich wrote:
>> >>> On 01.09.17 at 20:20, wrote:
>> > On Fri, Sep 01, 2017 at 10:25:42AM -0600, Jan Beulich wrote:
>> >> Xen and qemu having identical #define-s (w
>>> On 01.09.17 at 20:20, wrote:
> On Fri, Sep 01, 2017 at 10:25:42AM -0600, Jan Beulich wrote:
>> Xen and qemu having identical #define-s (with different names) is a
>> strong hint that these should have been part of the public interface
>> from the very start.
Xen and qemu having identical #define-s (with different names) is a
strong hint that these should have been part of the public interface
from the very start. Use them if they're available, falling back to
privately defined values only when using older headers.
Signed-off-by: Jan Beulich
gt; Signed-off-by: Roger Pau Monné
> Reported-by: Andreas Kinzler
Reviewed-by: Jan Beulich
>>> On 24.08.17 at 12:06, wrote:
> On Thu, Aug 24, 2017 at 03:54:21AM -0600, Jan Beulich wrote:
>> >>> On 24.08.17 at 11:47, wrote:
>> > @@ -274,7 +278,7 @@ int xen_pt_msi_update(XenPCIPassthroughState *s)
>> > {
>> > XenPTMSI *msi =
>>> On 24.08.17 at 11:47, wrote:
> @@ -274,7 +278,7 @@ int xen_pt_msi_update(XenPCIPassthroughState *s)
> {
> XenPTMSI *msi = s->msi;
> return msi_msix_update(s, msi_addr64(msi), msi->data, msi->pirq,
> - false, 0, &msi->pirq);
> + fal
>>> Stefano Stabellini 06/23/17 8:43 PM >>>
>On Fri, 23 Jun 2017, Jan Beulich wrote:
>> >>> On 22.06.17 at 20:52, wrote:
>> > I am happy to write the code and/or the commit message. Would a simple
>> > cast like below work to fix the securi
>>> On 22.06.17 at 20:52, wrote:
> On Thu, 22 Jun 2017, Jan Beulich wrote:
>> >>> On 21.06.17 at 20:46, wrote:
>> > On Wed, 21 Jun 2017, Jan Beulich wrote:
>> >> >>> On 20.06.17 at 23:48, wrote:
>> >> > On
>>> On 21.06.17 at 20:46, wrote:
> On Wed, 21 Jun 2017, Jan Beulich wrote:
>> >>> On 20.06.17 at 23:48, wrote:
>> > On Tue, 20 Jun 2017, Jan Beulich wrote:
>> >> @@ -36,13 +33,7 @@ struct blkif_x86_32_request_discard {
>> >> blkif
>>> On 20.06.17 at 23:48, wrote:
> On Tue, 20 Jun 2017, Jan Beulich wrote:
>> @@ -36,13 +33,7 @@ struct blkif_x86_32_request_discard {
>> blkif_sector_t sector_number;/* start sector idx on disk (r/w only)
>> */
>> uint64_t nr_sectors;
by: Anthony Perard
Signed-off-by: Jan Beulich
Reviewed-by: Konrad Rzeszutek Wilk
Acked-by: Anthony PERARD
---
v2: Add QEMU_PACKED to fix handling 32-bit guests by 64-bit qemu.
--- a/hw/block/xen_blkif.h
+++ b/hw/block/xen_blkif.h
@@ -14,9 +14,6 @@
struct blkif_common_request {
char dummy
>>> On 19.05.17 at 13:16, wrote:
> On Thu, May 18, 2017 at 01:32:59AM -0400, Lan Tianyu wrote:
>> --- a/include/hw/i386/apic-msidef.h
>> +++ b/include/hw/i386/apic-msidef.h
>> @@ -26,6 +26,7 @@
>>
>> #define MSI_ADDR_DEST_ID_SHIFT 12
>> #define MSI_ADDR_DEST_IDX_SHIFT 4
>> -#d
There's no way to communicate back read data, so only writes can ever
be usefully specified. Ignore the field, paving the road for eventually
re-using the bit for something else in a few (many?) years time.
Signed-off-by: Jan Beulich
Reviewed-by: Paul Durrant
Acked-by: Stefano Stabe
n unsigned long calculation of size when the field to
be initialized is only 32 bits wide (and the shift value in the range
0...3).
Signed-off-by: Jan Beulich
Reviewed-by: Paul Durrant
--- a/xen-hvm.c
+++ b/xen-hvm.c
@@ -995,6 +995,8 @@ static int handle_buffered_iopage(XenIOS
}
m
eported-by: yanghongke
Signed-off-by: Jan Beulich
---
v2: Bail (using hw_error()) instead of just breaking the loop.
--- a/xen-hvm.c
+++ b/xen-hvm.c
@@ -1021,6 +1021,9 @@ static int handle_buffered_iopage(XenIOS
xen_rmb();
qw = (req.size == 8);
if (qw) {
+if (rdptr +
1: fix quad word bufioreq handling
2: slightly simplify bufioreq handling
3: ignore direction in bufioreq handling
Signed-off-by: Jan Beulich
---
v2: Only patch 1 changed; see there.
>>> On 23.11.16 at 19:13, wrote:
> On Wed, 23 Nov 2016, Jan Beulich wrote:
>> There's no point setting fields always receiving the same value on each
>> iteration, as handle_ioreq() doesn't alter them anyway. Set state and
>> count once ahead of
>>> On 23.11.16 at 11:45, wrote:
> No, if QEMU is using a default ioreq server (i.e. the legacy way of doing
> things) then it's vulnerable to the guest messing with the rings and I'd
> forgotten that migrated-in guests from old QEMUs also end up using the
> default
> server, so I guess this i
>>> On 23.11.16 at 10:48, wrote:
>> From: Jan Beulich [mailto:jbeul...@suse.com]
>> Sent: 23 November 2016 09:24
>>
>> We should not consume the second slot if it didn't get written yet.
>> Normal writers - i.e. Xen - would not update write_pointer bet
There's no way to communicate back read data, so only writes can ever
be usefully specified. Ignore the field, paving the road for eventually
re-using the bit for something else in a few (many?) years time.
Signed-off-by: Jan Beulich
--- a/xen-hvm.c
+++ b/xen-hvm.c
@@ -997,6 +997,7 @@ s
n unsigned long calculation of size when the field to
be initialized is only 32 bits wide (and the shift value in the range
0...3).
Signed-off-by: Jan Beulich
--- a/xen-hvm.c
+++ b/xen-hvm.c
@@ -995,6 +995,8 @@ static int handle_buffered_iopage(XenIOS
}
memset(&req, 0x
yanghongke
Signed-off-by: Jan Beulich
---
TBD: Alternatively we could call e.g. hw_error() instead.
--- a/xen-hvm.c
+++ b/xen-hvm.c
@@ -1021,6 +1021,9 @@ static int handle_buffered_iopage(XenIOS
xen_rmb();
qw = (req.size == 8);
if (qw) {
+if (rdptr +
1: fix quad word bufioreq handling
2: slightly simplify bufioreq handling
3: ignore direction in bufioreq handling
Signed-off-by: Jan Beulich
Avoid double fetches and bounds check size to avoid overflowing
internal variables.
This is CVE-2016-9381 / XSA-197.
Reported-by: yanghongke
Signed-off-by: Jan Beulich
Reviewed-by: Stefano Stabellini
--- a/xen-hvm.c
+++ b/xen-hvm.c
@@ -810,6 +810,10 @@ static void cpu_ioreq_pio(ioreq_t *req
>>> On 17.06.16 at 12:08, wrote:
> On 17/06/16 11:50, Paul Durrant wrote:
>>> -Original Message-
>>> From: Juergen Gross [mailto:jgr...@suse.com]
>>> Sent: 17 June 2016 10:46
>>> To: Paul Durrant; Jan Beulich
>>> Cc: Anthon
>>> On 17.06.16 at 11:31, wrote:
> On 17/06/16 11:26, Jan Beulich wrote:
>>>>> On 17.06.16 at 11:14, wrote:
>>> In case the word size of the domU and qemu running the qdisk backend
>>> differ BLKIF_OP_DISCARD will not work reliably, as the request
>
>>> On 17.06.16 at 11:14, wrote:
> In case the word size of the domU and qemu running the qdisk backend
> differ BLKIF_OP_DISCARD will not work reliably, as the request
> structure in the ring have different layouts for different word size.
>
> Correct this by copying the request structure in cas
>>> On 16.06.16 at 13:04, wrote:
> On 16/06/16 12:54, Jan Beulich wrote:
>>>>> On 16.06.16 at 12:02, wrote:
>>> In case the word size of the domU and qemu running the qdisk backend
>>> differ BLKIF_OP_DISCARD will not work reliably, as the request
>
the request structure in case of different
> word size element by element in the BLKIF_OP_DISCARD case, too.
>
> Signed-off-by: Juergen Gross
With the indentation (tabs vs blanks) fixed
Reviewed-by: Jan Beulich
And maybe ...
> @@ -82,7 +98,7 @@ static inline void blkif_ge
>>> On 13.06.16 at 12:54, wrote:
> The following changes since commit a93c1bdf0bd4689287094ddb2aae3dc907da3535:
>
> Merge remote-tracking branch 'remotes/kraxel/tags/pull-ui-20160610-1' into
> staging (2016-06-10 15:47:17 +0100)
>
> are available in the git repository at:
>
>
> git://xenb
mething vulnerable is very unlikely (and not
observed in practice), this isn't being viewed as a new security issue.
Signed-off-by: Jan Beulich
--- a/hw/block/xen_blkif.h
+++ b/hw/block/xen_blkif.h
@@ -79,14 +79,14 @@ static inline void blkif_get_x86_32_req(
dst->handle = src-
>>> On 11.12.15 at 17:56, wrote:
> For the original issue here, could the flag be exposed as a
> XEN_SYSCTL_PHYSCAP_
Yes, I think it could, albeit calling this a "capability" or "feature"
seems odd (since really the original behavior was bogus/buggy).
But - with sysctl not being a stable inte
>>> On 11.12.15 at 17:56, wrote:
> On Fri, 2015-12-11 at 16:44 +, Stefano Stabellini wrote:
>>
>> It is not possible to do this at runtime. I think we should do this at
>> compile time because in any case it is not supported to run a QEMU built
>> for a given Xen version on a different Xen v
>>> On 11.12.15 at 15:33, wrote:
> On Mon, 7 Dec 2015, Jan Beulich wrote:
>> >>> On 07.12.15 at 15:56, wrote:
>> > On Mon, 7 Dec 2015, Jan Beulich wrote:
>> >> >>> On 07.12.15 at 13:45, wrote:
>> >> > On Tue, 24 Nov 2015, J
>>> On 09.12.15 at 16:55, wrote:
> On Tue, 8 Dec 2015, Jan Beulich wrote:
>> The remaining log message in pci_msix_write() is wrong, as there guest
>> behavior may only appear to be wrong: For one, the old logic didn't
>> take the mask-all bit into account
aving done so). Plus these writes shouldn't be dropped even when
an entry gets unmasked. Instead, if they can't be made take effect
right away, they should take effect on the next unmasking or enabling
operation - the specification explicitly describes such caching
behavior.
Signed-off-by:
>>> On 07.12.15 at 13:41, wrote:
> I know that in your opinion is superfluous, nonetheless could you please
> add 2-3 lines of in-code comment right here, to explain what you are
> doing with the check? Something like:
>
> /*
> * Update the entry addr and data to the latest values only when the
>>> On 07.12.15 at 13:41, wrote:
> On Tue, 24 Nov 2015, Jan Beulich wrote:
>> @@ -332,6 +334,13 @@ static int xen_pt_msix_update_one(XenPCI
>>
>> pirq = entry->pirq;
>
> I know that in your opinion is superfluous, nonetheless could you please
> a
>>> On 07.12.15 at 15:56, wrote:
> On Mon, 7 Dec 2015, Jan Beulich wrote:
>> >>> On 07.12.15 at 13:45, wrote:
>> > On Tue, 24 Nov 2015, Jan Beulich wrote:
>> >> Now that the hypervisor intercepts all config space writes and monitors
>> >&g
>>> On 07.12.15 at 13:45, wrote:
> On Tue, 24 Nov 2015, Jan Beulich wrote:
>> Now that the hypervisor intercepts all config space writes and monitors
>> changes to the masking flags, this undoes the main effect of the
>> XSA-129 fix, exposing the masking capability
Now that the hypervisor intercepts all config space writes and monitors
changes to the masking flags, this undoes the main effect of the
XSA-129 fix, exposing the masking capability again to guests.
Signed-off-by: Jan Beulich
---
TBD: We probably need to deal with running on an older hypervisor
Introduce yet another mask for them, so that the generic routine can
handle them, at once rendering xen_pt_pmcsr_reg_write() superfluous.
Signed-off-by: Jan Beulich
--- a/hw/xen/xen_pt.h
+++ b/hw/xen/xen_pt.h
@@ -113,6 +113,8 @@ struct XenPTRegInfo {
uint32_t res_mask;
/* reg read
aving done so). Plus these writes shouldn't be dropped even when
an entry gets unmasked. Instead, if they can't be made take effect
right away, they should take effect on the next unmasking or enabling
operation - the specification explicitly describes such caching
behavior.
Signed-off-by:
The way the generic infrastructure works the intention of not allowing
unaligned accesses can't be achieved by simply setting .unaligned to
false. The benefit is that we can now replace the conditionals in
{get,set}_entry_value() by assert()-s.
Signed-off-by: Jan Beulich
Reviewed-by: St
1: MSI-X: latch MSI-X table writes
2: MSI-X: really enforce alignment
3: pass-through: correctly deal with RW1C bits
4: [RFC] MSI: re-expose masking capability
Signed-off-by: Jan Beulich
>>> Tue, 16 Jun 2015 15:48:16 +0100 Stefano Stabellini wrote:
>On Tue, 16 Jun 2015, Jan Beulich wrote:
>> >>> On 16.06.15 at 15:35, Stefano Stabellini wrote:
>> > On Fri, 5 Jun 2015, Jan Beulich wrote:
I'm sorry for getting back to this only no
>>> On 12.08.15 at 09:10, wrote:
>
>> -Original Message-
>> From: qemu-devel-bounces+feng.wu=intel@nongnu.org
>> [mailto:qemu-devel-bounces+feng.wu=intel....@nongnu.org] On Behalf Of
>> Jan Beulich
>> Sent: Wednesday, August 12,
>>> On 05.08.15 at 04:02, wrote:
> @@ -491,8 +474,9 @@ static int xen_pt_bar_reg_write(XenPCIPassthroughState
> *s, XenPTReg *cfg_entry,
> bar_ro_mask = XEN_PT_BAR_IO_RO_MASK | (r_size - 1);
> break;
> case XEN_PT_BAR_FLAG_UPPER:
> +r = &d->io_regions[index-1];
Per
eeded, allowing it to atomically canonicalize both pointers when
both have gone through at least one cycle.
The Xen side counterpart (which is not a functional prereq to this
change, albeit a build one) went in already (commit b7007bc6f9).
Signed-off-by: Jan Beulich
---
v3: Check for Xen 4.6 (configur
>>> On 23.07.15 at 12:04, wrote:
> On Thu, 23 Jul 2015, Jan Beulich wrote:
>> >>> On 22.07.15 at 19:24, wrote:
>> > I'll queue this change up for the next QEMU release cycle.
>>
>> Thanks - v2 (with the adjusted description) just sent.
>
>>> On 22.07.15 at 19:24, wrote:
> I'll queue this change up for the next QEMU release cycle.
Thanks - v2 (with the adjusted description) just sent.
It would however be nice for our variant in 4.6 to also gain this,
perhaps independent of upstream's schedule.
Jan
eeded, allowing it to atomically canonicalize both pointers when
both have gone through at least one cycle.
The Xen side counterpart (which is not a functional prereq to this
change, albeit a build one) went in already (commit b7007bc6f9).
Signed-off-by: Jan Beulich
---
v2: Adjust description.
---
>>> On 22.07.15 at 16:50, wrote:
> On Wed, 22 Jul 2015, Jan Beulich wrote:
>> >> --- a/xen-hvm.c
>> >> +++ b/xen-hvm.c
>> >> @@ -981,19 +981,30 @@ static void handle_ioreq(XenIOState *sta
>> >>
>> >> static int handle_
>>> On 21.07.15 at 15:54, wrote:
> On Thu, 18 Jun 2015, Jan Beulich wrote:
>> The number of slots per page being 511 (i.e. not a power of two) means
>> that the (32-bit) read and write indexes going beyond 2^32 will likely
>> disturb operation. The hypervisor sid
http://lists.xenproject.org/archives/html/xen-devel/2015-06/msg02996.html
Signed-off-by: Jan Beulich
--- a/xen-hvm.c
+++ b/xen-hvm.c
@@ -981,19 +981,30 @@ static void handle_ioreq(XenIOState *sta
static int handle_buffered_iopage(XenIOState *state)
{
+buffered_iopage_t *buf_page = state->buffered
>>> On 16.06.15 at 16:56, wrote:
> On Tue, 16 Jun 2015, Jan Beulich wrote:
>> >>> On 16.06.15 at 16:03, wrote:
>> > On Fri, 5 Jun 2015, Jan Beulich wrote:
>> >> --- a/qemu/upstream/hw/xen/xen_pt_msi.c
>> >> +++ b/qemu/upstre
>>> On 16.06.15 at 16:27, wrote:
> On Fri, 5 Jun 2015, Jan Beulich wrote:
>> This is done indirectly by adjusting two typedefs and helps emphasizing
>> that the respective tables aren't supposed to be modified at runtime
>> (as they may be shared between
>>> On 16.06.15 at 16:19, wrote:
> On Fri, 5 Jun 2015, Jan Beulich wrote:
>> @@ -1016,11 +1002,12 @@ static XenPTRegInfo xen_pt_emu_reg_pm[]
>> .size = 2,
>> .init_val = 0x0008,
>> .res_mask = 0x00F0,
>> -
>>> On 16.06.15 at 16:03, wrote:
> On Fri, 5 Jun 2015, Jan Beulich wrote:
>> +} else if (s->msix->enabled) {
>> +if (!(value & PCI_MSIX_FLAGS_ENABLE)) {
>> +xen_pt_msix_disable(s);
>> +s->msix->enabl
>>> On 16.06.15 at 15:35, wrote:
> On Fri, 5 Jun 2015, Jan Beulich wrote:
>> @@ -322,6 +323,13 @@ static int xen_pt_msix_update_one(XenPCI
>>
>> pirq = entry->pirq;
>>
>> +if (pirq == XEN_PT_UNASSIGNED_PIRQ || s->msix-&
>>> On 10.06.15 at 13:46, wrote:
> I don't really know. The idea would be that device
> is not designed for memory to be disabled when it's
> active, and starts behaving in broken ways.
But you recall that we know the origin of the offending write is in
the hypervisor, and we also know that the d
>>> On 10.06.15 at 13:43, wrote:
> On Wed, Jun 10, 2015 at 08:00:55AM +0100, Jan Beulich wrote:
>> >>> On 08.06.15 at 13:28, wrote:
>> > On Mon, Jun 08, 2015 at 11:55:22AM +0100, Jan Beulich wrote:
>> >> while function 0 has
>> >>
>
>>> On 08.06.15 at 11:30, wrote:
> What happens if you disable SERR# in the command register
> of 83:00.1?
We've just been told that with SERR not enabled in any of the
sibling endpoints the NMI still occurs. Not really surprising with
us now assuming that it's the root port that generates the SE
>>> On 08.06.15 at 13:28, wrote:
> On Mon, Jun 08, 2015 at 11:55:22AM +0100, Jan Beulich wrote:
>> while function 0 has
>>
>> 0x10: Base Address Register 0 = 0xca23000c (Memory space, 64-bit access,
>> prefetchable)
>> 0x18: Base Address Register 2
initializing the ROM BAR register field
description.
Signed-off-by: Jan Beulich
---
v2: Convert complex if() into simpler ones.
--- a/hw/xen/xen_pt.c
+++ b/hw/xen/xen_pt.c
@@ -249,10 +249,18 @@ static void xen_pt_pci_write_config(PCID
/* check unused BAR register */
index
>>> On 08.06.15 at 13:28, wrote:
> On Mon, Jun 08, 2015 at 11:55:22AM +0100, Jan Beulich wrote:
>> But you asking this made me look more closely at the
>> memory ranges dumped out to the ITP log: The root port has
>>
>> 0x20: Memory Base
>>> On 08.06.15 at 11:36, wrote:
> On Mon, Jun 08, 2015 at 10:03:18AM +0100, Jan Beulich wrote:
>> >>> On 08.06.15 at 10:09, wrote:
>> > I believe the correct behaviour is happening but a PCIE completion timeout
>> > is occurring instead of a
>
>>> On 08.06.15 at 11:30, wrote:
> On Mon, Jun 08, 2015 at 08:42:57AM +0100, Jan Beulich wrote:
>> Otoh the respective root port also has
>> - Received Master Abort set in its Secondary Status register (but
>> that's also already the case in the log that we
>>> On 08.06.15 at 10:09, wrote:
> On 08/06/15 08:42, Jan Beulich wrote:
>> Not really. All we concluded so far is that _maybe_ the bridge, upon
>> seeing the UR, generates a Master Abort, rendering the whole thing
>> fatal. Otoh the respective root port also has
>
>>> On 07.06.15 at 08:23, wrote:
> On Mon, Apr 20, 2015 at 04:32:12PM +0200, Michael S. Tsirkin wrote:
>> On Mon, Apr 20, 2015 at 03:08:09PM +0100, Jan Beulich wrote:
>> > >>> On 20.04.15 at 15:43, wrote:
>> > > On Mon, Apr 13, 2015 at 01:51:06PM +
>>> On 05.06.15 at 18:41, wrote:
> On Fri, 5 Jun 2015, Jan Beulich wrote:
>> >>> On 05.06.15 at 13:32, wrote:
>> >> --- a/hw/xen/xen_pt.c
>> >> +++ b/hw/xen/xen_pt.c
>> >> @@ -248,7 +248,9 @@ static void xen_pt_pci_wr
This is done indirectly by adjusting two typedefs and helps emphasizing
that the respective tables aren't supposed to be modified at runtime
(as they may be shared between devices).
Signed-off-by: Jan Beulich
--- a/qemu/upstream/hw/xen/xen_pt.h
+++ b/qemu/upstream/hw/xen/xen_pt.h
@@ -31,7
aving done so). Plus these writes shouldn't be dropped even when
an entry gets unmasked. Instead, if they can't be made take effect
right away, they should take effect on the next unmasking or enabling
operation - the specification explicitly describes such caching
behavior.
Signed-off-by:
Particularly the maskall bit has to be under exclusive hypervisor
control (and since they live in the same config space field, the
enable bit has to follow suit). Use the replacement hypercall
interfaces.
Signed-off-by: Jan Beulich
--- a/qemu/upstream/hw/xen/xen_pt.h
+++ b/qemu/upstream/hw/xen
Functions setting errno commonly return just -1, which is of no
particular use in the log file.
Signed-off-by: Jan Beulich
--- a/qemu/upstream/hw/xen/xen_pt.c
+++ b/qemu/upstream/hw/xen/xen_pt.c
@@ -609,8 +609,8 @@ static void xen_pt_region_update(XenPCIP
Introduce yet another mask for them, so that the generic routine can
handle them, at once rendering xen_pt_pmcsr_reg_write() superfluous.
Signed-off-by: Jan Beulich
--- a/qemu/upstream/hw/xen/xen_pt.h
+++ b/qemu/upstream/hw/xen/xen_pt.h
@@ -105,6 +105,8 @@ struct XenPTRegInfo {
uint32_t
The way the generic infrastructure works the intention of not allowing
unaligned accesses can't be achieved by simply setting .unaligned to
false. The benefit is that we can now replace the conditionals in
{get,set}_entry_value() by assert()-s.
Signed-off-by: Jan Beulich
--- a/qemu/upstre
-by: Jan Beulich
>>> On 05.06.15 at 13:32, wrote:
>> --- a/hw/xen/xen_pt.c
>> +++ b/hw/xen/xen_pt.c
>> @@ -248,7 +248,9 @@ static void xen_pt_pci_write_config(PCID
>>
>> /* check unused BAR register */
>> index = xen_pt_bar_offset_to_index(addr);
>> -if ((index >= 0) && (val > 0 && val < XEN_PT_BAR
ddress portion of the register.
>
> Use suitable constants also for initializing the ROM BAR register field
> description.
>
> Signed-off-by: Jan Beulich
>
> --- a/hw/xen/xen_pt.c
> +++ b/hw/xen/xen_pt.c
> @@ -248,7 +248,9 @@ static void xen_pt_pci_write_con
Ping?
>>> On 15.05.15 at 14:46, wrote:
> The code introduced to address XSA-126 allows simplification of other
> code in xen_pt_initfn(): All we need to do is update "cmd" suitably,
> as it'll be written back to the host register near the end of the
> func
The code introduced to address XSA-126 allows simplification of other
code in xen_pt_initfn(): All we need to do is update "cmd" suitably,
as it'll be written back to the host register near the end of the
function anyway.
Signed-off-by: Jan Beulich
--- a/hw/xen/xen_pt.c
+++ b/
initializing the ROM BAR register field
description.
Signed-off-by: Jan Beulich
--- a/hw/xen/xen_pt.c
+++ b/hw/xen/xen_pt.c
@@ -248,7 +248,9 @@ static void xen_pt_pci_write_config(PCID
/* check unused BAR register */
index = xen_pt_bar_offset_to_index(addr);
-if ((index >= 0) &
1 - 100 of 155 matches
Mail list logo
