(Sorry for the formatting)
On 23 Mar 2018 14:46, "Manish Jaggi" wrote:
On 03/21/2018 03:26 PM, Julien Grall wrote:
> Hi Manish,
>
> On 03/21/2018 09:38 AM, Manish Jaggi wrote:
>
>>
>>
>> On 03/21/2018 02:15 PM, Julien Grall wrote:
>>
>>>
>>>
>>> On 03/21/2018 04:58 AM, Manish Jaggi wrote:
>>>
On 03/21/2018 03:26 PM, Julien Grall wrote:
Hi Manish,
On 03/21/2018 09:38 AM, Manish Jaggi wrote:
On 03/21/2018 02:15 PM, Julien Grall wrote:
On 03/21/2018 04:58 AM, Manish Jaggi wrote:
Hi Julien,
On 03/20/2018 01:16 PM, Julien Grall wrote:
On 03/16/2018 11:58 AM, Manish Jaggi wro
flight 121046 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/121046/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 2f1b849dc82f01ba5df198715f52dd6a0a8051c0
baseline version:
ovmf df67a480eb81821ba21ad
Hi,
On 03/23/2018 04:17 AM, Manish Jaggi wrote:
On 03/23/2018 06:58 AM, Julien Grall wrote:
On 03/13/2018 03:20 PM, mja...@caviumnetworks.com wrote:
+ *
+ * fwits_node - ITS Node pointer in Firmware IORT
+ * offset - offset of the equivalent its node to be stored in
+ * hwdom'
On 03/23/2018 06:58 AM, Julien Grall wrote:
Hi Manish,
On 03/13/2018 03:20 PM, mja...@caviumnetworks.com wrote:
From: Manish Jaggi
Structure of Hardware domain's (hwdom) IORT
hwdom's IORT will only have PCIRC nodes and ITS group nodes
in the following order. SMMU nodes as they are hidden f
flight 121015 xen-4.9-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/121015/
Failures :-/ but no regressions.
Regressions which are regarded as allowable (not blocking):
test-armhf-armhf-xl-rtds 12 guest-start fail REGR. vs. 12
Tests which did not succ
Hello,
Apologies for the late answer.
On 03/16/2018 02:39 PM, Naveed Asmat wrote:
Hi,
I am new to Xen and trying to understand how does the VGA passthrough
will work on a ARM based hardware.
I am not sure what you mean by VGA passthrough. Do you want to
passthrough the graphic device? If
flight 121012 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/121012/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-armhf-libvirt broken
test-amd64-i386-xl-xsm7 xen-boot
Hi Manish,
On 03/13/2018 03:20 PM, mja...@caviumnetworks.com wrote:
From: Manish Jaggi
Structure of Hardware domain's (hwdom) IORT
hwdom's IORT will only have PCIRC nodes and ITS group nodes
in the following order. SMMU nodes as they are hidden from hardware
domain.
[IORT Header]
[ITS Group
Hi Roger,
On 03/22/2018 01:58 PM, Roger Pau Monne wrote:
This is needed for MSI-X, since MSI-X will need to be initialized
before parsing the BARs, so that the header BAR handlers are aware of
the MSI-X related holes and make sure they are not mapped in order for
the trap handlers to work proper
Hi,
On 03/22/2018 03:12 PM, Andre Przywara wrote:
Hi,
On 22/03/18 14:06, Julien Grall wrote:
Hi Andre,
On 03/22/2018 11:56 AM, Andre Przywara wrote:
+ /* The locking order forces us to drop and re-take the locks
here. */
+ if ( irq->hw )
+ {
+ spin_unlock(&irq
flight 121031 xen-4.6-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/121031/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-xtf-amd64-amd64-3 50 xtf/test-hvm64-lbr-tsx-vmentry fail REGR. vs. 119227
test-amd64-amd6
On Thu, 22 Mar 2018, Lars Kurth wrote:
> On 22/03/2018, 14:49, "Julien Grall" wrote:
>
> >> -
> >>
> >> I think we need to discuss PCI emulation and our future direction. Our
> current hybrid with QEMU is becoming increasingly problematic.
> >
> > +1
>
> I thin
flight 121042 rumprun real [real]
http://logs.test-lab.xenproject.org/osstest/logs/121042/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-rumprun 6 rumprun-buildfail REGR. vs. 106754
build-i386-rumprun
flight 121068 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/121068/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-libvirt 13 migrate-support-checkfail never pass
test-arm64-arm64-xl-xsm 1
On 22/03/2018 20:29, Michael S. Tsirkin wrote:
> On Wed, Mar 21, 2018 at 05:22:03PM +0100, Kevin Wolf wrote:
>>> It's all still very much a non-standard convention and so less robust
>>> than prefixing file name with a project-specifix prefix.
>> I've always had the impression that it's by far the
On Thu, Mar 22, 2018 at 02:42:55PM -0500, Eric Blake wrote:
> On 03/22/2018 02:27 PM, Michael S. Tsirkin wrote:
> > Make sure all generated files go into qemu-build subdirectory.
> > We can then include them like this:
> > #include "qemu-build/trace.h"
> >
> > This serves two purposes:
> > - mak
On 03/22/2018 02:27 PM, Michael S. Tsirkin wrote:
Make sure all generated files go into qemu-build subdirectory.
We can then include them like this:
#include "qemu-build/trace.h"
This serves two purposes:
- make it easy to detect which files are in the source
directory (a bit more work for
On Wed, Mar 21, 2018 at 05:22:03PM +0100, Kevin Wolf wrote:
> > It's all still very much a non-standard convention and so less robust
> > than prefixing file name with a project-specifix prefix.
>
> I've always had the impression that it's by far the most common
> convention, to the point that I'd
Make sure all generated files go into qemu-build subdirectory.
We can then include them like this:
#include "qemu-build/trace.h"
This serves two purposes:
- make it easy to detect which files are in the source
directory (a bit more work for writers, easier for readers)
- reduce chances of confl
c/s 65e35549 "x86/PV: support data breakpoint extension registers"
accidentally broke the handing of writes. The call to activate_debugregs()
doesn't write %dr7 as v->arch.debugreg[7] hasn't been updated yet, and the
break skips the intended write to %dr7.
Remove the break, causing execution to h
flight 121065 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/121065/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-libvirt 13 migrate-support-checkfail never pass
test-arm64-arm64-xl-xsm 1
docs/qemu-deprivilege.txt had some basic instructions for using
dm_restrict, but it was incomplete, misleading, and stale.
Update the docs in a number of ways.
Introduce a section mentioning minimim versions of Linux, Xen, and
qemu required (TBD)
Fix the discussion of qemu userid. Mention xen-q
On 22/03/18 17:30, Jan Beulich wrote:
On 21.03.18 at 13:51, wrote:
>> Instead of flushing the TLB from global pages when switching address
>> spaces with XPTI being active just disable global pages via %cr4
>> completely when a domain subject to XPTI is active. This avoids the
>> need for ext
On Wed, Mar 14, 2018 at 02:29:17PM +, Anthony PERARD wrote:
> Hi,
>
> In an xl guest config, we have the "usbdevice" option. It is just
> passthrough to QEMU "-usbdevice" without parsing. The QEMU option is now
> deprecated. v2.11 (to be released with Xen 4.11) is the last version of
> QEMU to
flight 120994 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/120994/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-qemuu-nested-intel 14 xen-boot/l1 fail REGR. vs. 120095
test-amd64-amd64-
On 22/03/18 16:44, Jan Beulich wrote:
On 22.03.18 at 16:29, wrote:
>> On 22/03/18 16:26, Jan Beulich wrote:
>> On 21.03.18 at 13:51, wrote:
+void xpti_domain_init(struct domain *d)
+{
+if ( !is_pv_domain(d) || is_pv_32bit_domain(d) )
+return;
>>>
>>> As yo
On 22/03/18 16:35, Jan Beulich wrote:
On 21.03.18 at 13:51, wrote:
>> --- a/docs/misc/xen-command-line.markdown
>> +++ b/docs/misc/xen-command-line.markdown
>> @@ -1380,6 +1380,14 @@ Because responsibility for APIC setup is shared
>> between Xen and the
>> domain 0 kernel this option is aut
>>> On 21.03.18 at 13:51, wrote:
> Instead of flushing the TLB from global pages when switching address
> spaces with XPTI being active just disable global pages via %cr4
> completely when a domain subject to XPTI is active. This avoids the
> need for extra TLB flushes as loading %cr3 will remove
Hi,
On 22/03/18 14:06, Julien Grall wrote:
> Hi Andre,
>
> On 03/22/2018 11:56 AM, Andre Przywara wrote:
>> + /* The locking order forces us to drop and re-take the locks
>> here. */
>> + if ( irq->hw )
>> + {
>> + spin_unlock(&irq->irq_lock);
>> +
>> +
>>> On 22.03.18 at 16:29, wrote:
> On 22/03/18 16:26, Jan Beulich wrote:
> On 21.03.18 at 13:51, wrote:
>>> +void xpti_domain_init(struct domain *d)
>>> +{
>>> +if ( !is_pv_domain(d) || is_pv_32bit_domain(d) )
>>> +return;
>>
>> As you rely on the zero-initialization of the field
>>> On 22.03.18 at 16:26, wrote:
> On 22/03/18 15:31, Jan Beulich wrote:
> On 21.03.18 at 13:51, wrote:
>>> void write_ptbase(struct vcpu *v)
>>> {
>>> +if ( this_cpu(root_pgt) && is_pv_vcpu(v) && !is_pv_32bit_vcpu(v) )
>>> +get_cpu_info()->root_pgt_changed = true;
>>> writ
>>> On 21.03.18 at 13:51, wrote:
> --- a/docs/misc/xen-command-line.markdown
> +++ b/docs/misc/xen-command-line.markdown
> @@ -1380,6 +1380,14 @@ Because responsibility for APIC setup is shared
> between Xen and the
> domain 0 kernel this option is automatically propagated to the domain
> 0 com
On 22/03/18 15:12, Jan Beulich wrote:
> Paul,
>
> our PV driver person has found a reproducible crash with ws2k8,
> triggered by one of the WHQL tests. The guest get crashed because
> the re-issue check of an ioreq close to the top of hvmemul_do_io()
> fails. I've handed him a first debugging patch
On Thu, 22 Mar 2018 12:44:02 +
Roger Pau Monné wrote:
>On Thu, Mar 22, 2018 at 10:29:22PM +1000, Alexey G wrote:
>> On Thu, 22 Mar 2018 09:57:16 +
>> Roger Pau Monné wrote:
>> [...]
>> >> Yes, and it is still needed as we have two distinct (and not
>> >> equal) interfaces to PCI conf s
flight 121061 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/121061/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-armhf broken
build-armhf
On 22/03/18 16:26, Jan Beulich wrote:
On 21.03.18 at 13:51, wrote:
>> +void xpti_domain_init(struct domain *d)
>> +{
>> +if ( !is_pv_domain(d) || is_pv_32bit_domain(d) )
>> +return;
>
> As you rely on the zero-initialization of the field here, ...
>
>> +switch ( opt_xpti )
>
On 22/03/18 15:31, Jan Beulich wrote:
On 21.03.18 at 13:51, wrote:
>> --- a/xen/arch/x86/flushtlb.c
>> +++ b/xen/arch/x86/flushtlb.c
>> @@ -158,6 +158,9 @@ unsigned int flush_area_local(const void *va, unsigned
>> int flags)
>> }
>> }
>>
>> +if ( flags & FLUSH_ROOT_PGTBL
>>> On 21.03.18 at 13:51, wrote:
> +void xpti_domain_init(struct domain *d)
> +{
> +if ( !is_pv_domain(d) || is_pv_32bit_domain(d) )
> +return;
As you rely on the zero-initialization of the field here, ...
> +switch ( opt_xpti )
> +{
> +case XPTI_OFF:
> +d->arch.p
Hi,
On 22/03/18 14:06, Julien Grall wrote:
> Hi Andre,
>
> On 03/22/2018 11:56 AM, Andre Przywara wrote:
>> + /* The locking order forces us to drop and re-take the locks
>> here. */
>> + if ( irq->hw )
>> + {
>> + spin_unlock(&irq->irq_lock);
>> +
>> +
Paul,
our PV driver person has found a reproducible crash with ws2k8,
triggered by one of the WHQL tests. The guest get crashed because
the re-issue check of an ioreq close to the top of hvmemul_do_io()
fails. I've handed him a first debugging patch, output of which
suggests that we're dealing wit
On Thu, 22 Mar 2018 08:42:09 -0600
"Jan Beulich" wrote:
On 22.03.18 at 15:34, wrote:
>> On Thu, 22 Mar 2018 07:20:00 -0600
>> "Jan Beulich" wrote:
>>
>> On 22.03.18 at 14:05, wrote:
On Thu, 22 Mar 2018 06:09:44 -0600
"Jan Beulich" wrote:
On 22.03
On 22/03/18 14:41, Roger Pau Monné wrote:
> On Thu, Mar 22, 2018 at 08:40:04AM -0600, Jan Beulich wrote:
>> This clearly wasn't meant the way it was originally written.
>>
>> Reported-by: Roger Pau Monné
>> Signed-off-by: Jan Beulich
> Reviewed-by: Roger Pau Monné
Acked-by: Andrew Cooper
>>> On 21.03.18 at 13:51, wrote:
> When switching to a 64-bit pv context the TLB is flushed twice today:
> the first time when switching to the new address space in
> write_ptbase(), the second time when switching to guest mode in
> restore_to_guest.
>
> Avoid the first TLB flush in that case.
>
>>> On 22.03.18 at 15:34, wrote:
> On Thu, 22 Mar 2018 07:20:00 -0600
> "Jan Beulich" wrote:
>
> On 22.03.18 at 14:05, wrote:
>>> On Thu, 22 Mar 2018 06:09:44 -0600
>>> "Jan Beulich" wrote:
>>>
>>> On 22.03.18 at 12:56, wrote:
> I really don't understand why some people h
On Thu, Mar 22, 2018 at 08:40:04AM -0600, Jan Beulich wrote:
> This clearly wasn't meant the way it was originally written.
>
> Reported-by: Roger Pau Monné
> Signed-off-by: Jan Beulich
Reviewed-by: Roger Pau Monné
___
Xen-devel mailing list
Xen-dev
This clearly wasn't meant the way it was originally written.
Reported-by: Roger Pau Monné
Signed-off-by: Jan Beulich
--- a/xen/arch/x86/x86_emulate/x86_emulate.c
+++ b/xen/arch/x86/x86_emulate/x86_emulate.c
@@ -8662,7 +8662,7 @@ x86_emulate(
{
unsigned long cr4;
-if ( !o
>>> On 22.03.18 at 15:12, wrote:
> On Thu, Mar 15, 2018 at 07:06:36AM -0600, Jan Beulich wrote:
>> @@ -8478,7 +8411,8 @@ x86_emulate(
>> }
>>
>> complete_insn: /* Commit shadow register state. */
>> -put_fpu(&fic, false, state, ctxt, ops);
>> +put_fpu(fpu_type, false, state, ctxt,
On Thu, 22 Mar 2018 07:20:00 -0600
"Jan Beulich" wrote:
On 22.03.18 at 14:05, wrote:
>> On Thu, 22 Mar 2018 06:09:44 -0600
>> "Jan Beulich" wrote:
>>
>> On 22.03.18 at 12:56, wrote:
I really don't understand why some people have that fear of
emulated MMCONFIG -- it'
>>> On 21.03.18 at 13:51, wrote:
> --- a/xen/arch/x86/flushtlb.c
> +++ b/xen/arch/x86/flushtlb.c
> @@ -158,6 +158,9 @@ unsigned int flush_area_local(const void *va, unsigned
> int flags)
> }
> }
>
> +if ( flags & FLUSH_ROOT_PGTBL )
> +get_cpu_info()->root_pgt_changed =
On Thu, Mar 15, 2018 at 07:06:36AM -0600, Jan Beulich wrote:
> @@ -8478,7 +8411,8 @@ x86_emulate(
> }
>
> complete_insn: /* Commit shadow register state. */
> -put_fpu(&fic, false, state, ctxt, ops);
> +put_fpu(fpu_type, false, state, ctxt, ops);
> +fpu_type = X86EMUL_FPU_none;
On 03/22/2018 12:24 PM, Tim Deegan wrote:
Hi,
Hi Tim,
At 04:47 + on 21 Mar (1521607657), Julien Grall wrote:
Most of the users of page_to_mfn and mfn_to_page are either overriding
the macros to make them work with mfn_t or use mfn_x/_mfn because the
rest of the function use mfn_t.
So
Hi Andre,
On 03/22/2018 11:56 AM, Andre Przywara wrote:
+/* The locking order forces us to drop and re-take the locks here. */
+if ( irq->hw )
+{
+spin_unlock(&irq->irq_lock);
+
+desc = irq_to_desc(irq->hwintid);
+spin_lock(&desc->lock)
Removing the non-working Intel alias
@John: once this alias actually works, let me know.
The start of the thread is at
https://lists.xenproject.org/archives/html/xen-devel/2018-03/threads.html#02672
@All:
To summarize in terms of higher level discussions:
* Discuss PCI emulation and our future
So that MMCFG regions not present in the MCFG ACPI table can be added
at run time by the hardware domain.
Signed-off-by: Roger Pau Monné
Reviewed-by: Jan Beulich
Reviewed-by: Paul Durrant
---
Cc: Jan Beulich
Cc: Andrew Cooper
Cc: Paul Durrant
---
Changes since v7:
- Add newline in hvm_physd
When a MSI device with per-vector masking capabilities is detected or
added to Xen all the vectors are masked when initializing it. This
implies that the first time the interrupt is bound to a domain it's
masked.
This however only applies to the first time the interrupt is bound
because neither th
This is needed for MSI-X, since MSI-X will need to be initialized
before parsing the BARs, so that the header BAR handlers are aware of
the MSI-X related holes and make sure they are not mapped in order for
the trap handlers to work properly.
Signed-off-by: Roger Pau Monné
Reviewed-by: Jan Beulic
This functionality is going to reside in vpci.c (and the corresponding
vpci.h header), and should be arch-agnostic. The handlers introduced
in this patch setup the basic functionality required in order to trap
accesses to the PCI config space, and allow decoding the address and
finding the correspo
Add handlers for accesses to the MSI-X message control field on the
PCI configuration space, and traps for accesses to the memory region
that contains the MSI-X table and PBA. This traps detect attempts from
the guest to configure MSI-X interrupts and properly sets them up.
Note that accesses to t
So that it can be called from outside in order to get the size of regular PCI
BARs. This will be required in order to map the BARs from PCI devices into PVH
Dom0 p2m.
Signed-off-by: Roger Pau Monné
Reviewed-by: Jan Beulich
---
Cc: Jan Beulich
Cc: Andrew Cooper
Cc: George Dunlap
Cc: Ian Jackso
Hello,
The following series contain an implementation of handlers for the PCI
configuration space inside of Xen. This allows Xen to detect accesses
to the PCI configuration space and react accordingly.
Why is this needed? IMHO, there are two main points of doing all this
emulation inside of Xen,
Add handlers for the MSI control, address, data and mask fields in
order to detect accesses to them and setup the interrupts as requested
by the guest.
Note that the pending register is not trapped, and the guest can
freely read/write to it.
Signed-off-by: Roger Pau Monné
Reviewed-by: Jan Beulic
Hi Andre,
On 03/22/2018 11:56 AM, Andre Przywara wrote:
Now that we have both the old VGIC prepared to cope with a sibling and
the code for the new VGIC in place, lets add a Kconfig option to enable
the new code and wire it into the Xen build system.
This will add a compile time option to use ei
Some functions in vpci.c (vpci_remove_device and vpci_add_handlers)
are not used by the user-space test harness, so guard them with
__XEN__ in order to avoid exposing them to the user-space test
harness.
Requested-by: Jan Beulich
Signed-off-by: Roger Pau Monné
Reviewed-by: Jan Beulich
---
Cc: I
Signed-off-by: Roger Pau Monné
Reviewed-by: Jan Beulich
---
Cc: Jan Beulich
Cc: Andrew Cooper
Cc: George Dunlap
Cc: Ian Jackson
Cc: Julien Grall
Cc: Konrad Rzeszutek Wilk
Cc: Stefano Stabellini
Cc: Tim Deegan
Cc: Wei Liu
---
Changes since v6:
- Remove the rom local variable.
Changes si
Introduce a set of handlers for the accesses to the MMCFG areas. Those
areas are setup based on the contents of the hardware MMCFG tables,
and the list of handled MMCFG areas is stored inside of the hvm_domain
struct.
The read/writes are forwarded to the generic vpci handlers once the
address is d
Introduce a set of handlers that trap accesses to the PCI BARs and the
command register, in order to snoop BAR sizing and BAR relocation.
The command handler is used to detect changes to bit 2 (response to
memory space accesses), and maps/unmaps the BARs of the device into
the guest p2m. A rangese
This function allows to iterate over a rangeset while removing the
processed regions.
This will be used in order to split processing of large memory areas
when mapping them into the guest p2m.
Signed-off-by: Roger Pau Monné
Reviewed-by: Wei Liu
---
Cc: Andrew Cooper
Cc: George Dunlap
Cc: Ian
Hi Andre,
On 03/22/2018 11:56 AM, Andre Przywara wrote:
When playing around with hardware mapped, level triggered virtual IRQs,
there is the need to explicitly set the active or pending state of an
interrupt at some point.
To prepare the GIC for that, we introduce a set_active_state() and a
set_
Hi Andre,
On 03/22/2018 11:04 AM, Andre Przywara wrote:
This is a "patch to the patch" mentioned above, to make it clear what
changed:
We now take the desc lock in vgic_v2_fold_lr_state() when we are dealing
with a hardware IRQ. This is a bit complicated, because we have to obey
the existing loc
Hi,
On 03/22/2018 11:55 AM, Roger Pau Monné wrote:
On Thu, Mar 22, 2018 at 10:27:35AM +, Paul Durrant wrote:
De-htmling...
-
From: Lars Kurth
Sent: 22 March 2018 10:22
To: xen-de...@lists.xensource.com
Cc: committ...@xenproject.org; Juergen Gross ; Janakarajan Natarajan ; Tamas K Lengy
>>> On 22.03.18 at 14:20, wrote:
> On Mon, Mar 19, 2018 at 07:41:42AM -0600, Jan Beulich wrote:
>> --- a/xen/arch/x86/pv/domain.c
>> +++ b/xen/arch/x86/pv/domain.c
>> @@ -219,10 +219,22 @@ int pv_domain_initialise(struct domain *
>> return rc;
>> }
>>
>> -static void _toggle_guest_pt(struc
On 03/22/2018 12:22 PM, Lars Kurth wrote:
> Hi all,
>
> please find attached
> a) Meeting details (just a link with timezones) – the meeting invite
> will follow when we have an agenda
> Bridge details – will be sent with the meeting invite
> I am thinking of using GotoMeeting, but want to
On Mon, Mar 19, 2018 at 07:41:42AM -0600, Jan Beulich wrote:
> When XPTI is active, the CR3 load in restore_all_guest is sufficient
> when switching to user mode, improving in particular system call and
> page fault exit paths for the guest.
>
> Signed-off-by: Jan Beulich
> Tested-by: Juergen Gro
>>> On 22.03.18 at 14:05, wrote:
> On Thu, 22 Mar 2018 06:09:44 -0600
> "Jan Beulich" wrote:
>
> On 22.03.18 at 12:56, wrote:
>>> I really don't understand why some people have that fear of emulated
>>> MMCONFIG -- it's really the same thing as any other MMIO range QEMU
>>> already emulat
On Thu, 22 Mar 2018 06:09:44 -0600
"Jan Beulich" wrote:
On 22.03.18 at 12:56, wrote:
>> I really don't understand why some people have that fear of emulated
>> MMCONFIG -- it's really the same thing as any other MMIO range QEMU
>> already emulates via map_io_range_to_ioreq_server(). No se
flight 121056 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/121056/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-armhf broken
build-armhf
On Thu, Mar 22, 2018 at 10:29:22PM +1000, Alexey G wrote:
> On Thu, 22 Mar 2018 09:57:16 +
> Roger Pau Monné wrote:
> [...]
> >> Yes, and it is still needed as we have two distinct (and not equal)
> >> interfaces to PCI conf space. Apart from 0..FFh range overlapping
> >> they can be considere
On Thu, 22 Mar 2018 09:57:16 +
Roger Pau Monné wrote:
[...]
>> Yes, and it is still needed as we have two distinct (and not equal)
>> interfaces to PCI conf space. Apart from 0..FFh range overlapping
>> they can be considered very different interfaces. And whether it is
>> a real system or emu
Hi,
At 04:47 + on 21 Mar (1521607657), Julien Grall wrote:
> Most of the users of page_to_mfn and mfn_to_page are either overriding
> the macros to make them work with mfn_t or use mfn_x/_mfn because the
> rest of the function use mfn_t.
>
> So make page_to_mfn and mfn_to_page return mfn_t by
On Mon, Mar 19, 2018 at 07:41:11AM -0600, Jan Beulich wrote:
> ... despite quite likely the gain being rather limited.
>
> Signed-off-by: Jan Beulich
Reviewed-by: Wei Liu
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproj
On Mon, Mar 19, 2018 at 07:40:12AM -0600, Jan Beulich wrote:
> This exposes less code pieces and at the same time reduces the range
> covered from slightly above 3 pages to a little below 2 of them.
>
> The code being moved is unchanged, except for the removal of trailing
> blanks, insertion of bl
On Mon, Mar 19, 2018 at 07:40:50AM -0600, Jan Beulich wrote:
> The STI instances were moved (or added in the INT80 case) to meet TLB
> flush requirements. When XPTI is disabled, they can be put back where
> they were (or omitted in the INT80 case).
>
> Signed-off-by: Jan Beulich
Reviewed-by: Wei
flight 120988 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/120988/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-armhf 6 xen-buildfail REGR. vs. 120943
Tests which did no
>>> On 22.03.18 at 12:56, wrote:
> I really don't understand why some people have that fear of emulated
> MMCONFIG -- it's really the same thing as any other MMIO range QEMU
> already emulates via map_io_range_to_ioreq_server(). No sensitive
> information exposed. It is related only to emulated PC
A previous patch introduced a new HYPERVISOR_memory_op to acquire guest
resources for direct priv-mapping.
This patch adds new functionality into libxenforeignmemory to make use
of a new privcmd ioctl [1] that uses the new memory op to make such
resources available via mmap(2).
[1]
http://xenbit
A previous patch added support for priv-mapping guest resources directly
(rather than having to foreign-map, which requires P2M modification for
HVM guests).
This patch makes use of the new API to seed the guest grant table unless
the underlying infrastructure (i.e. privcmd) doesn't support it, in
This patch allows grant table frames to be mapped using the
XENMEM_acquire_resource memory op.
NOTE: This patch expands the on-stack mfn_list array in acquire_resource()
but it is still small enough to remain on-stack.
Signed-off-by: Paul Durrant
---
Cc: Jan Beulich
Cc: Andrew Cooper
Cc:
Now that we have both the old VGIC prepared to cope with a sibling and
the code for the new VGIC in place, lets add a Kconfig option to enable
the new code and wire it into the Xen build system.
This will add a compile time option to use either the "old" or the "new"
VGIC.
In the moment this is res
When playing around with hardware mapped, level triggered virtual IRQs,
there is the need to explicitly set the active or pending state of an
interrupt at some point.
To prepare the GIC for that, we introduce a set_active_state() and a
set_pending_state() function to let the VGIC manipulate the sta
Processing maintenance interrupts and accessing the list registers
are dependent on the host's GIC version.
Introduce vgic-v2.c to contain GICv2 specific functions.
Implement the GICv2 specific code for syncing the emulation state
into the VGIC registers.
This also adds the hook to let Xen setup th
Hi,
this is just an update of the three patches which didn't get any review
tags so far.
The fixes for the new versions of 03/39 and 39/39 are pretty straight
forward, but 14/39 is more of a beast. I sent a diff to the original
patch [1] separately to give an idea of the changes.
I added the R-b:
On Thu, 22 Mar 2018 10:06:09 +
Paul Durrant wrote:
>> -Original Message-
>> From: Alexey G [mailto:x19...@gmail.com]
>> Sent: 22 March 2018 09:55
>> To: Jan Beulich
>> Cc: Andrew Cooper ; Anthony Perard
>> ; Ian Jackson ;
>> Paul Durrant ; Roger Pau Monne
>> ; Wei Liu ; Stefano
>> St
Certain memory resources associated with a guest are not necessarily
present in the guest P2M.
This patch adds the boilerplate for new memory op to allow such a resource
to be priv-mapped directly, by either a PV or HVM tools domain.
NOTE: Whilst the new op is not intrinsicly specific to the x86
This patch adjusts the ioreq server code to use type-safe gfn_t values
where possible. No functional change.
Signed-off-by: Paul Durrant
Reviewed-by: Roger Pau Monné
Reviewed-by: Wei Liu
Acked-by: Jan Beulich
---
Cc: Andrew Cooper
v18:
- Trivial re-base.
---
xen/arch/x86/hvm/ioreq.c
By using a static inline stub in private.h for OS where this functionality
is not implemented, the various duplicate stubs in the OS-specific source
modules can be avoided.
Signed-off-by: Paul Durrant
Reviewed-by: Roger Pau Monné
Acked-by: Wei Liu
---
Cc: Ian Jackson
v4:
- Removed extraneous
...to allow the calling domain to prevent translation of specified l1e
value.
Despite what the comment in public/xen.h might imply, specifying a
command value of MMU_NORMAL_PT_UPDATE will not simply update an l1e with
the specified value. Instead, mod_l1_entry() tests whether foreign_dom
has PG_tr
This patch re-works much of the ioreq server initialization and teardown
code:
- The hvm_map/unmap_ioreq_gfn() functions are expanded to call through
to hvm_alloc/free_ioreq_gfn() rather than expecting them to be called
separately by outer functions.
- Several functions now test the validity o
A subsequent patch will remove the current implicit limitation on creation
of ioreq servers which is due to the allocation of gfns for the ioreq
structures and buffered ioreq ring.
It will therefore be necessary to introduce an explicit limit and, since
this limit should be small, it simplifies th
This series introduces support for direct mapping of guest resources.
The resources are:
- IOREQ server pages
- Grant tables
v18:
- Re-base
- Use the now-reference-counted emulating domain to host ioreq pages
v17:
- Make sure ioreq page free-ing is done at domain destruction
v16:
- Fix def
1 - 100 of 152 matches
Mail list logo
