On 03.09.19 17:09, Jan Beulich wrote:
On 03.09.2019 17:03, Juergen Gross wrote:
On 03.09.19 16:53, Jan Beulich wrote:
On 29.08.2019 12:18, Juergen Gross wrote:
In order to have unique names when doing lock profiling several local
locks "lock" need to be renamed.
But these are all named
branch xen-unstable
xenbranch xen-unstable
job test-amd64-i386-pair
testid xen-boot/dst_host
Tree: linux git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git
Tree: linuxfirmware git://xenbits.xen.org/osstest/linux-firmware.git
Tree: ovmf git://xenbits.xen.org/osstest/ovmf.git
branch xen-unstable
xenbranch xen-unstable
job test-amd64-i386-xl-pvshim
testid xen-boot
Tree: linux git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git
Tree: linuxfirmware git://xenbits.xen.org/osstest/linux-firmware.git
Tree: ovmf git://xenbits.xen.org/osstest/ovmf.git
Tree:
flight 140971 linux-4.4 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/140971/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-pvshim 20 guest-start/debian.repeat fail in 140955 REGR.
vs. 139698
Tests
George,
> Are you up for taking a stab at something like `gengotypes.py`?
I have was able to make a bit of progress on this over the weekend. I've started
`gengotypes.py` in my branch[1]; the portion which generates `xenlight_types.go`
(the counterpart to _libxl_types.h) is mostly working.
The
If MCFG area is not reserved in E820, Xen by default will defer its usage
until Dom0 registers it explicitly after ACPI parser recognizes it as
a reserved resource in DSDT. Having it reserved in E820 is not
mandatory according to "PCI Firmware Specification, rev 3.2" (par. 4.1.2)
and firmware is
flight 140966 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/140966/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-pvshim 18 guest-localmigrate/x10 fail in 140905 REGR. vs.
140282
Tests
(Now with correct address for Juergen)
On 9/3/19 6:15 PM, Boris Ostrovsky wrote:
> On 9/2/19 9:03 AM, Christoph Hellwig wrote:
>> diff --git a/drivers/xen/swiotlb-xen.c b/drivers/xen/swiotlb-xen.c
>> index b8808677ae1d..f9dd4cb6e4b3 100644
>> --- a/drivers/xen/swiotlb-xen.c
>> +++
On 9/2/19 9:03 AM, Christoph Hellwig wrote:
> diff --git a/drivers/xen/swiotlb-xen.c b/drivers/xen/swiotlb-xen.c
> index b8808677ae1d..f9dd4cb6e4b3 100644
> --- a/drivers/xen/swiotlb-xen.c
> +++ b/drivers/xen/swiotlb-xen.c
> @@ -299,8 +299,7 @@ xen_swiotlb_alloc_coherent(struct device *hwdev,
flight 140980 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/140980/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-libvirt 13 migrate-support-checkfail never pass
test-armhf-armhf-xl
flight 140960 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/140960/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-pvshim 18 guest-localmigrate/x10 fail REGR. vs. 139876
build-amd64-xsm
On 02/09/2019 15:50, Jan Beulich wrote:
>>> I'm also not sure why you
>>> call them "unpredictable": If all (or most) cases match, the branch
>>> there could be pretty well predicted (subject of course to capacity).
>> Data-dependent branches which have no correlation to pattern history, of
>>
flight 140964 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/140964/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-armhf-armhf-libvirt 14 saverestore-support-checkfail like 140904
test-armhf-armhf-libvirt-raw 13
Folks,
I have not gotten around to draft an agenda yet. Please reply to this thread
with possible agenda items. I will reply to this thread with meeting invite and
details as usual
Regards
Lars
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
flight 140969 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/140969/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 8b8e91584555b6193f2099a36502763b47501533
baseline version:
ovmf
On Tue, Sep 3, 2019 at 9:53 AM Jan Beulich wrote:
>
> On 02.09.2019 10:11, Alexandru Stefan ISAILA wrote:
> > @@ -1355,6 +1355,23 @@ void p2m_init_altp2m_ept(struct domain *d, unsigned
> > int i)
> > ept = >ept;
> > ept->mfn = pagetable_get_pfn(p2m_get_pagetable(p2m));
> >
On 03/09/2019 17:14, Roger Pau Monne wrote:
> diff --git a/xen/arch/x86/hvm/ioreq.c b/xen/arch/x86/hvm/ioreq.c
> index 692b710b02..69652e1080 100644
> --- a/xen/arch/x86/hvm/ioreq.c
> +++ b/xen/arch/x86/hvm/ioreq.c
> @@ -1015,6 +1015,12 @@ int hvm_map_io_range_to_ioreq_server(struct domain *d,
>
flight 140959 linux-4.14 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/140959/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-pvshim 17 guest-saverestore.2 fail REGR. vs. 139910
build-amd64-xsm
Place the code that converts a PIO/COPY ioreq into a PCI_CONFIG one
into a separate function, and adjust the code to make use of this
newly introduced function.
No functional change intended.
Signed-off-by: Roger Pau Monné
---
Changes since v1:
- New in this version.
---
flight 140975 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/140975/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64 6 xen-buildfail REGR. vs. 140952
Tests which
hvm_select_ioreq_server and hvm_send_ioreq where both using
hvm_ioreq_server directly, switch to use ioservid_t in order to select
and forward ioreqs.
This is a preparatory change, since future patches will use the ioreq
server id in order to differentiate between internal and external
ioreq
Do not forward accesses to cf8 to external emulators, decoding of PCI
accesses is handled by Xen, and emulators can request handling of
config space accesses of devices using the provided ioreq interface.
Fully terminate cf8 accesses at the hypervisor level, by improving the
existing
Pick up on the infrastructure already added for vPCI and allow ioreq
to decode accesses to MMCFG regions registered for a domain. This
infrastructure is still only accessible from internal callers, so
MMCFG regions can only be registered from the internal domain builder
used by PVH dom0.
Note
Internal ioreq servers are plain function handlers implemented inside
of the hypervisor. Note that most fields used by current (external)
ioreq servers are not needed for internal ones, and hence have been
placed inside of a struct and packed in an union together with the
only internal specific
...and switch vPCI to use this infrastructure for long running
physmap modification operations.
This allows to get rid of the vPCI specific modifications done to
handle_hvm_io_completion and allows generalizing the support for
long-running operations to other internal ioreq servers. Such support
Such internal servers are implemented by a single function that handles
ioreqs inside the hypervisor.
The motivation behind this change is to switch vPCI to become an
internal ioreq server, so that accesses to the PCI config space can be
multiplexed between devices handled by vPCI and devices
Internal ioreq servers are always processed first, and ioreqs are
dispatched by calling the handler function. Note this is already the
case due to the implementation of FOR_EACH_IOREQ_SERVER.
Note that hvm_send_ioreq doesn't get passed the ioreq server id, so
obtain it from the ioreq server data
Add support for internal ioreq servers to initialization and
deinitialization routines, prevent some functions from being executed
against internal ioreq servers and add guards to only allow internal
callers to modify internal ioreq servers. External callers (ie: from
hypercalls) are only allowed
Switch vPCI to become an internal ioreq server, and hence drop all the
vPCI specific decoding and trapping to PCI IO ports and MMCFG regions.
This allows to unify the vPCI code with the ioreq infrastructure,
opening the door for domains having PCI accesses handled by vPCI and
other ioreq servers
The loop in FOR_EACH_IOREQ_SERVER is backwards hence the cleanup on
failure needs to be done forwards.
Fixes: 97a5a3e30161 ('x86/hvm/ioreq: maintain an array of ioreq servers rather
than a list')
Signed-off-by: Roger Pau Monné
---
Changes since v1:
- New in this version.
---
Provide a routine to register the handler for an internal ioreq
server.
Signed-off-by: Roger Pau Monné
---
Changes since v1:
- Allow to provide an opaque data parameter to pass to the handler.
- Allow changing the handler as long as the server is not enabled.
---
xen/arch/x86/hvm/ioreq.c
On Tue, Sep 03, 2019 at 05:13:38PM +0200, Jan Beulich wrote:
> On 03.09.2019 16:15, Roger Pau Monné wrote:
> > On Tue, Sep 03, 2019 at 03:58:08PM +0200, Jan Beulich wrote:
> >> --- a/xen/drivers/char/ns16550.c
> >> +++ b/xen/drivers/char/ns16550.c
> >> @@ -763,23 +763,16 @@ static void __init
On 02.09.2019 10:11, Alexandru Stefan ISAILA wrote:
> @@ -1355,6 +1355,23 @@ void p2m_init_altp2m_ept(struct domain *d, unsigned
> int i)
> ept = >ept;
> ept->mfn = pagetable_get_pfn(p2m_get_pagetable(p2m));
> d->arch.altp2m_eptp[i] = ept->eptp;
> +
> +if ( set_sve )
> +{
>
On 03.09.2019 16:15, Roger Pau Monné wrote:
> On Tue, Sep 03, 2019 at 03:58:08PM +0200, Jan Beulich wrote:
>> --- a/xen/drivers/char/ns16550.c
>> +++ b/xen/drivers/char/ns16550.c
>> @@ -763,23 +763,16 @@ static void __init ns16550_init_postirq(
>> #ifdef CONFIG_HAS_PCI
>> if ( uart->bar ||
On 03.09.2019 17:03, Juergen Gross wrote:
> On 03.09.19 16:53, Jan Beulich wrote:
>> On 29.08.2019 12:18, Juergen Gross wrote:
>>> In order to have unique names when doing lock profiling several local
>>> locks "lock" need to be renamed.
>>
>> But these are all named simply "lock" for a good
On 03.09.2019 16:38, Juergen Gross wrote:
> On 03.09.19 16:22, Jan Beulich wrote:
>> On 29.08.2019 12:18, Juergen Gross wrote:
>>> V2:
>>> - rename CONFIG_LOCK_PROFILE to CONFIG_DEBUG_LOCK_PROFILE (Jan Beulich)
>>> - move .lockprofile.data section to init area in linker scripts
>>
>> How can this
On 03.09.19 16:53, Jan Beulich wrote:
On 29.08.2019 12:18, Juergen Gross wrote:
In order to have unique names when doing lock profiling several local
locks "lock" need to be renamed.
But these are all named simply "lock" for a good reason, including
because they're all function scope symbols
On 03.09.2019 16:31, Juergen Gross wrote:
> On 03.09.19 16:11, Jan Beulich wrote:
>> On 29.08.2019 12:18, Juergen Gross wrote:
>>> --- a/xen/include/xen/spinlock.h
>>> +++ b/xen/include/xen/spinlock.h
>>> @@ -6,14 +6,21 @@
>>> #include
>>>
>>> #ifndef NDEBUG
>>> -struct lock_debug {
>>> -
On 29.08.2019 12:18, Juergen Gross wrote:
> In order to have unique names when doing lock profiling several local
> locks "lock" need to be renamed.
But these are all named simply "lock" for a good reason, including
because they're all function scope symbols (and typically the
functions are all
On 29.08.2019 12:18, Juergen Gross wrote:
> Today adding locks located in a struct to lock profiling requires a
> unique type index for each structure. This makes it hard to add any
> new structure as the related sysctl interface needs to be changed, too.
>
> Instead of using an index the already
On 03.09.19 16:22, Jan Beulich wrote:
On 29.08.2019 12:18, Juergen Gross wrote:
V2:
- rename CONFIG_LOCK_PROFILE to CONFIG_DEBUG_LOCK_PROFILE (Jan Beulich)
- move .lockprofile.data section to init area in linker scripts
How can this be correct, when you don't change lock_prof_init() at
all?
On 03.09.19 16:11, Jan Beulich wrote:
On 29.08.2019 12:18, Juergen Gross wrote:
--- a/xen/include/xen/spinlock.h
+++ b/xen/include/xen/spinlock.h
@@ -6,14 +6,21 @@
#include
#ifndef NDEBUG
-struct lock_debug {
-s16 irq_safe; /* +1: IRQ-safe; 0: not IRQ-safe; -1: don't know yet */
On 29.08.2019 12:18, Juergen Gross wrote:
> V2:
> - rename CONFIG_LOCK_PROFILE to CONFIG_DEBUG_LOCK_PROFILE (Jan Beulich)
> - move .lockprofile.data section to init area in linker scripts
How can this be correct, when you don't change lock_prof_init() at
all? The function builds a linked list
On Tue, Sep 03, 2019 at 03:58:08PM +0200, Jan Beulich wrote:
> The difference between pci_hide_device() and pci_ro_device() is that
> the former only prevents a device from getting assigned to a guest,
> while the latter additionally arranges for Dom0 write attempts to the
> device's config space
On 29.08.2019 12:18, Juergen Gross wrote:
> Instead of enabling debugging for debug builds only add a dedicated
> Kconfig option for that purpose which defaults to DEBUG.
>
> Signed-off-by: Juergen Gross
Reviewed-by: Jan Beulich
___
Xen-devel
On 29.08.2019 12:18, Juergen Gross wrote:
> --- a/xen/include/xen/spinlock.h
> +++ b/xen/include/xen/spinlock.h
> @@ -6,14 +6,21 @@
> #include
>
> #ifndef NDEBUG
> -struct lock_debug {
> -s16 irq_safe; /* +1: IRQ-safe; 0: not IRQ-safe; -1: don't know yet */
> +union lock_debug {
> +
A/D bit writes (on page walks) can be considered benign by an introspection
agent, so receiving vm_events for them is a pessimization. We try here to
optimize by filtering these events out.
Currently, we are fully emulating the instruction at RIP when the hardware sees
an EPT fault with npfec.kind
The difference between pci_hide_device() and pci_ro_device() is that
the former only prevents a device from getting assigned to a guest,
while the latter additionally arranges for Dom0 write attempts to the
device's config space to be ignored/discarded. Whether we want one or
the other certainly
On 03.09.19 13:50, Jan Beulich wrote:
On 03.09.2019 12:31, Juergen Gross wrote:
On 03.09.19 12:16, Jan Beulich wrote:
On 28.08.2019 10:00, Juergen Gross wrote:
+static unsigned int debugtrace_kilobytes = 128;
Since you touch this anyway, add __initdata? Maybe also move it
next to its
flight 140957 linux-4.19 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/140957/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-armhf-pvops 6 kernel-build fail REGR. vs. 129313
On 03.09.2019 14:34, Andrew Cooper wrote:
> On 03/09/2019 10:41, Jan Beulich wrote:
>> While the PM doesn't say so, this assumes that the MPERF value read this
>> way gets scaled similarly to its reading through RDMSR.
>>
>> Signed-off-by: Jan Beulich
>
> This wants the following hunks merged,
On 03.09.2019 14:51, Roger Pau Monné wrote:
> On Tue, Sep 03, 2019 at 02:16:52PM +0200, Jan Beulich wrote:
>> On 03.09.2019 12:14, Roger Pau Monne wrote:
>>> Don't allow the hardware domain write access the PCI config space of
>>> devices marked as read-only.
>>>
>>> Signed-off-by: Roger Pau
On Tue, Sep 03, 2019 at 02:16:52PM +0200, Jan Beulich wrote:
> On 03.09.2019 12:14, Roger Pau Monne wrote:
> > Don't allow the hardware domain write access the PCI config space of
> > devices marked as read-only.
> >
> > Signed-off-by: Roger Pau Monné
> > ---
> > Changes since v2:
> > - Fix
> On 2 Sep 2019, at 15:50, Paul Durrant wrote:
>
> tools/ocaml/libs/xc/xenctrl.ml| 8 +++-
> tools/ocaml/libs/xc/xenctrl.mli | 8 +++-
Acked-by: Christian Lindig
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
On 03.09.2019 14:22, Juergen Gross wrote:
> On 03.09.19 14:09, Jan Beulich wrote:
>> On 03.09.2019 13:58, Juergen Gross wrote:
>>> On 03.09.19 13:47, Jan Beulich wrote:
On 03.09.2019 12:22, Juergen Gross wrote:
> On 03.09.19 12:00, Jan Beulich wrote:
>> On 28.08.2019 10:00, Juergen
On 03/09/2019 10:41, Jan Beulich wrote:
> While the PM doesn't say so, this assumes that the MPERF value read this
> way gets scaled similarly to its reading through RDMSR.
>
> Signed-off-by: Jan Beulich
This wants the following hunks merged, to at least keep the
intercept/exit codes up to
On 03.09.2019 12:28, Andrew Cooper wrote:
> On 03/09/2019 10:39, Jan Beulich wrote:
>> Note that SDM revision 070 doesn't specify exception behavior for
>> ModRM.mod != 0b11; assuming #UD here.
>>
>> Signed-off-by: Jan Beulich
>
> What are we going to do about the ->write() hook atomicity? I'm
On 03.09.2019 12:18, Andrew Cooper wrote:
> On 03/09/2019 10:37, Jan Beulich wrote:
>> The only place we'd expect the insn to be sensibly used is in
>> (virtualization unaware) firmware.
>>
>> Suggested-by: Andrew Cooper
>> Signed-off-by: Jan Beulich
>> ---
>> v3: New.
>>
>> ---
On 03.09.19 14:09, Jan Beulich wrote:
On 03.09.2019 13:58, Juergen Gross wrote:
On 03.09.19 13:47, Jan Beulich wrote:
On 03.09.2019 12:22, Juergen Gross wrote:
On 03.09.19 12:00, Jan Beulich wrote:
On 28.08.2019 10:00, Juergen Gross wrote:
Today dumping the debugtrace buffers is done via
flight 140950 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/140950/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-examine 8 reboot fail REGR. vs. 133580
On 03.09.2019 12:14, Roger Pau Monne wrote:
> Don't allow the hardware domain write access the PCI config space of
> devices marked as read-only.
>
> Signed-off-by: Roger Pau Monné
> ---
> Changes since v2:
> - Fix test harness.
> - Do the RO check before the ownership one.
>
> Changes since
On 03.09.19 14:01, Jan Beulich wrote:
On 03.09.2019 13:10, Juergen Gross wrote:
On 03.09.19 12:51, Jan Beulich wrote:
On 28.08.2019 10:00, Juergen Gross wrote:
+static void debugtrace_dump_buffer(struct debugtrace_data_s *data,
+ const char *which)
{
-
On 03.09.2019 13:58, Juergen Gross wrote:
> On 03.09.19 13:47, Jan Beulich wrote:
>> On 03.09.2019 12:22, Juergen Gross wrote:
>>> On 03.09.19 12:00, Jan Beulich wrote:
On 28.08.2019 10:00, Juergen Gross wrote:
> Today dumping the debugtrace buffers is done via sercon_puts(), while
>
On 03.09.2019 13:10, Juergen Gross wrote:
> On 03.09.19 12:51, Jan Beulich wrote:
>> On 28.08.2019 10:00, Juergen Gross wrote:
>>> +static void debugtrace_dump_buffer(struct debugtrace_data_s *data,
>>> + const char *which)
>>> {
>>> -if ( !debtr_data ||
On 03.09.19 13:47, Jan Beulich wrote:
On 03.09.2019 12:22, Juergen Gross wrote:
On 03.09.19 12:00, Jan Beulich wrote:
On 28.08.2019 10:00, Juergen Gross wrote:
Today dumping the debugtrace buffers is done via sercon_puts(), while
direct printing of trace entries (after toggling output to the
On 03.09.2019 12:31, Juergen Gross wrote:
> On 03.09.19 12:16, Jan Beulich wrote:
>> On 28.08.2019 10:00, Juergen Gross wrote:
>>> +static unsigned int debugtrace_kilobytes = 128;
>>
>> Since you touch this anyway, add __initdata? Maybe also move it
>> next to its integer_param()?
>
> This is
On 02.09.19 17:57, Christoph Hellwig wrote:
On Fri, Aug 30, 2019 at 07:40:42PM -0700, Stefano Stabellini wrote:
+ Juergen, Boris
On Fri, 30 Aug 2019, Christoph Hellwig wrote:
Can we take a step back and figure out what we want to do here?
AFAICS this function allocates memory for the
On 03.09.2019 12:22, Juergen Gross wrote:
> On 03.09.19 12:00, Jan Beulich wrote:
>> On 28.08.2019 10:00, Juergen Gross wrote:
>>> Today dumping the debugtrace buffers is done via sercon_puts(), while
>>> direct printing of trace entries (after toggling output to the console)
>>> is using
On 03.09.19 12:51, Jan Beulich wrote:
On 28.08.2019 10:00, Juergen Gross wrote:
@@ -24,32 +25,62 @@ struct debugtrace_data_s {
};
static struct debugtrace_data_s *debtr_data;
+static DEFINE_PER_CPU(struct debugtrace_data_s *, debtr_cpu_data);
-static unsigned int debugtrace_kilobytes
On 28.08.2019 10:00, Juergen Gross wrote:
> @@ -24,32 +25,62 @@ struct debugtrace_data_s {
> };
>
> static struct debugtrace_data_s *debtr_data;
> +static DEFINE_PER_CPU(struct debugtrace_data_s *, debtr_cpu_data);
>
> -static unsigned int debugtrace_kilobytes = 128;
> +static unsigned int
On 03.09.19 12:16, Jan Beulich wrote:
On 28.08.2019 10:00, Juergen Gross wrote:
As a preparation for per-cpu buffers do a little refactoring of the
debugtrace data: put the needed buffer admin data into the buffer as
it will be needed for each buffer.
While at it switch
On 03/09/2019 10:39, Jan Beulich wrote:
> Note that SDM revision 070 doesn't specify exception behavior for
> ModRM.mod != 0b11; assuming #UD here.
>
> Signed-off-by: Jan Beulich
What are we going to do about the ->write() hook atomicity? I'm happy
to put it on the TODO list, but we can't
On 03.09.19 12:00, Jan Beulich wrote:
On 28.08.2019 10:00, Juergen Gross wrote:
Today dumping the debugtrace buffers is done via sercon_puts(), while
direct printing of trace entries (after toggling output to the console)
is using serial_puts().
Use sercon_puts() in both cases, as the
On 03/09/2019 10:37, Jan Beulich wrote:
> The only place we'd expect the insn to be sensibly used is in
> (virtualization unaware) firmware.
>
> Suggested-by: Andrew Cooper
> Signed-off-by: Jan Beulich
> ---
> v3: New.
>
> --- a/xen/arch/x86/hvm/emulate.c
> +++ b/xen/arch/x86/hvm/emulate.c
> @@
On 03/09/2019 10:37, Jan Beulich wrote:
> Rev 037 of Intel's ISA extensions document does not state intercept
> behavior for the insn (I've been unofficially told that the distinction
> is going to be by exit qualification, as I would have assumed
> considering that this way it's sufficiently
On 28.08.2019 10:00, Juergen Gross wrote:
> As a preparation for per-cpu buffers do a little refactoring of the
> debugtrace data: put the needed buffer admin data into the buffer as
> it will be needed for each buffer.
>
> While at it switch debugtrace_send_to_console and debugtrace_used to
>
Don't allow the hardware domain write access the PCI config space of
devices marked as read-only.
Signed-off-by: Roger Pau Monné
---
Changes since v2:
- Fix test harness.
- Do the RO check before the ownership one.
Changes since v1:
- Change the approach and allow full read access, while
On 28.08.2019 10:00, Juergen Gross wrote:
> Instead of living in drivers/char/console.c move the debugtrace
> related coding to a new file common/debugtrace.c
>
> No functional change, code movement only.
>
> Signed-off-by: Juergen Gross
Acked-by: Jan Beulich
On 28.08.2019 10:00, Juergen Gross wrote:
> Today dumping the debugtrace buffers is done via sercon_puts(), while
> direct printing of trace entries (after toggling output to the console)
> is using serial_puts().
>
> Use sercon_puts() in both cases, as the difference between both is not
> really
On Tue, Sep 03, 2019 at 11:48:19AM +0200, Jan Beulich wrote:
> On 03.09.2019 11:28, Roger Pau Monné wrote:
> > On Tue, Sep 03, 2019 at 11:09:09AM +0200, Jan Beulich wrote:
> >> On 02.09.2019 17:30, Roger Pau Monne wrote:
> >>> --- a/xen/drivers/vpci/vpci.c
> >>> +++ b/xen/drivers/vpci/vpci.c
>
On 03.09.2019 11:28, Roger Pau Monné wrote:
> On Tue, Sep 03, 2019 at 11:09:09AM +0200, Jan Beulich wrote:
>> On 02.09.2019 17:30, Roger Pau Monne wrote:
>>> --- a/xen/drivers/vpci/vpci.c
>>> +++ b/xen/drivers/vpci/vpci.c
>>> @@ -418,13 +418,21 @@ void vpci_write(pci_sbdf_t sbdf, unsigned int
> -Original Message-
> From: Jan Beulich
> Sent: 03 September 2019 10:38
> To: xen-devel@lists.xenproject.org
> Cc: Andrew Cooper ; Paul Durrant
> ; Roger Pau Monne
> ; Wei Liu
> Subject: [PATCH v3 2/8] x86/HVM: ignore guest INVD uses
>
> The only place we'd expect the insn to be
If the hardware can handle accesses, we should allow it to do so. This
way we can expose EFRO to HVM guests, and "all" that's left for exposing
APERF/MPERF is to figure out how to handle writes to these MSRs. (Note
that the leaf 6 guest CPUID checks will evaluate to false for now, as
While the PM doesn't say so, this assumes that the MPERF value read this
way gets scaled similarly to its reading through RDMSR.
Signed-off-by: Jan Beulich
---
v3: New.
--- a/tools/libxl/libxl_cpuid.c
+++ b/tools/libxl/libxl_cpuid.c
@@ -257,6 +257,7 @@ int libxl_cpuid_parse_config(libxl_cpuid
AMD's PM specifies that MPERF (and its r/o counterpart) reads are
affected by the TSC ratio. Hence when processing such reads in software
we too should scale the values. While we don't currently (yet) expose
the underlying feature flags, besides us allowing the MSRs to be read
nevertheless, RDPRU
Note that SDM revision 070 doesn't specify exception behavior for
ModRM.mod != 0b11; assuming #UD here.
Signed-off-by: Jan Beulich
---
v3: Update description.
--- a/tools/tests/x86_emulator/test_x86_emulator.c
+++ b/tools/tests/x86_emulator/test_x86_emulator.c
@@ -2196,6 +2196,36 @@ int
The hook is already in use for INVLPGA as well. Rename the hook and add
parameters. For the moment INVLPGA with a non-zero ASID remains
unsupported, but the TODO item gets pushed into the actual hook handler.
Signed-off-by: Jan Beulich
Reviewed-by: Paul Durrant
Reviewed-by: Andrew Cooper
---
Just like for INVLPGA the HVM hook only supports PCID 0 for the time
being for individual address invalidation. It also translates the other
types to a full flush, which is architecturally permitted and
performance-wise presumably not much worse because emulation is slow
anyway.
Signed-off-by:
The only place we'd expect the insn to be sensibly used is in
(virtualization unaware) firmware.
Suggested-by: Andrew Cooper
Signed-off-by: Jan Beulich
---
v3: New.
--- a/xen/arch/x86/hvm/emulate.c
+++ b/xen/arch/x86/hvm/emulate.c
@@ -2210,11 +2210,18 @@ static int hvmemul_cache_op(
Rev 037 of Intel's ISA extensions document does not state intercept
behavior for the insn (I've been unofficially told that the distinction
is going to be by exit qualification, as I would have assumed
considering that this way it's sufficiently transparent to unaware
software, as using WBINVD in
1: x86emul: support WBNOINVD
2: x86/HVM: ignore guest INVD uses
3: x86emul: generalize invlpg() hook
4: x86emul: support INVPCID
5: x86emul: support MOVDIR{I,64B} insns
6: x86/HVM: scale MPERF values reported to guests (on AMD)
7: x86emul: support RDPRU
8: x86/HVM: don't needlessly intercept
On Tue, Sep 03, 2019 at 11:09:09AM +0200, Jan Beulich wrote:
> On 02.09.2019 17:30, Roger Pau Monne wrote:
> > --- a/xen/drivers/vpci/vpci.c
> > +++ b/xen/drivers/vpci/vpci.c
> > @@ -418,13 +418,21 @@ void vpci_write(pci_sbdf_t sbdf, unsigned int reg,
> > unsigned int size,
> > return;
>
On 03/09/2019 08:54, Jan Beulich wrote:
> On 02.09.2019 20:27, Edwin Török wrote:
>> On a Intel(R) Xeon(R) CPU E5-2697 v3 @ 2.60GHz the host frequency drifts:
>> ```
>> (XEN) [6.607693] Detected 2600.004 MHz processor.
>> (XEN) [ 2674.213081] dom1(hvm):
>>
flight 140955 linux-4.4 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/140955/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-pvshim 20 guest-start/debian.repeat fail REGR. vs. 139698
build-amd64-xsm
On 02.09.2019 17:30, Roger Pau Monne wrote:
> --- a/xen/drivers/vpci/vpci.c
> +++ b/xen/drivers/vpci/vpci.c
> @@ -418,13 +418,21 @@ void vpci_write(pci_sbdf_t sbdf, unsigned int reg,
> unsigned int size,
> return;
> }
>
> -/*
> - * Find the PCI dev matching the address.
>
On 02.09.2019 20:27, Edwin Török wrote:
> On a Intel(R) Xeon(R) CPU E5-2697 v3 @ 2.60GHz the host frequency drifts:
> ```
> (XEN) [6.607693] Detected 2600.004 MHz processor.
> (XEN) [ 2674.213081] dom1(hvm):
> mode=0,ofs=0xfffee6f70b7faa48,khz=2600018,inc=3
> (XEN) [ 2674.213087] dom2(hvm):
On 03.09.2019 07:15, Juergen Gross wrote:
> Several public headers of the hypervisor contain structures with
> variable length arrays. In order to be usable with different compilers
> those definitions are depending on the compiler type and the standard
> supported by the compiler.
>
> In order
At 15:50 +0100 on 02 Sep (1567439409), Paul Durrant wrote:
> The flag is not needed since the domain 'options' can now be tested
> directly.
>
> Signed-off-by: Paul Durrant
Acked-by: Tim Deegan
___
Xen-devel mailing list
The Makefile below tools/libs have a lot in common. Put those common
parts into a new libs.mk and include that from the specific Makefiles.
Signed-off-by: Juergen Gross
---
tools/libs/call/Makefile | 86 ++-
tools/libs/devicemodel/Makefile | 88
99 matches
Mail list logo
