On 29.10.20 01:37, Stefano Stabellini wrote:
On Tue, 27 Oct 2020, Elliott Mitchell wrote:
On Mon, Oct 26, 2020 at 06:44:27PM +, Julien Grall wrote:
On 26/10/2020 16:03, Elliott Mitchell wrote:
On Mon, Oct 26, 2020 at 01:31:42PM +, Julien Grall wrote:
On 24/10/2020 06:35, Elliott Mitch
From: Arnd Bergmann
There are hundreds of warnings in a W=2 build about a local
variable shadowing the global 'apic' definition:
arch/x86/kvm/lapic.h:149:65: warning: declaration of 'apic' shadows a global
declaration [-Wshadow]
Avoid this by renaming the global 'apic' variable to the more des
flight 156267 qemu-mainline real [real]
flight 156286 qemu-mainline real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/156267/
http://logs.test-lab.xenproject.org/osstest/logs/156286/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be
flight 156264 xen-4.14-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/156264/
Failures :-/ but no regressions.
Regressions which are regarded as allowable (not blocking):
test-armhf-armhf-xl-rtds18 guest-start/debian.repeat fail REGR. vs. 156063
Tests which did not suc
Hi Alex,
2020年10月29日(木) 2:44 Alex Bennée :
>
> Xen is supported on aarch64 although weirdly using the i386-softmmu
> model. Checking based on the host CPU meant we never enabled Xen
> support. It would be nice to enable CONFIG_XEN for aarch64-softmmu to
> make it not seem weird but that will requi
Hi Alex,
2020年10月28日(水) 21:03 Alex Bennée :
>
>
> Masami Hiramatsu writes:
>
> > Hello,
> >
> > When I tested the kprobes on Dom0 kernel, it caused a kernel panic.
> >
> > Here is an example, to clarify the bug is in the single-stepping
> > (software-step exception), I added a printk() where the
On Tue, 27 Oct 2020, Elliott Mitchell wrote:
> On Mon, Oct 26, 2020 at 06:44:27PM +, Julien Grall wrote:
> > On 26/10/2020 16:03, Elliott Mitchell wrote:
> > > On Mon, Oct 26, 2020 at 01:31:42PM +, Julien Grall wrote:
> > >> On 24/10/2020 06:35, Elliott Mitchell wrote:
> > >>> ACPI has a di
On 26/10/2020 09:40, Jan Beulich wrote:
> In the case that no 64-bit SYSCALL callback is registered, the guest
> will be crashed when 64-bit userspace executes a SYSCALL instruction,
> which would be a userspace => kernel DoS. Similarly for 32-bit
> userspace when no 32-bit SYSCALL callback was re
On Wed, 28 Oct 2020, Alex Bennée wrote:
> Xen is supported on aarch64 although weirdly using the i386-softmmu
> model. Checking based on the host CPU meant we never enabled Xen
> support. It would be nice to enable CONFIG_XEN for aarch64-softmmu to
> make it not seem weird but that will require fur
On Wed, 28 Oct 2020, Julien Grall wrote:
> Hi Bertrand,
>
> On 26/10/2020 16:21, Bertrand Marquis wrote:
> > When a Cortex A57 processor is affected by CPU errata 832075, a guest
> > not implementing the workaround for it could deadlock the system.
> > Add a warning during boot informing the user
The functions exynos_drm_gem_prime_{vmap,vunmap}() are empty. Remove
them before changing the interface to use struct drm_buf_map. As a side
effect of removing drm_gem_prime_vmap(), the error code changes from
ENOMEM to EOPNOTSUPP.
Signed-off-by: Thomas Zimmermann
Acked-by: Christian König
Teste
The function drm_gem_cma_prime_vunmap() is empty. Remove it before
changing the interface to use struct drm_buf_map.
Signed-off-by: Thomas Zimmermann
Reviewed-by: Christian König
Tested-by: Sam Ravnborg
---
drivers/gpu/drm/drm_gem_cma_helper.c | 17 -
drivers/gpu/drm/vc4/vc4_bo
The function etnaviv_gem_prime_vunmap() is empty. Remove it before
changing the interface to use struct drm_buf_map.
Signed-off-by: Thomas Zimmermann
Acked-by: Christian König
Tested-by: Sam Ravnborg
---
drivers/gpu/drm/etnaviv/etnaviv_drv.h | 1 -
drivers/gpu/drm/etnaviv/etnaviv_gem.c
The new functions ttm_bo_{vmap,vunmap}() map and unmap a TTM BO in kernel
address space. The mapping's address is returned as struct dma_buf_map.
Each function is a simplified version of TTM's existing kmap code. Both
functions respect the memory's location ani/or writecombine flags.
On top TTM's
Kernel DRM clients now store their framebuffer address in an instance
of struct dma_buf_map. Depending on the buffer's location, the address
refers to system or I/O memory.
Callers of drm_client_buffer_vmap() receive a copy of the value in
the call's supplied arguments. It can be accessed and modi
At least sparc64 requires I/O-specific access to framebuffers. This
patch updates the fbdev console accordingly.
For drivers with direct access to the framebuffer memory, the callback
functions in struct fb_ops test for the type of memory and call the rsp
fb_sys_ of fb_cfb_ functions. Read and wri
DRM's fbdev console uses regular load and store operations to update
framebuffer memory. The bochs driver on sparc64 requires the use of
I/O-specific load and store operations. We have a workaround, but need
a long-term solution to the problem.
This patchset changes GEM's vmap/vunmap interfaces to
The parameters map and is_iomem are always of the same value. Removed them
to prepares the function for conversion to struct dma_buf_map.
v4:
* don't check for !kmap->virtual; will always be false
Signed-off-by: Thomas Zimmermann
Reviewed-by: Daniel Vetter
Reviewed-by: Christian König
To do framebuffer updates, one needs memcpy from system memory and a
pointer-increment function. Add both interfaces with documentation.
v5:
* include to build on sparc64 (Sam)
Signed-off-by: Thomas Zimmermann
Reviewed-by: Sam Ravnborg
Tested-by: Sam Ravnborg
---
include/linux/dma-bu
GEM's vmap and vunmap interfaces now wrap memory pointers in struct
dma_buf_map.
Signed-off-by: Thomas Zimmermann
Reviewed-by: Daniel Vetter
Tested-by: Sam Ravnborg
---
drivers/gpu/drm/drm_client.c | 18 +++---
drivers/gpu/drm/drm_gem.c | 26 +-
drive
This patch replaces the vmap/vunmap's use of raw pointers in GEM object
functions with instances of struct dma_buf_map. GEM backends are
converted as well. For most of them, this simply changes the returned type.
TTM-based drivers now return information about the location of the memory,
either sys
On 26/10/2020 11:03, Rahul Singh wrote:
Hello Julien,
Hi Rahul,
On 23 Oct 2020, at 4:19 pm, Julien Grall wrote:
On 23/10/2020 15:27, Rahul Singh wrote:
Hello Julien,
On 23 Oct 2020, at 2:00 pm, Julien Grall wrote:
On 23/10/2020 12:35, Rahul Singh wrote:
Hello,
On 23 Oct 2020, a
Hi Bertrand,
On 26/10/2020 16:21, Bertrand Marquis wrote:
When a Cortex A57 processor is affected by CPU errata 832075, a guest
not implementing the workaround for it could deadlock the system.
Add a warning during boot informing the user that only trusted guests
should be executed on the system
Hi,
On 28/10/2020 08:43, Bertrand Marquis wrote:
On 27 Oct 2020, at 22:44, Stefano Stabellini wrote:
On Mon, 26 Oct 2020, Bertrand Marquis wrote:
When a Cortex A57 processor is affected by CPU errata 832075, a guest
not implementing the workaround for it could deadlock the system.
Add a wa
On Tue, Oct 27, 2020 at 12:06:56PM +0100, Jan Beulich wrote:
> On 27.10.2020 11:57, Andrew Cooper wrote:
> > On 27/10/2020 10:37, Jan Beulich wrote:
> >> On 27.10.2020 11:27, Olaf Hering wrote:
> >>> Am Tue, 27 Oct 2020 11:16:04 +0100
> >>> schrieb Jan Beulich :
> >>>
> This pattern is used wh
Xen is supported on aarch64 although weirdly using the i386-softmmu
model. Checking based on the host CPU meant we never enabled Xen
support. It would be nice to enable CONFIG_XEN for aarch64-softmmu to
make it not seem weird but that will require further build surgery.
Signed-off-by: Alex Bennée
On Wed, Oct 28, 2020 at 03:23:18PM +0100, Mauro Carvalho Chehab wrote:
> diff --git a/Documentation/ABI/testing/sysfs-uevent
> b/Documentation/ABI/testing/sysfs-uevent
> index aa39f8d7bcdf..d0893dad3f38 100644
> --- a/Documentation/ABI/testing/sysfs-uevent
> +++ b/Documentation/ABI/testing/sysfs-
On Wed, Oct 28, 2020 at 02:49:15PM +, Julien Grall wrote:
> (+ Anthony and Stefano,)
>
> Hi Jason,
>
> On 28/10/2020 13:37, Jason Andryuk wrote:
> > On Tue, Oct 27, 2020 at 5:23 PM osstest service owner
> > wrote:
> > >
> > > flight 156257 qemu-mainline real [real]
> > > flight 156266 qemu-
flight 156265 xen-4.13-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/156265/
Failures :-/ but no regressions.
Regressions which are regarded as allowable (not blocking):
test-armhf-armhf-xl-rtds18 guest-start/debian.repeat fail REGR. vs. 156054
Tests which did not suc
On 28.10.2020 16:47, Rahul Singh wrote:
> Ok. I will enable by default HAS_NS16550_PCI on X86 only. Once we have proper
> support for NS16550 PCI on ARM we can enable it at that time.
> I will modify as follows:
>
> config HAS_NS16550_PCI
>
Hello Julen,
> On 28 Oct 2020, at 11:32 am, Julien Grall wrote:
>
> Hi,
>
> On 28/10/2020 10:41, Rahul Singh wrote:
>>> On 28 Oct 2020, at 7:18 am, Jan Beulich wrote:
>>>
>>> On 28.10.2020 00:32, Stefano Stabellini wrote:
On Mon, 26 Oct 2020, Rahul Singh wrote:
> --- a/xen/drivers/ch
Luckily sh_remove_all_mappings()'s use of the parameter is limited to
generation of log messages. Nevertheless we'd better pass correct GFNs
around:
- the incoming GFN, when replacing a large page, may not be large page
aligned,
- incrementing by page-size-scaled values can't be right.
Signed-of
On 28.10.2020 16:20, Rahul Singh wrote:
>> On 28 Oct 2020, at 11:51 am, Jan Beulich wrote:
>> On 26.10.2020 18:17, Rahul Singh wrote:
>>> +int arch_pci_release_devices(struct domain *d)
>>> +{
>>> +return pci_clean_dpci_irqs(d);
>>> +}
>>
>> Why the extra function layer?
>
> Is that ok if I r
Hello Jan,
> On 28 Oct 2020, at 11:51 am, Jan Beulich wrote:
>
> On 26.10.2020 18:17, Rahul Singh wrote:
>> passthrough/pci.c file is common for all architecture, but there is x86
>> sepcific code in this file.
>
> The code you move doesn't look to be x86 specific in the sense that
> it makes n
Hello Jan,
> On 28 Oct 2020, at 11:56 am, Jan Beulich wrote:
>
> On 26.10.2020 18:17, Rahul Singh wrote:
>> --- a/xen/drivers/passthrough/pci.c
>> +++ b/xen/drivers/passthrough/pci.c
>> @@ -1419,13 +1419,15 @@ static int assign_device(struct domain *d, u16 seg,
>> u8 bus, u8 devfn, u32 flag)
>>
(+ Anthony and Stefano,)
Hi Jason,
On 28/10/2020 13:37, Jason Andryuk wrote:
On Tue, Oct 27, 2020 at 5:23 PM osstest service owner
wrote:
flight 156257 qemu-mainline real [real]
flight 156266 qemu-mainline real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/156257/
http://log
Read a batch of iovec's.
In the common case of short reads, finish individual iov's with read_exact.
Signed-off-by: Olaf Hering
---
Users will follow, next month probably.
tools/libs/ctrl/xc_private.c | 54 +++-
tools/libs/ctrl/xc_private.h | 1 +
2 files chan
From: Mauro Carvalho Chehab
Several entries at the stable ABI files won't parse if we pass
them directly to the ReST output.
Adjust them, in order to allow adding their contents as-is at
the stable ABI book.
Signed-off-by: Mauro Carvalho Chehab
Signed-off-by: Mauro Carvalho Chehab
---
Docume
Introduce a helper which decides if a given pfn type has data
for the migration stream.
No change in behavior intended.
Signed-off-by: Olaf Hering
---
tools/libs/guest/xg_sr_common.h | 17
tools/libs/guest/xg_sr_restore.c | 34 +---
tools/libs/guest
Users of xc_get_pfn_type_batch may want to sanity check the data
returned by Xen. Add a simple helper for this purpose.
Signed-off-by: Olaf Hering
---
tools/libs/ctrl/xc_private.h | 33 +
1 file changed, 33 insertions(+)
diff --git a/tools/libs/ctrl/xc_private.h
Verify pfn type on sending side, also verify incoming batch of pfns.
Signed-off-by: Olaf Hering
---
tools/libs/guest/xg_sr_restore.c | 3 +--
tools/libs/guest/xg_sr_save.c| 6 ++
2 files changed, 7 insertions(+), 2 deletions(-)
diff --git a/tools/libs/guest/xg_sr_restore.c b/tools/libs/
On 28/10/2020 08:50, Masami Hiramatsu wrote:
Hello,
Hi,
When I tested the kprobes on Dom0 kernel, it caused a kernel panic.
Here is an example, to clarify the bug is in the single-stepping
(software-step exception), I added a printk() where the kprobes setup
single-stepping.
root@develbo
On Tue, Oct 27, 2020 at 5:23 PM osstest service owner
wrote:
>
> flight 156257 qemu-mainline real [real]
> flight 156266 qemu-mainline real-retest [real]
> http://logs.test-lab.xenproject.org/osstest/logs/156257/
> http://logs.test-lab.xenproject.org/osstest/logs/156266/
>
> Regressions :-(
>
> Te
Masami Hiramatsu writes:
> Hello,
>
> When I tested the kprobes on Dom0 kernel, it caused a kernel panic.
>
> Here is an example, to clarify the bug is in the single-stepping
> (software-step exception), I added a printk() where the kprobes setup
> single-stepping.
>
> root@develbox:~# cd /sys/
On 28/10/2020 11:51, Jan Beulich wrote:
On 26.10.2020 18:17, Rahul Singh wrote:
passthrough/pci.c file is common for all architecture, but there is x86
sepcific code in this file.
The code you move doesn't look to be x86 specific in the sense that
it makes no sense on other architectures, b
On 26.10.2020 18:17, Rahul Singh wrote:
> --- a/xen/drivers/passthrough/pci.c
> +++ b/xen/drivers/passthrough/pci.c
> @@ -1419,13 +1419,15 @@ static int assign_device(struct domain *d, u16 seg,
> u8 bus, u8 devfn, u32 flag)
> if ( !is_iommu_enabled(d) )
> return 0;
>
> -/* Prev
On 26.10.2020 18:17, Rahul Singh wrote:
> passthrough/pci.c file is common for all architecture, but there is x86
> sepcific code in this file.
The code you move doesn't look to be x86 specific in the sense that
it makes no sense on other architectures, but just because certain
pieces are missing
Hi,
On 28/10/2020 10:41, Rahul Singh wrote:
On 28 Oct 2020, at 7:18 am, Jan Beulich wrote:
On 28.10.2020 00:32, Stefano Stabellini wrote:
On Mon, 26 Oct 2020, Rahul Singh wrote:
--- a/xen/drivers/char/Kconfig
+++ b/xen/drivers/char/Kconfig
@@ -4,6 +4,13 @@ config HAS_NS16550
help
flight 156263 xen-4.12-testing real [real]
flight 156278 xen-4.12-testing real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/156263/
http://logs.test-lab.xenproject.org/osstest/logs/156278/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could
Am Wed, 28 Oct 2020 10:39:55 +
schrieb Andrew Cooper :
> I would however recommend against the name is_data_page_type() because
> then the predicate is ambiguous with "== NOTAB".
Why is it ambiguous? It is not obvious to me.
page_type_has_stream_data() is certainly fine as a name.
Olaf
p
Hello Jan,
> On 28 Oct 2020, at 7:18 am, Jan Beulich wrote:
>
> On 28.10.2020 00:32, Stefano Stabellini wrote:
>> On Mon, 26 Oct 2020, Rahul Singh wrote:
>>> --- a/xen/drivers/char/Kconfig
>>> +++ b/xen/drivers/char/Kconfig
>>> @@ -4,6 +4,13 @@ config HAS_NS16550
>>> help
>>> This sele
On 28/10/2020 10:28, Olaf Hering wrote:
> Am Tue, 27 Oct 2020 23:18:47 +
> schrieb Andrew Cooper :
>
>> I suspect we probably want an is_known_page_type() predicate on the
>> source side to sanity check data from Xen, and on the destination side
>> in handle_page_data() to sanity check data in
Hello Stefano,
> On 27 Oct 2020, at 11:32 pm, Stefano Stabellini
> wrote:
>
> On Mon, 26 Oct 2020, Rahul Singh wrote:
>> ARM platforms does not support ns16550 PCI support. When CONFIG_HAS_PCI
>^ do
Ok I will fix that in next version.
>
>> is enabled for ARM a compilation erro
Am Tue, 27 Oct 2020 23:18:47 +
schrieb Andrew Cooper :
> I suspect we probably want an is_known_page_type() predicate on the
> source side to sanity check data from Xen, and on the destination side
> in handle_page_data() to sanity check data in the stream, and we
> probably want a page_type_h
Hi George,
> On 28 Oct 2020, at 09:43, George Dunlap wrote:
>
>
>
>> On Oct 28, 2020, at 8:43 AM, Bertrand Marquis
>> wrote:
>>
>>
>>
>>> On 27 Oct 2020, at 22:44, Stefano Stabellini wrote:
>>>
>>> On Mon, 26 Oct 2020, Bertrand Marquis wrote:
When a Cortex A57 processor is affected
flight 156274 xen-unstable-coverity real [real]
http://logs.test-lab.xenproject.org/osstest/logs/156274/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
xen 16a20963b3209788f2c0d3a3eebb7d92f03f5883
baseline version:
xen 6ca7
> On Oct 28, 2020, at 8:43 AM, Bertrand Marquis
> wrote:
>
>
>
>> On 27 Oct 2020, at 22:44, Stefano Stabellini wrote:
>>
>> On Mon, 26 Oct 2020, Bertrand Marquis wrote:
>>> When a Cortex A57 processor is affected by CPU errata 832075, a guest
>>> not implementing the workaround for it coul
flight 156262 xen-4.11-testing real [real]
flight 156275 xen-4.11-testing real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/156262/
http://logs.test-lab.xenproject.org/osstest/logs/156275/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could
By latching the old MFN into a local variable, these calculations don't
depend on anything but local variables anymore. Hence the point in time
when they get performed doesn't matter anymore, so they can be moved
past the locked region.
Signed-off-by: Jan Beulich
--- a/xen/arch/x86/mm/hap/hap.c
Fair parts of the present handlers are identical; in fact
nestedp2m_write_p2m_entry() lacks a call to p2m_entry_modify(). Move
common parts right into write_p2m_entry(), splitting the hooks into a
"pre" one (needed just by shadow code) and a "post" one.
For the common parts moved I think that the
When P2M_AUDIT is false, it's unused, so instead of having a dangling
NULL pointer sit there, omit the field altogether.
Instead of adding "#if P2M_AUDIT && defined(CONFIG_HVM)" in even more
places, fold the latter part right into the definition of P2M_AUDIT.
Signed-off-by: Jan Beulich
--- a/xe
The struct paging_mode instances get set to the same functions
regardless of mode by both HAP and shadow code, hence there's no point
having this hook there. The hook also doesn't need moving elsewhere - we
can directly use struct p2m_domain's. This merely requires (from a
strictly formal pov; in p
As it gets installed by p2m_pt_init(), it doesn't need to live in
paging.c. The function working in terms of l1_pgentry_t even further
indicates its non-paging-generic nature. Move it and drop its
paging_ prefix, not adding any new one now that it's static.
This then also makes more obvious that i
This started out with me getting confused by the two write_p2m_entry()
hooks we have - there really ought to be no more than one, or if two
were absolutely needed they imo would better have distinct names. Other
adjustment opportunities (and I hope they're improvements) were found
while getting rid
Hello,
When I tested the kprobes on Dom0 kernel, it caused a kernel panic.
Here is an example, to clarify the bug is in the single-stepping
(software-step exception), I added a printk() where the kprobes setup
single-stepping.
root@develbox:~# cd /sys/kernel/debug/tracing/
root@develbox:/sys/ker
> On 27 Oct 2020, at 22:44, Stefano Stabellini wrote:
>
> On Mon, 26 Oct 2020, Bertrand Marquis wrote:
>> When a Cortex A57 processor is affected by CPU errata 832075, a guest
>> not implementing the workaround for it could deadlock the system.
>> Add a warning during boot informing the user t
On 26.10.20 18:25, Andrew Cooper wrote:
Many CPUs will actually reload microcode when offered the same version as
currently loaded. This allows for easy testing of the late microcode loading
path.
Signed-off-by: Andrew Cooper
---
CC: Jan Beulich
CC: Roger Pau Monné
CC: Wei Liu
CC: Juergen G
On 26.10.2020 18:25, Andrew Cooper wrote:
> Many CPUs will actually reload microcode when offered the same version as
> currently loaded. This allows for easy testing of the late microcode loading
> path.
>
> Signed-off-by: Andrew Cooper
Reviewed-by: Jan Beulich
with one nit:
> @@ -2248,6 +22
On 26.10.2020 18:25, Andrew Cooper wrote:
> For Intel microcodes, the revision field is signed (as documented in the SDM)
> and negative revisions are used for pre-production/test microcode (not
> documented publicly anywhere I can spot).
>
> Adjust the revision checking to match the algorithm pre
On 26.10.2020 18:25, Andrew Cooper wrote:
> Drop some unnecesserily verbose pr_debug()'s on the AMD side.
To be honest I'm not entirely convinced of this part of the change:
For one, pr_debug() expands to nothing by default. And then you
delete 2/3 of all pr_debug() instances, putting under questi
flight 156261 xen-4.10-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/156261/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-arm64-arm64-xl-thunderx 3 hosts-allocate fail like 156033
test-amd64-amd64-xl-qemuu-dmrest
On 27.10.2020 20:30, Andrew Cooper wrote:
> On 27/10/2020 15:24, Jan Beulich wrote:
>> On 26.10.2020 14:50, Andrew Cooper wrote:
>>> The format of the Host State Area is, and has always been, a VMCB. It is
>>> explicitly safe to put the host VMSAVE data in.
>> Nit: The PM calls this "Host Save Are
On 27.10.2020 18:45, Oleksandr Andrushchenko wrote:
> On 10/27/20 7:18 PM, Jan Beulich wrote:
>> On 27.10.2020 16:52, Oleksandr Andrushchenko wrote:
>>> On 10/27/20 2:55 PM, Roger Pau Monné wrote:
On Tue, Oct 27, 2020 at 09:59:05AM +, Oleksandr Andrushchenko wrote:
> 5. An alternat
On 28.10.2020 03:04, Michał Leszczyński wrote:
> As I've said before, I'm using RELEASE-4.14.0, this is DELL PowerEdge R640
> with 14 PCPUs.
I.e. you haven't tried the tip of the 4.14 stable branch?
> I have the following additional pieces of log (enclosed below). As you could
> see, the issue
On 26.10.2020 18:17, Rahul Singh wrote:
> @@ -48,5 +50,27 @@ static inline int pci_ats_device(int seg, int bus, int
> devfn)
> return pci_find_ext_capability(seg, bus, devfn, PCI_EXT_CAP_ID_ATS);
> }
>
> +#else
> +
> +static inline int enable_ats_device(struct pci_dev *pdev,
> +
On 28.10.2020 00:55, Stefano Stabellini wrote:
> On Mon, 26 Oct 2020, Rahul Singh wrote:
>> --- a/xen/arch/x86/Kconfig
>> +++ b/xen/arch/x86/Kconfig
>> @@ -20,6 +20,7 @@ config X86
>> select HAS_NS16550
>> select HAS_PASSTHROUGH
>> select HAS_PCI
>> +select HAS_PCI_ATS
>From an
On 28.10.2020 00:32, Stefano Stabellini wrote:
> On Mon, 26 Oct 2020, Rahul Singh wrote:
>> --- a/xen/drivers/char/Kconfig
>> +++ b/xen/drivers/char/Kconfig
>> @@ -4,6 +4,13 @@ config HAS_NS16550
>> help
>>This selects the 16550-series UART support. For most systems, say Y.
>>
>> +co
77 matches
Mail list logo
