On Mon, May 06, 2019 at 03:57:06AM -0600, Jan Beulich wrote:
> >>> On 06.05.19 at 10:04, wrote:
> > On 05/05/2019 15:27, Marek Marczykowski-Górecki wrote:
> >> Hi,
> >>
> >> I have a machine that allocate vesa LFB above 4GB, as reported by
buffer could be involved here.
Truncated framebuffer address (0x0) caused memset() in vesa_init() to
zero (among other things) mbi->mods_count. This triggered the crash as
described above.
Obviously, bitmap_fill() crash was just a fallout here, not the root
cause.
--
Best Regards,
Marek Marczyk
On Tue, May 07, 2019 at 03:10:06AM -0600, Jan Beulich wrote:
> >>> On 06.05.19 at 17:32, wrote:
> > On Mon, May 06, 2019 at 05:15:19PM +0200, Juergen Gross wrote:
> >> On 06/05/2019 16:50, Marek Marczykowski-Górecki wrote:
> >> > diff --git a/xen/include/
if a) framebuffer
address didn't fit, and b) you called ExitBootServices() already, you
don't have any means to tell the user what is wrong. Other than serial
console of course, if you're lucky enough to have one. So the idea was
to report the problem before ExitBootServices().
-
ddress didn't fit, and b) you called ExitBootServices() already, you
> > don't have any means to tell the user what is wrong. Other than serial
> > console of course, if you're lucky enough to have one. So the idea was
> > to report the problem before ExitBootServi
lfb_info is a #define to vga_console_info.u.vesa_lfb.
This means such helper would either not have any parameters, or would
need to have full struct xen_console_info as a parameter (inner
structure is anonymous). In both cases, it won't be obvious that
lfb_base live inside vlfb_info. I could ad
like this name. I've changed it to "pad"
(v4 upcoming).
> > +/* high 32 bits of lfb_base */
> > +uint32_t ext_lfb_base;
> > +#endif
>
> Strictly speaking the padding field belongs ahead of the earlier
> #endif.
>
> Both aspects can
o extend this if need be.
You mean:
#define PHYSDEVOP_MSI_CONTROL_ENABLE 1
#define PHYSDEVOP_MSI_CONTROL_MSI2
#define PHYSDEVOP_MSI_CONTROL_MSIX 4
Then use PHYSDEVOP_MSI_CONTROL_MSI(X) with or without
PHYSDEVOP_MSI_CONTROL_ENABLE ?
> > --- a/xen/include/xlat.lst
> > +++ b/xen/i
> one other instance), which will lead to skipping of the destroy_irq()
> call, and hence skipping of the permission removal. Or wait, that's
> going to be taken care of in the caller as it seems. If this is also
> your understanding, then please add a sentence to the description
>
x27;d anyway prefer a single
> >> flags field with descriptive #define-s, which will also make more
> >> obvious how to extend this if need be.
> >
> > You mean:
> >
> > #define PHYSDEVOP_MSI_CONTROL_ENABLE 1
> > #define PHYSDEVOP_MSI_CO
On Thu, Feb 28, 2019 at 01:25:50PM +0100, Marek Marczykowski wrote:
> On Thu, Feb 28, 2019 at 03:58:37AM -0700, Jan Beulich wrote:
> > Another thing: You're also bypassing the MSI{,-X}-already-enabled
> > checks that __pci_enable_msi{,x}() do, yet allowing to enable both
> &
}
> >>
> >> What about a call to pci_intx()?
> >
> > Should pci_intx(dev, !enable) be called in all those cases?
>
> Well, that depends whether Dom0 is involved, which is where the
> operation would normally be done. But since this is about bypassing
&g
sence check instead. If needed at this point at all - is this
function even called if there is no ROM?
--
Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
signature
he first time I see inline assembly is used to silence gcc.
> > ;-)
>
> And I'm not overly happy about it, but couldn't think of a better way
> without disabling said warning (or -Werror) altogether for the CU. If
> Ian's sketched out approach wo
rectly regardless of any possible
> > compiler optimizations.
> >
> > Use a volatile source to prevent the compiler from reordering or
> > omitting the copy.
> >
> > This is complementary to XSA155.
> >
> > Signed-off-by: Marek Marczykowski-Górecki
&
xen-devel on both the To and the Cc lists (just with different
> domains)?
Sorry about that, now fixed my setup.
--
Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
si
haps simply because it wasn't easy to obtain useful data, as
> frequently is the case with S3 resume). I think it would be nice if we could
> release 4.11 without a regression here.
I only know that Simon have tested it and it fails. Cc'ing him.
--
Best Regards,
Marek Marczykowski-Gó
Anyway, I'll send updated patch in a moment (instead of the revert).
--
Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
signature.asc
Description: PGP signature
_
ich would
> automatically determine the minimum number of 'extra' patches to
> backport from the stable branch to allow the patch to apply and build.
> The issue with that, of course, is that such a branch will be an
> artificial branch which has almost no testing.
I'm
nches of xen.git. If anything, then merging. But I further
> think we also shouldn't break the strict staging -> stable workflow
> with the osstest push gate in between. Some delay between public
> disclosure and release of the new stable version will hence be
> unavoidable. (Just
t; 858dbaaeda libacpi: fixes for iasl >= 20180427
>
> Iirc I've applied this back to 4.8 already, and quite some time ago.
Yes, this one is missing only in 4.7 and 4.6.
--
Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
A: Because it messes
at error, but looks EINVAL is used for a lot of cases.
> But I guess it wouldn't
> be appropriate to ask you to deal with this at the same time.
>
> Jan
>
>
--
Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
A:
ll the dependencies
resolved?
> sources= [ "xen/lowlevel/xc/xc.c" ])
>
> xs = Extension("xs",
> @@ -33,6 +44,7 @@ xs = Extension("xs",
> library_dirs = [ PATH_XENSTORE ],
> libraries = [ "xenstore" ],
> depends= [ PATH_XENSTORE + "/libxenstore.so" ],
> + extra_link_args= [ "-Wl,-rpath-link="+PATH_LIBXENTOOLCORE
> ],
> sources= [ "xen/lowlevel/xs/xs.c" ])
>
> plat = os.uname()[0]
--
Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
signature.asc
Description: PGP signature
s of the invocations.
>
> Signed-off-by: Jan Beulich
Acked-by: Marek Marczykowski-Górecki
> ---
> v2: Pass on and use SHLIB_libxen*.
> ---
> It's unclear to me whether this is ld version dependent - the pattern
> of where I've seen such warnings doesn't suggest a clear
being introduced in my place.
>
> Signed-off-by: Jan Beulich
I'm not sure what is the proper tag for cases like this, but:
Acked-by: Marek Marczykowski
> ---
> For the new maintainers, here's a 1st patch to consider right away:
> https://lists.xen.org/archives/html/x
it's not clear to me whether that would be (a) correct from an abstract
> >> pov (that's exception, not interrupt context after all)
> >
> > I agree with that.
> >
> >> and (b) really beneficial.
> >
> > I guess this could help to reduce the amount of churn. I can't really
> > make my mind whether this is worth it or not. So I would keep it as you did.
>
> Good, thanks.
>
> Jan
--
Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
signature.asc
Description: PGP signature
On Tue, Feb 13, 2024 at 08:45:54AM +0100, Jan Beulich wrote:
> On 13.02.2024 04:43, Marek Marczykowski wrote:
> > On Mon, Feb 12, 2024 at 10:04:38AM +0100, Jan Beulich wrote:
> >> On 08.02.2024 23:00, Julien Grall wrote:
> >>> On 05/02/2024 13:27, Jan Beulich w
On Tue, Feb 13, 2024 at 04:00:32PM +0100, Jan Beulich wrote:
> On 13.02.2024 15:53, Marek Marczykowski wrote:
> > On Tue, Feb 13, 2024 at 08:45:54AM +0100, Jan Beulich wrote:
> >> On 13.02.2024 04:43, Marek Marczykowski wrote:
> >>> On Mon, Feb 12, 2024 at 10:04
On Tue, Feb 13, 2024 at 04:44:04PM +0100, Jan Beulich wrote:
> On 13.02.2024 16:11, Marek Marczykowski wrote:
> > On Tue, Feb 13, 2024 at 04:00:32PM +0100, Jan Beulich wrote:
> >> On 13.02.2024 15:53, Marek Marczykowski wrote:
> >>> On Tue, Feb 13, 2024 at 08:45
On Thu, Feb 15, 2024 at 09:39:41AM +0100, Jan Beulich wrote:
> On 15.02.2024 03:19, Marek Marczykowski wrote:
> > On Tue, Feb 13, 2024 at 04:44:04PM +0100, Jan Beulich wrote:
> >> On 13.02.2024 16:11, Marek Marczykowski wrote:
> >>> On Tue, Feb 13, 2024 at 04:00
Stubdomain do not have it's own config file - its configuration is
derived from target domains. Do not try to manipulate it when attaching
PCI device.
This bug prevented starting HVM with stubdomain and PCI passthrough
device attached.
Signed-off-by: Marek Marczykowski-Górecki
Acked-by: We
rge Dunlap
Cc: Jan Beulich
Cc: Julien Grall
Cc: Konrad Rzeszutek Wilk
Cc: Stefano Stabellini
Cc: Tim Deegan
Cc: Anthony PERARD
Cc: "Roger Pau Monné"
Cc: Suravee Suthikulpanit
Cc: Brian Woods
Cc: Kevin Tian
Cc: Daniel De Graaf
Marek Marczykowski-Górecki (6):
libxl: do not attac
Add libxc wrapper for PHYSDEVOP_interrupt_control introduced in previous
commit.
Signed-off-by: Marek Marczykowski-Górecki
---
Changes in v3:
- new patch
Changes in v4:
- adjust for updated previous patch
Changes in v5:
- rename to PHYSDEVOP_msi_control, adjust arguments
Change in v6
only for stubdomain controlling the domain
which own the device.
Signed-off-by: Marek Marczykowski-Górecki
---
Changes in v3:
- new patch
Changes in v4:
- adjust code style
- s/msi_msix/msi/
- add msi_set_enable XSM hook
- flatten struct physdev_msi_set_enable
- add to include/xlat.lst
Chang
it be stubdomain (the commit prevents attaching device to target
HVM in this case); otherwise, attach it to the target domain.
Signed-off-by: Marek Marczykowski-Górecki
Acked-by: Wei Liu
---
Changes in v2:
- previously called "libxl: attach xen-pciback only to PV domains"
- instead of exc
ff-by: Simon Gaiser
Signed-off-by: Marek Marczykowski-Górecki
---
Changes in v3:
- extend commit message
Changes in v4:
- add missing destroy_irq on error path
Changes in v5:
- move irq_{grant,revoke}_access() to {create,destroy}_irq(), which
basically make it a different patch
- add get_dm_d
When qemu is running in stubdomain, handling "pci-ins" command will fail
if pcifront is not initialized already. Fix this by sending such command
only after confirming that pciback/front is running.
Signed-off-by: Marek Marczykowski-Górecki
Acked-by: Wei Liu
---
Changes in v2:
-
On Fri, Sep 20, 2019 at 12:10:09PM +0200, Jan Beulich wrote:
> On 14.09.2019 17:37, Marek Marczykowski-Górecki wrote:
> > Allow device model running in stubdomain to enable/disable INTx/MSI(-X),
> > bypassing pciback. While pciback is still used to access config space
> > f
On Mon, Sep 23, 2019 at 09:58:27AM +0200, Jan Beulich wrote:
> On 20.09.2019 18:02, Marek Marczykowski-Górecki wrote:
> > On Fri, Sep 20, 2019 at 12:10:09PM +0200, Jan Beulich wrote:
> >> On 14.09.2019 17:37, Marek Marczykowski-Górecki wrote:
> >>> Allow device
On Mon, Sep 23, 2019 at 02:05:58PM +0200, Jan Beulich wrote:
> On 23.09.2019 12:47, Marek Marczykowski-Górecki wrote:
> > On Mon, Sep 23, 2019 at 09:58:27AM +0200, Jan Beulich wrote:
> >> On 20.09.2019 18:02, Marek Marczykowski-Górecki wrote:
> >>> Anyway, if you al
On Mon, Sep 23, 2019 at 03:02:49PM +0200, Jan Beulich wrote:
> On 23.09.2019 14:25, Marek Marczykowski-Górecki wrote:
> > What about this: HVM guest can already do all of this when qemu is
> > running in dom0. So, allowing those actions when qemu is running in
> > stubdomain
Cc: Tim Deegan
Cc: Anthony PERARD
Cc: "Roger Pau Monné"
Cc: Suravee Suthikulpanit
Cc: Brian Woods
Cc: Kevin Tian
Cc: Daniel De Graaf
Marek Marczykowski-Górecki (4):
libxl: do not attach xen-pciback to HVM domain, if stubdomain is in use
libxl: attach PCI device to qemu only af
Stubdomain do not have it's own config file - its configuration is
derived from target domains. Do not try to manipulate it when attaching
PCI device.
This bug prevented starting HVM with stubdomain and PCI passthrough
device attached.
Signed-off-by: Marek Marczykowski-Górecki
Acked-by: We
ff-by: Simon Gaiser
Signed-off-by: Marek Marczykowski-Górecki
---
Changes in v3:
- extend commit message
Changes in v4:
- add missing destroy_irq on error path
Changes in v5:
- move irq_{grant,revoke}_access() to {create,destroy}_irq(), which
basically make it a different patch
- add get_dm_d
it be stubdomain (the commit prevents attaching device to target
HVM in this case); otherwise, attach it to the target domain.
Signed-off-by: Marek Marczykowski-Górecki
Acked-by: Wei Liu
---
Changes in v2:
- previously called "libxl: attach xen-pciback only to PV domains"
- instead of exc
When qemu is running in stubdomain, handling "pci-ins" command will fail
if pcifront is not initialized already. Fix this by sending such command
only after confirming that pciback/front is running.
Signed-off-by: Marek Marczykowski-Górecki
Acked-by: Wei Liu
---
Changes in v2:
-
that part, as discussed, doesn't need to be in Xen. For example
the solution deployed in current Qubes stable version is based on
pciback for this purpose.
--
Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
A: Because it messes up the order in which people normally read text.
Q: Why is
stubdomain-msi-irq-access.patch
by Eric Chanudet .
Signed-off-by: Simon Gaiser
Signed-off-by: Marek Marczykowski-Górecki
Reviewed-by: Roger Pau Monné
---
Changes in v3:
- extend commit message
Changes in v4:
- add missing destroy_irq on error path
Changes in v5:
- move irq_{grant,revoke}_a
On Wed, Sep 25, 2019 at 03:26:17PM +0200, Roger Pau Monné wrote:
> On Wed, Sep 25, 2019 at 02:29:41PM +0200, Marek Marczykowski-Górecki wrote:
> > On Wed, Sep 25, 2019 at 11:41:50AM +0200, Roger Pau Monné wrote:
> > > It would still be nice to get the missing bits (interrupt e
evtchn
--
Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
signature.asc
Description: PGP signature
___
Xen-devel maili
On Fri, Sep 27, 2019 at 09:44:35AM +0200, David Hildenbrand wrote:
> On 26.09.19 23:34, Marek Marczykowski-Górecki wrote:
> > Hi,
> >
> > I've hit VM_BUG_ON_PAGE(!PageOffline(page), page) in
> > alloc_xenballooned_pages, when trying to use gnttab from userspace
&g
On Fri, Sep 27, 2019 at 03:36:08PM +0100, Wei Liu wrote:
> On Fri, Sep 27, 2019 at 04:21:55PM +0200, Jan Beulich wrote:
> > >
> > > Marek Marczykowski-Górecki (4):
> > > libxl: do not attach xen-pciback to HVM domain, if stubdomain is in use
> > > libx
Stubdomain do not have it's own config file - its configuration is
derived from target domains. Do not try to manipulate it when attaching
PCI device.
This bug prevented starting HVM with stubdomain and PCI passthrough
device attached.
Signed-off-by: Marek Marczykowski-Górecki
Acked-by: We
it be stubdomain (the commit prevents attaching device to target
HVM in this case); otherwise, attach it to the target domain.
Signed-off-by: Marek Marczykowski-Górecki
Acked-by: Wei Liu
---
Changes in v2:
- previously called "libxl: attach xen-pciback only to PV domains"
- instead of exc
When qemu is running in stubdomain, handling "pci-ins" command will fail
if pcifront is not initialized already. Fix this by sending such command
only after confirming that pciback/front is running.
Signed-off-by: Marek Marczykowski-Górecki
---
Changes in v2:
- Fixed code style sinc
quot;Roger Pau Monné"
Cc: Suravee Suthikulpanit
Cc: Brian Woods
Cc: Kevin Tian
Cc: Daniel De Graaf
Marek Marczykowski-Górecki (4):
libxl: fix cold plugged PCI device with stubdomain
libxl: do not attach xen-pciback to HVM domain, if stubdomain is in use
libxl: attach PCI device to
and stubdomain.
Fix this by resetting (local) 'starting' to false in pci_add_dm_done()
(previously part of do_pci_add()) when handling stubdomain, regardless
of pas->starting value.
Fixes: 11db56f9a6 (libxl_pci: Use libxl__ao_device with libxl__device_pci_add)
Signed-off-by: Marek Marcz
On Thu, Sep 26, 2019 at 09:10:17AM +0200, Roger Pau Monné wrote:
> On Thu, Sep 26, 2019 at 06:16:06AM +0200, Marek Marczykowski-Górecki wrote:
> > On Wed, Sep 25, 2019 at 03:26:17PM +0200, Roger Pau Monné wrote:
> > > On Wed, Sep 25, 2019 at 02:29:41PM +0200, Marek Ma
On Sun, Sep 29, 2019 at 03:35:57AM +0200, Marek Marczykowski-Górecki wrote:
> On Thu, Sep 26, 2019 at 09:10:17AM +0200, Roger Pau Monné wrote:
> > On Thu, Sep 26, 2019 at 06:16:06AM +0200, Marek Marczykowski-Górecki wrote:
> > > On Wed, Sep 25, 2019 at 03:26:17PM +0200, Rog
LFB64?). But I'm not sure how non-patched
Linux (or other supported OSes) would respond to this. xen_init_vga() in
Linux doesn't seem to bail on unknown video_type, so it may be fragile.
Any better ideas?
--
Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
A: Because it mess
MAX_BPP, MAX_FONT_W, MAX_FONT_H are not used in the code at all.
Signed-off-by: Marek Marczykowski-Górecki
---
xen/drivers/video/lfb.c | 3 ---
1 file changed, 3 deletions(-)
diff --git a/xen/drivers/video/lfb.c b/xen/drivers/video/lfb.c
index d0c8c49..0475a68 100644
--- a/xen/drivers/video
console on device with 3840x2160 native resolution.
Signed-off-by: Marek Marczykowski-Górecki
---
Cc: Olaf Hering
---
xen/drivers/video/lfb.c | 10 --
1 file changed, 10 deletions(-)
diff --git a/xen/drivers/video/lfb.c b/xen/drivers/video/lfb.c
index 0475a68..5022195 100644
--- a/xen/dri
When bitmap_fill(..., 0) is called, do not try to write anything. Before
this patch, it tried to write almost LONG_MAX, surely overwriting
something.
Signed-off-by: Marek Marczykowski-Górecki
---
Found while debugging framebuffer located above 4GB. In that case 32bit
variable for it overflows
with older
Linux versions too (other than using possibly truncated address - no
worse than without this change). Thanks to ABI containing size of the
structure (start_info.console.dom0.info_size), Linux can detect when
this field is present and use it appropriately then.
Signed-off-by:
cc: Olaf Hering
Marek Marczykowski-Górecki (5):
xen/bitmap: fix bitmap_fill with zero-sized bitmap
drivers/video: drop unused limits
drivers/video: Drop framebuffer size constraints
xen: fix handling framebuffer located above 4GB
drivers/video: use vlfb_info consistently
xen/arch/x86
vlfb_info is an alias for vga_console_info.u.vesa_lfb, so this change is
purely cosmetic. But using the same name helps reading the code.
Signed-off-by: Marek Marczykowski-Górecki
---
xen/drivers/video/vesa.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/xen/drivers/video
On Mon, May 06, 2019 at 05:15:19PM +0200, Juergen Gross wrote:
> On 06/05/2019 16:50, Marek Marczykowski-Górecki wrote:
> > diff --git a/xen/include/public/xen.h b/xen/include/public/xen.h
> > index ccdffc0..b0f0f7e 100644
> > --- a/xen/include/public/xen.h
> > +++
When bitmap_fill(..., 0) is called, do not try to write anything. Before
this patch, it tried to write almost LONG_MAX, surely overwriting
something.
Signed-off-by: Marek Marczykowski-Górecki
Reviewed-by: Andrew Cooper
Reviewed-by: Jan Beulich
---
xen/include/xen/bitmap.h | 2 ++
1 file
MAX_BPP, MAX_FONT_W, MAX_FONT_H are not used in the code at all.
Signed-off-by: Marek Marczykowski-Górecki
Suggested-by: Jan Beulich
Acked-by: Andrew Cooper
---
xen/drivers/video/lfb.c | 3 ---
1 file changed, 3 deletions(-)
diff --git a/xen/drivers/video/lfb.c b/xen/drivers/video/lfb.c
vlfb_info is an alias for vga_console_info.u.vesa_lfb, so this change is
purely cosmetic. But using the same name helps reading the code.
Signed-off-by: Marek Marczykowski-Górecki
Acked-by: Andrew Cooper
---
xen/drivers/video/vesa.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff
console on device with 3840x2160 native resolution.
Signed-off-by: Marek Marczykowski-Górecki
Suggested-by: Jan Beulich
Acked-by: Andrew Cooper
---
Cc: Olaf Hering
---
xen/drivers/video/lfb.c | 10 --
1 file changed, 10 deletions(-)
diff --git a/xen/drivers/video/lfb.c b/xen/drivers/v
cc: Olaf Hering
Marek Marczykowski-Górecki (5):
xen/bitmap: fix bitmap_fill with zero-sized bitmap
drivers/video: drop unused limits
drivers/video: Drop framebuffer size constraints
xen: fix handling framebuffer located above 4GB
drivers/video: use vlfb_info consistently
xen/arch/x86
with older
Linux versions too (other than using possibly truncated address - no
worse than without this change). Thanks to ABI containing size of the
structure (start_info.console.dom0.info_size), Linux can detect when
this field is present and use it appropriately then.
Signed-off-by:
On Mon, May 13, 2019 at 04:34:14PM +0100, Wei Liu wrote:
> Hello
>
> Seeing that you were the last people who changed blktap2 in a meaningful
> way: do you use it at all?
>
> I'm thinking about dropping it (again).
Fine with me too.
--
Best Regards,
Marek Marczykowski-G
an Jackson
cc: Jan Beulich
cc: Julien Grall
cc: Konrad Rzeszutek Wilk
cc: Stefano Stabellini
cc: Tim Deegan
cc: Wei Liu
cc: Olaf Hering
Marek Marczykowski-Górecki (1):
xen: fix handling framebuffer located above 4GB
xen/arch/x86/efi/efi-boot.h | 1 +
xen/drivers/video/vesa.c
ublic interface and use __XEN_INTERFACE_VERSION__,
bump __XEN_LATEST_INTERFACE_VERSION__.
Note: if/when backporting this change to Xen <= 4.12, #if in xen.h needs
to be extended with " || defined(__XEN__)".
Signed-off-by: Marek Marczykowski-Górecki
---
Changes in v2:
- guard ext
ublic interface and use __XEN_INTERFACE_VERSION__,
bump __XEN_LATEST_INTERFACE_VERSION__.
Note: if/when backporting this change to Xen <= 4.12, #if in xen.h needs
to be extended with " || defined(__XEN__)".
Signed-off-by: Marek Marczykowski-Górecki
---
Changes in v2:
- guard ext
On Thu, Nov 01, 2018 at 05:21:39PM +, Ian Jackson wrote:
> Marek Marczykowski-Górecki writes ("[RFC PATCH v2 11/17] xenconsoled: add
> support for consoles using 'state' xenstore entry"):
> > Add support for standard xenbus initialization protocol using '
-by: Marek Marczykowski-Górecki
---
This is only one part of fixing MSI with QEMU in stubdomain. The other
part is allowing stubdomain to actually enable MSI in PCI config space.
QEMU does that through pcifront/back connected to the stubdomain (see
hw/xen/xen_pt_msi.c:msi_msix_enable()), but pciback
Stubdomain do not have it's own config file - its configuration is
derived from target domains. Do not try to manipulate it when attaching
PCI device.
This bug prevented starting HVM with stubdomain and PCI passthrough
device attached.
Signed-off-by: Marek Marczykowski-Górecki
---
tools/
When qemu is running in stubdomain, handling "pci-ins" command will fail
if pcifront is not initialized already. Fix this by sending such command
only after confirming that pciback/front is running.
Signed-off-by: Marek Marczykowski-Górecki
---
Changes in v2:
- Fixed code style sinc
to the stubdomain, effectively breaking PCI
passthrough.
Signed-off-by: Marek Marczykowski-Górecki
---
Changes in v2:
- previously called "libxl: attach xen-pciback only to PV domains"
- instead of excluding all HVMs, change the condition to what actually
matters here - check if stu
to irq created for msi" patch
- applied review comments from v1
Marek Marczykowski-Górecki (3):
libxl: do not attach xen-pciback to HVM domain, if stubdomain is in use
libxl: attach PCI device to qemu only after setting pciback/pcifront
libxl: don't try to manipulate json config for
On Wed, Jan 16, 2019 at 10:21:29AM +0100, Roger Pau Monné wrote:
> On Tue, Jan 15, 2019 at 04:36:31PM +0100, Marek Marczykowski-Górecki wrote:
> > From: Simon Gaiser
> >
> > Stubdomains need to be given sufficient privilege over the guest which it
> > provides emu
On Wed, Jan 16, 2019 at 01:20:04PM +0100, Roger Pau Monné wrote:
> On Wed, Jan 16, 2019 at 11:52:18AM +0100, Marek Marczykowski-Górecki wrote:
> > On Wed, Jan 16, 2019 at 10:21:29AM +0100, Roger Pau Monné wrote:
> > > On Tue, Jan 15, 2019 at 04:36:31PM +0100, Marek Ma
On Wed, Jan 16, 2019 at 05:47:19PM +0100, Roger Pau Monné wrote:
> On Tue, Jan 15, 2019 at 04:36:28PM +0100, Marek Marczykowski-Górecki wrote:
> > HVM domains use IOMMU and device model assistance for communicating with
> > PCI devices, xen-pcifront/pciback is used only in PV do
target domain.
This also may be the reason why PCI devices are not included in
stubdomain's config, but only do_pci_add() is called. It may be that in
the past some more parts of the device setup was skipped this way.
--
Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
A: Because
On Wed, Jan 16, 2019 at 11:52:21AM +0100, Marek Marczykowski-Górecki wrote:
> On Wed, Jan 16, 2019 at 10:21:29AM +0100, Roger Pau Monné wrote:
> > On Tue, Jan 15, 2019 at 04:36:31PM +0100, Marek Marczykowski-Górecki wrote:
> > > From: Simon Gaiser
> > >
> &g
On Fri, Jan 25, 2019 at 08:43:59PM +0100, Marek Marczykowski-Górecki wrote:
> On Wed, Jan 16, 2019 at 11:52:21AM +0100, Marek Marczykowski-Górecki wrote:
> > On Wed, Jan 16, 2019 at 10:21:29AM +0100, Roger Pau Monné wrote:
> > > On Tue, Jan 15, 2019 at 04:36:31PM +0100, Marek Ma
On Thu, Jan 17, 2019 at 11:29:59AM +0100, Roger Pau Monné wrote:
> On Tue, Jan 15, 2019 at 04:36:29PM +0100, Marek Marczykowski-Górecki wrote:
> > When qemu is running in stubdomain, handling "pci-ins" command will fail
> > if pcifront is not initialized already. Fix thi
it be stubdomain (the commit prevents attaching device to target
HVM in this case); otherwise, attach it to the target domain.
Signed-off-by: Marek Marczykowski-Górecki
---
Changes in v2:
- previously called "libxl: attach xen-pciback only to PV domains"
- instead of excluding all HVMs, chang
/18/msi-support/
Changes in v2:
- new "xen/x86: Allow stubdom access to irq created for msi" patch
- applied review comments from v1
Changes is v3:
- apply suggestions by Roger
- add PHYSDEVOP_msi_msix_set_enable
Marek Marczykowski-Górecki (5):
libxl: do not attach xen-pciback to
ed on
https://github.com/OpenXT/xenclient-oe/blob/5e0e7304a5a3c75ef01240a1e3673665b2aaf05e/recipes-extended/xen/files/stubdomain-msi-irq-access.patch
by Eric Chanudet .
Signed-off-by: Simon Gaiser
Signed-off-by: Marek Marczykowski-Górecki
---
Changes in v3:
- extend commit message
With this
g the domain
which own the device.
Signed-off-by: Marek Marczykowski-Górecki
---
Changes in v3:
- new patch
This is rather RFC. Any suggestions for shorter name? Also, I'm not sure
if physdev_msi_msix_set_enable.flag is the best name/idea.
Should it be plugged into XSM? Any suggestions h
Stubdomain do not have it's own config file - its configuration is
derived from target domains. Do not try to manipulate it when attaching
PCI device.
This bug prevented starting HVM with stubdomain and PCI passthrough
device attached.
Signed-off-by: Marek Marczykowski-Górecki
---
Changes
When qemu is running in stubdomain, handling "pci-ins" command will fail
if pcifront is not initialized already. Fix this by sending such command
only after confirming that pciback/front is running.
Signed-off-by: Marek Marczykowski-Górecki
---
Changes in v2:
- Fixed code style sinc
Add libxc wrapper for PHYSDEVOP_msi_msix_set_enable introduced in
previous commit.
Signed-off-by: Marek Marczykowski-Górecki
---
Changes in v3:
- new patch
---
tools/libxc/include/xenctrl.h | 7 +++
tools/libxc/xc_physdev.c | 21 +
2 files changed, 28 insertions
On Mon, Jan 28, 2019 at 02:50:00PM +, Wei Liu wrote:
> On Sat, Jan 26, 2019 at 03:31:15AM +0100, Marek Marczykowski-Górecki wrote:
> > From: Simon Gaiser
> >
> > Stubdomains need to be given sufficient privilege over the guest which it
> > provides emulation for i
On Mon, Jan 28, 2019 at 02:41:15PM +, Wei Liu wrote:
> On Sat, Jan 26, 2019 at 03:31:14AM +0100, Marek Marczykowski-Górecki wrote:
> > Stubdomain do not have it's own config file - its configuration is
> > derived from target domains. Do not try to manipulate it when atta
functions that are
not async-compatible do need to call qmp commands (for example
libxl_domain_unpause). Alternative to this patch, would be return error,
breaking all such functions, and incrementally convert them to async
API.
Signed-off-by: Marek Marczykowski-Górecki
---
Two TODOs here:
- hand
1 - 100 of 1289 matches
Mail list logo
