For some pci device, even its PCI_INTERRUPT_PIN is not 0, it actually
doesn't support INTx mode, so its machine irq read from host sysfs is 0.
In that case, report PCI_INTERRUPT_PIN as 0 to guest and let passthrough
continue.
Cc: Roger Pau Monné
Cc: Jan Beulich
Signed-off-by: Zhao Yan
---
v2:
hi Andrew,
It's a pci device that does not support legacy intx mode, but it accidently
reports PCI_INTERRUPT_PIN as 1, which should be 0 instead.
So, in dom0, the machine irq is 0, which will cause later
xc_physdev_map_pirq() fail and passthrough failure.
Therefore, we treat this case as PCI_INTE
On Mon, Dec 03, 2018 at 12:20:30PM +0100, Roger Pau Monné wrote:
> Hello,
>
> Thanks for the patch.
>
> The subject should be more descriptive, "Fix a xen passthrough
> failure" is too generic. How about: "allow passthrough of devices with
> bogus interrupt pin" or something similar.
right, thank
Hi Julien,
Awesome, after applying those patches in latest xen, hikey960 able to
enable 4 CPUs and other four CPUs are giving error -5.
And after using "hmp-unsafe" in xen command line, all CPUs got enabled
successfully.
Thank you,
Omkar B
On Mon, Dec 3, 2018 at 7:27 PM Julien Grall wrote:
>
>
The problem is that we call this with a spin lock held.
The call tree is:
pvcalls_front_accept() holds bedata->socket_lock.
-> create_active()
-> __get_free_pages() uses GFP_KERNEL
The create_active() function is only called from pvcalls_front_accept()
with a spin_lock held, The alloca
Hello,
I'm currently attempting to add guard pages to a Xen-based unikernel. These
are memory regions that cannot be read, written, or executed, could be
potentially ones up to 1MB in size, and would, for instance, separate the
stack and the heap to prevent buffer overflows and stack clashes.
Ide
On Mon, Dec 3, 2018 at 11:52 AM Mike Rapoport wrote:
>
> On Mon, Dec 03, 2018 at 09:51:45AM +0530, Souptick Joarder wrote:
> > Hi Mike,
> >
> > On Sun, Dec 2, 2018 at 4:43 PM Mike Rapoport wrote:
> > >
> > > On Sun, Dec 02, 2018 at 11:49:44AM +0530, Souptick Joarder wrote:
> > > > Previouly drive
On 04/12/2018 02:14, Dongli Zhang wrote:
> Hi Boris,
>
> On 12/04/2018 12:07 AM, Boris Ostrovsky wrote:
>> On 12/2/18 3:31 PM, Manjunath Patil wrote:
>>> On 11/30/2018 2:33 PM, Boris Ostrovsky wrote:
>>>
On 11/30/18 4:49 PM, Manjunath Patil wrote:
> Thank you Boris for your comments. I re
Hi all,
When I make grub, I met error " too few arguments to function
'grub_create_loader_cmdline'" with xen.
I used git bisect and found the error occurred from commit:
4d4a8c96e3593d76fe7b025665ccdecc70a53c1f.
Do you have any ideas? Thanks a lot!
commit 4d4a8c96e3593d76fe7b025665ccdecc70a53c1
‐‐‐ Original Message ‐‐‐
On Monday, December 3, 2018 1:07 PM, Rian Quinn wrote:
>> Xen signals in the FADT that there's no VGA, but I won't be surprised
>> that some OSes simply ignore this bit because there are systems with
>> broken ACPI tables out there with the bit set and VGA.
>
> We
Missing the DT list...
On Mon, Dec 3, 2018 at 3:43 PM Stefano Stabellini
wrote:
>
> From: Stefano Stabellini
>
> Introduce a device tree binding for Xen reserved-memory regions. They
> are used to share memory across VMs from the VM config files. (See
> static_shm config option.)
>
> Signed-off-
On Wed, Nov 28, 2018 at 2:57 PM Razvan Cojocaru
wrote:
>
> This series aims to prevent the display from freezing when
> enabling altp2m and switching to a new view (and assorted problems
> when resizing the display).
>
> The series allocates a new logdirty rangeset for each new altp2m,
> and propa
Hi Manjunath,
On 12/04/2018 10:49 AM, Manjunath Patil wrote:
> On 12/3/2018 6:16 PM, Boris Ostrovsky wrote:
>
>> On 12/3/18 8:14 PM, Dongli Zhang wrote:
>>> Hi Boris,
>>>
>>> On 12/04/2018 12:07 AM, Boris Ostrovsky wrote:
On 12/2/18 3:31 PM, Manjunath Patil wrote:
> On 11/30/2018 2:33 PM
On 12/3/2018 6:16 PM, Boris Ostrovsky wrote:
On 12/3/18 8:14 PM, Dongli Zhang wrote:
Hi Boris,
On 12/04/2018 12:07 AM, Boris Ostrovsky wrote:
On 12/2/18 3:31 PM, Manjunath Patil wrote:
On 11/30/2018 2:33 PM, Boris Ostrovsky wrote:
On 11/30/18 4:49 PM, Manjunath Patil wrote:
Thank you Bori
On 12/3/18 8:14 PM, Dongli Zhang wrote:
> Hi Boris,
>
> On 12/04/2018 12:07 AM, Boris Ostrovsky wrote:
>> On 12/2/18 3:31 PM, Manjunath Patil wrote:
>>> On 11/30/2018 2:33 PM, Boris Ostrovsky wrote:
>>>
On 11/30/18 4:49 PM, Manjunath Patil wrote:
> Thank you Boris for your comments. I remo
Hi Boris,
On 12/04/2018 12:07 AM, Boris Ostrovsky wrote:
> On 12/2/18 3:31 PM, Manjunath Patil wrote:
>> On 11/30/2018 2:33 PM, Boris Ostrovsky wrote:
>>
>>> On 11/30/18 4:49 PM, Manjunath Patil wrote:
Thank you Boris for your comments. I removed faulty email of mine.
replies inline
flight 130906 linux-4.19 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/130906/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-qemuu-debianhvm-amd64-xsm 7 xen-boot fail REGR. vs. 129313
test-amd64-amd64-xl-
From: Stefano Stabellini
Introduce a device tree binding for Xen reserved-memory regions. They
are used to share memory across VMs from the VM config files. (See
static_shm config option.)
Signed-off-by: Stefano Stabellini
Cc: julien.gr...@arm.com
Cc: devicet...@vger.kernel.org
Cc: robh...@kern
On Mon, 3 Dec 2018, Rob Herring wrote:
> Missing the DT list...
Sorry about that, I'll add it next time
> On Mon, Dec 3, 2018 at 3:43 PM Stefano Stabellini
> wrote:
> >
> > From: Stefano Stabellini
> >
> > Introduce a device tree binding for Xen reserved-memory regions. They
> > are used to sh
On Wed, 7 Nov 2018, Jan Beulich wrote:
> >>> On 06.11.18 at 23:42, wrote:
> > On Tue, 9 Oct 2018, Jan Beulich wrote:
> >> >>> On 09.10.18 at 01:37, wrote:
> >> > --- a/xen/include/xsm/dummy.h
> >> > +++ b/xen/include/xsm/dummy.h
> >> > @@ -535,6 +535,20 @@ static XSM_INLINE int
> >> > xsm_map_gm
From: Stefano Stabellini
Introduce a device tree binding for Xen reserved-memory regions. They
are used to share memory across VMs from the VM config files. (See
static_shm config option.)
Signed-off-by: Stefano Stabellini
Cc: julien.gr...@arm.com
---
Changes in v4:
- add offset property
Chang
flight 130904 linux-4.4 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/130904/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-armhf-armhf-xl-cubietruck 16 guest-start/debian.repeat fail REGR. vs.
130865
test-armhf-armhf-
On Mon, 3 Dec 2018, Stefano Stabellini wrote:
> From: "Edgar E. Iglesias"
>
> From: Edgar E. Iglesias
Sorry about this, I haven't found a way to deal with this problem
automatically with git and guilt yet.
> Introduce platform_smc as a way to handle firmware calls that Xen does
> not know ab
From: "Edgar E. Iglesias"
From: Edgar E. Iglesias
zynqmp_eemi uses the defined functions and structs to decide whether to
make a call to the firmware, or to simply return a predefined value.
Signed-off-by: Edgar E. Iglesias
Signed-off-by: Stefano Stabellini
---
Changes in v5:
- remove mmio_a
From: "Edgar E. Iglesias"
From: Edgar E. Iglesias
Stop blacklisting ZynqMP's power management node. It is now possible
since we allow the hardware domain to issue HVC/SMC calls to firmware.
Signed-off-by: Edgar E. Iglesias
Signed-off-by: Stefano Stabellini
Reviewed-by: Stefano Stabellini
--
From: "Edgar E. Iglesias"
From: Edgar E. Iglesias
Introduce data structs to implement basic access controls.
Introduce the following three functions:
domain_has_node_access: check access to the node
domain_has_reset_access: check access to the reset line
domain_has_mmio_access: check access to
From: "Edgar E. Iglesias"
From: Edgar E. Iglesias
Introduce platform_smc as a way to handle firmware calls that Xen does
not know about in a platform specific way. This is particularly useful
for implementing the SiP (SoC implementation specific) service calls.
Signed-off-by: Edgar E. Iglesias
From: "Edgar E. Iglesias"
From: Edgar E. Iglesias
Introduce zynqmp_eemi: a function responsible for implementing access
controls over the firmware calls. Only calls that are allowed are
forwarded to the firmware.
Signed-off-by: Edgar E. Iglesias
Signed-off-by: Stefano Stabellini
---
Changes
To be used in constant initializations of mfn_t variables, such as:
static mfn_t node = mfn_init(MM_ADDR);
It is necessary because static inline functions cannot be used as static
initializers.
Signed-off-by: Stefano Stabellini
CC: Andrew Cooper
CC: George Dunlap
CC: Ian Jackson
CC: Jan Beul
From: "Edgar E. Iglesias"
From: Edgar E. Iglesias
Introduce zynqmp specific defines for the firmware calls.
See EEMI:
https://www.xilinx.com/support/documentation/user_guides/ug1200-eemi-api.pdf
The error codes are described, under XIlPM Error Codes:
https://www.xilinx.com/support/documentatio
Hi all,
Compared to v4, I removed the amount of #defines and used mfn_t more
widely across the series. Some #defines remain, see my comments on patch
#3 and patch #5.
Cheers,
Stefano
The following changes since commit 162fc8295f31240dc3670190a91e9bbc03b0d7be:
libxl: Restore scheduling param
[...]
>>>
>>> + if (type == MEMORY_BLOCK_NONE)
>>> + return -EINVAL;
>>
>> No one will pass in this value. Can we omit this check for now?
>
>I could move it to patch nr 2 I guess, but as I introduce
>MEMORY_BLOCK_NONE here it made sense to keep it in here.
>
Yes, this make sense to m
> Xen signals in the FADT that there's no VGA, but I won't be surprised
> that some OSes simply ignore this bit because there are systems with
> broken ACPI tables out there with the bit set and VGA.
We do the same thing, and yeah it appears that Linux is ignoring this. We
noticed the same thing W
On 06/11/2018 13:45, Jan Beulich wrote:
> Now that there's an almost unconditional CR4 read right at the beginning
> of x86_emulate(), centralize its reading there and use result and value
> everywhere else without further invoking the hook.
>
> Subsequently we may want to consider having the calle
On 06/11/2018 13:45, Jan Beulich wrote:
> This is a check explicitly listed by the instruction page in the SDM.
>
> Signed-off-by: Jan Beulich
Reviewed-by: Andrew Cooper
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenprojec
On 06/11/2018 13:44, Jan Beulich wrote:
> At IOPL 3 CR4.VME is irrelevant.
>
> Reported-by: Andrew Cooper
> Signed-off-by: Jan Beulich
Reviewed-by: Andrew Cooper
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/m
Signed-off-by: Andrew Cooper
---
CC: Jan Beulich
CC: Wei Liu
CC: Roger Pau Monné
It's taken me nearly an hour with the vendor manuals to convince myself that
the emulation is correct. The code is definitely too complicated to follow
without some comments.
---
xen/arch/x86/x86_emulate/x86_emu
On Wed, Nov 21, 2018 at 03:12:03PM +, Paul Durrant wrote:
> This patch adds the transformations necessary to get dataplane/xen-qdisk.c
> to build against the new XenBus/XenDevice framework. MAINTAINERS is also
> updated due to the introduction of dataplane/xen-qdisk.h.
>
> NOTE: Existing data
The iommu_ops structure contains two methods for flushing: 'iotlb_flush' and
'iotlb_flush_all'. This patch adds implementations of these for AMD IOMMUs.
The iotlb_flush method takes a base DFN and a (4k) page count, but the
flush needs to be done by page order (i.e. 0, 9 or 18). Because a flush
op
Now that the iommu_map() and iommu_unmap() operations take an order
parameter and elide flushing there's no strong reason why modifying MMIO
ranges in the p2m should be restricted to a 4k granularity simply because
the IOMMU is enabled but shared page tables are not in operation.
Signed-off-by: Pa
Paul Durrant (4):
amd-iommu: add flush iommu_ops
iommu: rename wrapper functions
iommu: elide flushing for higher order map/unmap operations
x86/mm/p2m: stop checking for IOMMU shared page tables in mmio_order()
xen/arch/arm/p2m.c| 13 ++-
xen/arch/x86/mm.c
This patch removes any implicit flushing that occurs in the implementation
of map and unmap operations and adds new iommu_map/unmap() wrapper
functions. To maintain sematics of the iommu_legacy_map/unmap() wrapper
functions, these are modified to call the new wrapper functions and then
perform an e
A subsequent patch will add semantically different versions of
iommu_map/unmap() so, in advance of that change, this patch renames the
existing functions to iommu_legacy_map/unmap() and modifies all call-sites.
The patch also renames iommu_iotlb_flush[_all] to the shorter name(s)
iommu_flush[_all]
On Fri, Nov 30, 2018 at 03:53:29AM -0700, Jan Beulich wrote:
> >>> On 29.11.18 at 18:11, wrote:
> > This errata affect the values read from the BAR registers, and could
> > render vPCI (and by extension PVH Dom0 unusable).
> >
> > HSE43 is a Haswell erratum where a non-BAR register is implemented
Does anyone but Linus and Russell have comments on this series?
I'd like to pull it in fairly quickly as I have a fair amount of
work on top of it that I'd like to get into 4.21 as well.
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://
flight 130895 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/130895/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-pygrub 7 xen-boot fail REGR. vs. 129817
Regressions which
Hello,
On Mon, Dec 03, 2018 at 09:06:37AM -0700, Rian Quinn wrote:
> > Can you trace this to the Linux code that's actually making the call
> > by injecting a trap when this happens?
>
> Yes, we can. In some cases, we have to manually backtrace, but so far
> we have been able to map resources to
On Wed, Nov 21, 2018 at 03:12:02PM +, Paul Durrant wrote:
> Not all of the code duplicated from xen_disk.c is required as the basis for
> the new dataplane implementation so this patch removes extraneous code,
> along with the legacy #includes and calls to the legacy xen_pv_printf()
> function.
> == Future items
>
> The Linux device driver used to test this software is derived from the
> OpenXT v4v Linux device driver, available at:
> https://github.com/OpenXT/v4v
> The Argo implementation is not yet ready to publish (focus has been on
> the hypervisor code to this point). A Linux dev
On Mon, Dec 03, 2018 at 04:35:39PM +, Anthony PERARD wrote:
> On Wed, Nov 21, 2018 at 03:12:01PM +, Paul Durrant wrote:
> > The new xen-qdisk XenDevice implementation requires the same core dataplane
> > as the legacy xen_disk implementation it will eventually replace. This
> > patch theref
On Mon, 3 Dec 2018 14:33:08 +0200
Andrii Anisov wrote:
Hi Andrii,
> On 29.11.18 14:14, Andre Przywara wrote:
> > Nah, please don't do this.
> Sorry for making you crying looking at this code.
> It's terrible, I know. It's rather an idea.
>
> > Can you show that atomic bit ops are a
> > proble
On Wed, Nov 21, 2018 at 03:12:01PM +, Paul Durrant wrote:
> The new xen-qdisk XenDevice implementation requires the same core dataplane
> as the legacy xen_disk implementation it will eventually replace. This
> patch therefore copies the legacy xen_disk.c source module into a new
> dataplane/xe
On 03/12/2018 16:24, Jan Beulich wrote:
On 03.12.18 at 17:18, wrote:
>> This is a lingering TODO item from XSA-263. It adds support AMD's
>> MSR_VIRT_SPEC_CTRL interface, and changes Xen's "boot time global" SSBD
>> setting into a per-vcpu setting.
>>
>> This can be found on:
>> git://xenb
>>> On 03.12.18 at 17:18, wrote:
> This is a lingering TODO item from XSA-263. It adds support AMD's
> MSR_VIRT_SPEC_CTRL interface, and changes Xen's "boot time global" SSBD
> setting into a per-vcpu setting.
>
> This can be found on:
> git://xenbits.xen.org/people/andrewcoop/xen.git xen-virt
On Wed, Nov 21, 2018 at 03:12:00PM +, Paul Durrant wrote:
> The legacy PV backend infrastructure provides functions to bind, unbind
> and send notifications to event channnels. Similar functionality will be
> required by XenDevice implementations so this patch adds the necessary
> support.
>
>
With all other infrastructure now in place, offer X86_FEATURE_VIRT_SC_SSBD to
guests in cases where Xen thinks it has a working LEGACY_SSBD interface.
Signed-off-by: Andrew Cooper
---
CC: Jan Beulich
CC: Wei Liu
CC: Roger Pau Monné
CC: Brian Woods
---
xen/arch/x86/cpuid.c
>>> On 01.12.18 at 02:32, wrote:
> Allocates an IPI-bound event channel on vcpu0 for specified domain.
Please can such changes to general code be done at the point where
they're needed?
> Is able to bypass the existence check on vcpu number since vcpu 0
> should always exist. Bypass is required
This is a lingering TODO item from XSA-263. It adds support AMD's
MSR_VIRT_SPEC_CTRL interface, and changes Xen's "boot time global" SSBD
setting into a per-vcpu setting.
This can be found on:
git://xenbits.xen.org/people/andrewcoop/xen.git xen-virt-spec-ctrl-v1
The start of the series is some
It is critical that MSR_AMD64_LS_CFG is never modified outside of this
function, to avoid trampling on sibling settings.
For now, pass in NULL from the boot paths and just set Xen's default. Later
patches will plumb in guest choices. This now supercedes the older code which
wrote to MSR_AMD64_LS
At the time of writing, the spec is available from:
https://developer.amd.com/wp-content/resources/124441_AMD64_SpeculativeStoreBypassDisable_Whitepaper_final.pdf
Future hardware (Zen v2) is expect to have hardware MSR_SPEC_CTRL support,
including SPEC_CTRL.SSBD, and with the expectation that
The semantics of MSR_VIRT_SPEC_CTRL are that unknown bits are write-discard
and read as zero. Only VIRT_SPEC_CTRL.SSBD is defined at the moment.
To facilitate making this per-guest, the legacy SSBD state needs context
switching between vcpus. amd_ctxt_switch_legacy_ssbd() is updated to take the
bti= was introduced with the original Spectre fixes (Jan 2018), but by the
time Speculative Store Bypass came along (May 2018), it was superceeded by the
more generic spec-ctrl=.
Since then, we've had LazyFPU (June 2018) and L1TF (August 2018), which means
noone will be using the option. Remove i
The need for per-core resources is a property of Fam17h hardware. The
mechanim for calculating / allocating space is all a bit horrible, but is the
best which can be done at this point. See the code comments for details.
Signed-off-by: Andrew Cooper
Parts based on an earlier patch by Brian
Sign
Introduce a new synthetic LEGACY_SSBD feature and set it if we find
VIRT_SPEC_CTRL offered by our hypervisor, or if we find a working bit in an
LS_CFG register.
Signed-off-by: Andrew Cooper
---
CC: Jan Beulich
CC: Wei Liu
CC: Roger Pau Monné
CC: Brian Woods
---
xen/arch/x86/cpu/amd.c
For gen-cpuid.py, fix a comment describing self.names, and generate the
reverse mapping in self.values. Write out INIT_FEATURE_NAMES which maps a
string name to a bit position.
For parse_cpuid(), introduce a slightly fuzzy strcmp() to accept changes in
punctuation, and perform a binary search ove
This appears to be a vestigial remnent of an old version of the
XSA-254/Spectre series, and has never been used.
Signed-off-by: Andrew Cooper
---
CC: Jan Beulich
CC: Wei Liu
CC: Roger Pau Monné
---
xen/include/asm-x86/cpufeatures.h | 1 -
1 file changed, 1 deletion(-)
diff --git a/xen/includ
On 12/2/18 3:31 PM, Manjunath Patil wrote:
> On 11/30/2018 2:33 PM, Boris Ostrovsky wrote:
>
>> On 11/30/18 4:49 PM, Manjunath Patil wrote:
>>> Thank you Boris for your comments. I removed faulty email of mine.
>>>
>>> replies inline.
>>> On 11/30/2018 12:42 PM, Boris Ostrovsky wrote:
On 11/29
> Can you trace this to the Linux code that's actually making the call
> by injecting a trap when this happens?
Yes, we can. In some cases, we have to manually backtrace, but so far
we have been able to map resources to the actual source code.
> Serial port poking?
This would be a great one to l
On 12/1/18 1:33 AM, Wen Yang wrote:
> The problem is that we call this with a spin lock held.
> The call tree is:
> pvcalls_front_accept() holds bedata->socket_lock.
> -> create_active()
> -> __get_free_pages() uses GFP_KERNEL
>
> The create_active() function is only called from pvcalls
>>> On 01.12.18 at 02:32, wrote:
> A convenience for working on development of the argo subsystem:
> toggling a local #define variable turns on just the debug messages
> in this subsystem.
I'm afraid I don't see the #define variable to toggle. I assume it's
ARGO_DEBUG, but there's no #define line
>>> On 01.12.18 at 02:32, wrote:
> --- a/xen/common/Kconfig
> +++ b/xen/common/Kconfig
> @@ -200,6 +200,26 @@ config LATE_HWDOM
>
> If unsure, say N.
>
> +config ARGO
> +bool "Argo: hypervisor-mediated interdomain communication"
> +default y
Until our policy changes as to wide
On Wed, Nov 21, 2018 at 03:11:59PM +, Paul Durrant wrote:
> The legacy PV backend infrastructure provides functions to map, unmap and
> copy pages granted by frontends. Similar functionality will be required
> by XenDevice implementations so this patch adds the necessary support.
>
> Signed-of
> -Original Message-
> From: Jan Beulich [mailto:jbeul...@suse.com]
> Sent: 03 December 2018 15:29
> To: Paul Durrant
> Cc: Brian Woods ; Suravee Suthikulpanit
> ; Julien Grall ;
> Andrew Cooper ; Roger Pau Monne
> ; Wei Liu ; Kevin Tian
> ; Stefano Stabellini ; xen-
> devel
> Subject: RE
>>> On 01.12.18 at 02:32, wrote:
> http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/errno.h.html
> describes these codes thus:
> EMSGSIZE : "Message too large"
> ECONNREFUSED : "Connection refused".
If you were to go solely by what POSIX mandates to have, more
additions would
On Mon, Dec 03, 2018 at 01:40:06AM -0700, Jan Beulich wrote:
> >>> On 30.11.18 at 17:33, wrote:
> > On Mon, Oct 01, 2018 at 10:26:05AM -0600, Jan Beulich wrote:
> >> --- a/xen/arch/x86/msi.c
> >> +++ b/xen/arch/x86/msi.c
> >> @@ -742,6 +742,16 @@ static int msi_capability_init(struct pc
> >>
> >
Hello Andre,
On 03.12.18 15:46, Andre Przywara wrote:
Well, you should be scared of the old VGIC locking scheme instead ;-)
Old VGIC locking is more mazy, indeed.
Apart from the vgic_queue_irq_unlock() function, the rest of the new
locking scheme is much clearer.
I agree,
Yes, but effectiv
>>> On 03.12.18 at 16:18, wrote:
>> From: Xen-devel [mailto:xen-devel-boun...@lists.xenproject.org] On Behalf
>> Of Jan Beulich
>> Sent: 03 December 2018 15:03
>>
>> >>> On 30.11.18 at 11:45, wrote:
>> > --- a/xen/drivers/passthrough/vtd/iommu.c
>> > +++ b/xen/drivers/passthrough/vtd/iommu.c
>>
> -Original Message-
> From: Xen-devel [mailto:xen-devel-boun...@lists.xenproject.org] On Behalf
> Of Jan Beulich
> Sent: 03 December 2018 15:03
> To: Paul Durrant
> Cc: Kevin Tian ; Stefano Stabellini
> ; Wei Liu ; Andrew Cooper
> ; Julien Grall ; Suravee
> Suthikulpanit ; xen-devel de..
>>> On 30.11.18 at 11:45, wrote:
> This patch removes any implicit flushing that occurs in the implementation
> of map and unmap operations and, instead, adds explicit flushing at the
> end of the loops in the iommu_map/unmap() wrapper functions.
>
> Because VT-d currently performs two different
>>> On 03.12.18 at 15:47, wrote:
> On Mon, Dec 03, 2018 at 04:01:07AM -0700, Jan Beulich wrote:
>> >>> On 02.12.18 at 18:47, wrote:
>> > From: Dwayne Litzenberger
>> >
>> > Newer AMD GPUs store their initialization routines as bytecode on the
>> > ROM. This fixes the following initialization e
flight 130897 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/130897/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-i386-xsm6 xen-buildfail REGR. vs. 129475
build-i386
On Mon, Dec 03, 2018 at 04:01:07AM -0700, Jan Beulich wrote:
> >>> On 02.12.18 at 18:47, wrote:
> > From: Dwayne Litzenberger
> >
> > Newer AMD GPUs store their initialization routines as bytecode on the
> > ROM. This fixes the following initialization error inside the VM when
> > doing PCI pas
On Wed, Nov 21, 2018 at 03:11:58PM +, Paul Durrant wrote:
> A Xen PV frontend communicates its state to the PV backend by writing to
> the 'state' key in the frontend area in xenstore. It is therefore
> necessary for a XenDevice implementation to be notified whenever the
> value of this key cha
Hello Juergen,
On 03.12.18 15:53, Juergen Gross wrote:
On 03/12/2018 14:46, Andre Przywara wrote:
I think PERFCOUNTER is your friend.
CONFIG_LOCK_PROFILE and xen-lockprof on tools side?
Not sure it is still working, though. Its about 9 years since I wrote
and used it.
It does work. I've use
branch xen-unstable
xenbranch xen-unstable
job test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict
testid debian-hvm-install
Tree: linux git://xenbits.xen.org/linux-pvops.git
Tree: linuxfirmware git://xenbits.xen.org/osstest/linux-firmware.git
Tree: qemu git://xenbits.xen.org/qemu-xen-traditional
On 03/12/2018 05:04, Zhao Yan wrote:
> For some pci device, even its PCI_INTERRUPT_PIN is not 0, it actually
> doesn't support INTx mode, so its machine irq read from host sysfs is 0.
> In that case, report PCI_INTERRUPT_PIN as 0 to guest and let passthrough
> continue.
What causes this problem?
On 29/11/2018 07:39, Omkar Bolla wrote:
Hi,
Hello,
I just wanted to run xen hypervisor on ARMv8 architecture, I tried on Hikey960
platform which has armv8, but latest xen giving cpu errors.
Could you please tell me, on which platforms latest xen is working?
If your platform supports vir
On 03/12/2018 14:46, Andre Przywara wrote:
> On 30/11/2018 19:52, Andrii Anisov wrote:
>> Hello Andre,
>>
>> Please see my comments below:
>>
>> On 23.11.18 14:18, Andre Przywara wrote:
>>> Fundamentally there is a semantic difference between edge and level
>>> triggered IRQs: When the guest has ha
On 30/11/2018 19:52, Andrii Anisov wrote:
> Hello Andre,
>
> Please see my comments below:
>
> On 23.11.18 14:18, Andre Przywara wrote:
>> Fundamentally there is a semantic difference between edge and level
>> triggered IRQs: When the guest has handled an *edge* IRQ (EOIed so
>> the LR's state go
Hi Andrii,
On 03/12/2018 12:58, Andrii Anisov wrote:
On 03.12.18 14:17, Julien Grall wrote:
No. I meant that I would be happy with that and I think should also suit you.
Great!
There are no isb() in do_trap_irq(). So did you mean gic_interrupt()?
Right you are.
But then, I am not sure wh
On 03/12/2018 13:05, Andrii Anisov wrote:
Hello Julien,
On 03.12.18 14:58, Julien Grall wrote:
That's micro optimizing Xen... there are better (and less risky) place to look
for optimization.
I would appreciate you point me those places.
I already pointed them in various threads with you.
Hello Julien,
On 03.12.18 14:58, Julien Grall wrote:
That's micro optimizing Xen... there are better (and less risky) place
to look for optimization.
I would appreciate you point me those places.
Knowing how fragile the locking is on the old vGIC, the risk of
micro-optimizing is not worth it.
Hi Andrii,
On 03/12/2018 12:33, Andrii Anisov wrote:
On 29.11.18 14:14, Andre Przywara wrote:
Nah, please don't do this.
Sorry for making you crying looking at this code.
It's terrible, I know. It's rather an idea.
Can you show that atomic bit ops are a
problem? They shouldn't be expensive u
On 03.12.18 14:17, Julien Grall wrote:
No. I meant that I would be happy with that and I think should also suit
you.
Great!
There are no isb() in do_trap_irq(). So did you mean gic_interrupt()?
Right you are.
But then, I am not sure why you want to avoid the isb() in the guest path.
Well,
On Sun, Dec 02, 2018 at 06:47:33PM +0100, Marek Marczykowski-Górecki wrote:
> From: Dwayne Litzenberger
>
> Newer AMD GPUs store their initialization routines as bytecode on the
> ROM. This fixes the following initialization error inside the VM when
> doing PCI passthrough:
>
> radeon :
On Mon, Dec 03, 2018 at 05:28:08AM -0700, Jan Beulich wrote:
> >>> On 03.12.18 at 12:57, wrote:
> > On Mon, Dec 03, 2018 at 02:49:34AM -0700, Jan Beulich wrote:
> >> >>> On 01.12.18 at 13:43, wrote:
> >> > flight 130858 xen-unstable real [real]
> >> > http://logs.test-lab.xenproject.org/osstest/l
flight 75632 distros-debian-sid real [real]
http://osstest.xensource.com/osstest/logs/75632/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-i386-i386-sid-netboot-pvgrub 10 debian-di-install fail like 75621
test-armhf-armhf-armhf-sid-netboot-pygr
On Sun, Dec 02, 2018 at 06:47:32PM +0100, Marek Marczykowski-Górecki wrote:
> From: Dwayne Litzenberger
I think this requires some description. At least a note that the
function is not altered, just errors from pci reads/writes are no
longer ignored.
> Signed-off-by: Dwayne Litzenberger
> ---
>
Hello Andre,
On 29.11.18 14:14, Andre Przywara wrote:
Nah, please don't do this.
Sorry for making you crying looking at this code.
It's terrible, I know. It's rather an idea.
Can you show that atomic bit ops are a
problem? They shouldn't be expensive unless contended, also pretty
lightweight
>>> On 03.12.18 at 12:57, wrote:
> On Mon, Dec 03, 2018 at 02:49:34AM -0700, Jan Beulich wrote:
>> >>> On 01.12.18 at 13:43, wrote:
>> > flight 130858 xen-unstable real [real]
>> > http://logs.test-lab.xenproject.org/osstest/logs/130858/
>> >
>> > Regressions :-(
>> >
>> > Tests which did not
1 - 100 of 152 matches
Mail list logo
